johnyeocx

each event is a consumable which means we aren't running large analytical queries to process them.

Our bottleneck is probably infra + optimisations via caching but at the moment I'd say we can handle 1k events per second comfortably :)

Thanks! Going oss was definitely about trust in the beginning -- people were more open to using the platform because they could see our codebase

Agreed that self-hosting billing can be a pain just cuz of how complex the whole system can be, which also means that it's prob p hard to debug / fix when something goes wrong. We don't see a lot of people self-hosting Autumn at the moment, but would be interesting to see that happen.

We've got a bunch of requests for a go sdk, so definitely on our roadmap to launch that soon!

DX is our bread and butter though, and we're fully focused on perfecting it for a single language (Typescript) before we start journeying into other languages!

it was more of a figure of speech where the entire implementation for the user would be on the frontend (React). Sensitive operations are being called securely on the backend, just through Next.js server functions!

Maybe we didn't phrase it as well as we should've. We meant to say API routes in general are public, and so the server actions could be called by anyone.

Authentication is definitely possible, but we were trying to brainstorm a way where users could have protected routes with as little set up as possible, the ideal being they just pass in customerId into a Provider component

We also did think about things like registering an auth function but felt that being able to just pass in customerId would be a magical experience!

Definitely acknowledge that the current mechanism has flaws though -- it's really more of an experiment at the moment, and if it does indeed become very popular with users we would implement auth mechanisms like JWT and what not -- though that would kinda be reinventing the wheel

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, and down the line if we continue working on it we might even build an auth system involving JWTs -- though that'd be reinventing the wheel and not something we're keen on

3. We are actually now working more on a framework agnostic pattern where users register a middleware on their backend which will spin up routes for Autumn, and the frontend provider contains a client which simply calls these routes

+1 to the branding