Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We tried to make billing backendless

useautumn.com

Post reply on HN
Print view View original

31–40 of 43 posts

Re: We tried to make billing backendless

#31

Post by skeptrune »

serbuvlad wrote: post #6

I find everything about web technology nowadays to be extremely obtuse. I am mostly an embedded/Linux driver engineer, but I think I know the basics of HTTP, REST APIs, Docker containers, how the web works overall etc. But, like. What are we doing? What do you mean make the billing backendless? Obviously there has to be a backend to process the payment. What are you even saying? You are presumably not building a dist…

>If these people named NoSQL, it would be called databaseless.

Lmao, this is way too good. I'm going to steal this.

Re: We tried to make billing backendless

#32

Post by supportengineer »

ayushrodrigues wrote: post #13
taurath wrote: post #3

I'm rather confused by this article - I've made products and pricing services, and just on the first line its said that billing requires webhooks and state syncing.. but why? Is it a way to utilize payments in an otherwise static site? Whats the benefit? You can absolutely accept payments without webhooks. Please help, I really don't understand the niche! I'm left with the sense that this is a sort of solution that's…

Yes you're right -- payments can definitely be done without webhooks, but it is typically all controlled server-side. Especially things like upgrade and downgrade flows, as they involve automatically charging a user's card. What we were exploring is whether there's a way to do this securely from the frontend (eg on a pricing page) without needing to open up backend routes. You're also correct that our niche is trying…

The browser allows JavaScript to be modified. Therefore, you can never trust the client side. You can’t put “trust” there.

Re: We tried to make billing backendless

#33

Post by ayushrodrigues »

Daviey wrote: post #11

I find this "backendless billing" approach fascinating because it highlights the tension between DX and security. As someone who's built payment systems, I understand the appeal of reducing backend boilerplate, but there's always a security tax to pay. The real issue seems to be that they're trying to make billing "feel frontendish" when it's inherently a backend concern. The encryption approach in Part 3 is essentia…

Appreciate the comment! Has definitely been an interesting journey for us exploring the space

Re: We tried to make billing backendless

#34

Post by ayushrodrigues »

robertlagrant wrote: post #2

Why not just authenticate the user against that customer_id, and then you can pass the customer_id around as much as you like (or have a surrogate key to it for a little more security)? A JWT with the customer_id (or surrogate) in would let you do that in serverless function.

yep, this is the plan

Re: We tried to make billing backendless

#35

Post by ayushrodrigues »

johnyeocx wrote: post #12
beej71 wrote: post #5

I don't get it. If someone gets a hold of the encrypted customer ID, can't they impersonate the customer? Is it just that the customer ID is guessable?

That's true for now -- we definitely don't recommend using the encrypted customer ID as a fully secure method for auth, but implemented it more as a way for users to quick start without friction 1. This is also why we've built plugins for popular auth providers like Clerk, Better Auth and Supabase, which are called on the backend to fetch the user / org ID. 2. The encrypted customer ID is more of an experiment atm, a…

Also we can make these rotate with each request

Re: We tried to make billing backendless

#36

Post by robertlagrant »

ayushrodrigues wrote: post #34
robertlagrant wrote: post #2

Why not just authenticate the user against that customer_id, and then you can pass the customer_id around as much as you like (or have a surrogate key to it for a little more security)? A JWT with the customer_id (or surrogate) in would let you do that in serverless function.

yep, this is the plan

Oh, I must have misread? I thought the thing was a custom encryption/decryption dance instead of a signed JWT.

Re: We tried to make billing backendless

#37

Post by oatmeal_croc »

ayushrodrigues wrote: post #16
biker142541 wrote: post #10

Like others, quite confused here. If it requires server actions, then it's not backendless? Just say you are simplifying the backend and how you interact with it, if that's what you are doing.

I intended to use backendless more as a figure of speech here. We wanted to make billing "feel" backendless.

You could also say "I made the billing a winged cow sailing a boat" and it would be a figure of speech.

Re: We tried to make billing backendless

#38

Post by serbuvlad »

jollyllama wrote: post #30
MobiusHorizons wrote: post #22

Earlier quoted context omitted.

I believe the marketing material around serverles functions is at fault. Clearly there is a server, because there is a computer answering requests on a specific ip address mapped to dns. So the wording is maddening. It’s a bit like cgi-bin except it spins up a vm or other sandbox to run the serving code instead of just starting a process.

Functions-as-a-service was a better descriptor. This is just billing as a service.

Oh, so there is a billing backend. It's just managed by someone else.

Then yeah, just call it billing as a service.

I just dislike the wording of it all. "You don't have to do the billing in the backend, you can do it on the frontend". As if the frontend and the backend were mythical realms fighting for control.

We went from PHP generated websites, to PHP backend generation bad, use "client-side rendering" and "single-page applications", as the shiny new thing.

Then we went to Server Side Rendering (SSR), as a new thing. What do you mean a new thing? You're just doing in Node what everyone was doing in PHP 15 years ago.

And that's fine!

Not every idea has to be revolutionary, not everything has to be "the future", or "the only way".

You've found a service that does billing for you without having to integrate it into your backend. Great! Amazing! Good for you! I'm sure it's of interest to a lot of people!

But why can't you just, you know, say it like that?

Re: We tried to make billing backendless

#39

Post by ljm »

serbuvlad wrote: post #6

I find everything about web technology nowadays to be extremely obtuse. I am mostly an embedded/Linux driver engineer, but I think I know the basics of HTTP, REST APIs, Docker containers, how the web works overall etc. But, like. What are we doing? What do you mean make the billing backendless? Obviously there has to be a backend to process the payment. What are you even saying? You are presumably not building a dist…

One day there will be a type of web developer who completely dismisses the concept of running a backend and instead whips out their wallet and subscribes to a dozen SaaS providers instead. Literally everything else will be client side inside NextJS.

Re: We tried to make billing backendless

#40

Post by UK-AL »

ljm wrote: post #39
serbuvlad wrote: post #6

I find everything about web technology nowadays to be extremely obtuse. I am mostly an embedded/Linux driver engineer, but I think I know the basics of HTTP, REST APIs, Docker containers, how the web works overall etc. But, like. What are we doing? What do you mean make the billing backendless? Obviously there has to be a backend to process the payment. What are you even saying? You are presumably not building a dist…

One day there will be a type of web developer who completely dismisses the concept of running a backend and instead whips out their wallet and subscribes to a dozen SaaS providers instead. Literally everything else will be client side inside NextJS.

It's not really backendless more like outsourcing backend.
Post reply on HN