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 :)

ah that makes sense, yeah that'd fire, if there's any way to do batching also let me know

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

The current mechanism has security flaws that are hiding because of SSR. Try to implement the same flow in pure-vanilla-js and you'll realize that you're hitting replay attacks instantly. This is the same vulnerability that companies which try to "hash the password on the client side to protect it" face - they've merely transformed the password to a different one (the hashed one) which has the exact same semantics as the original password for an attacker.

Your encrypted customer ID has the exact same semantics as the original customer ID for an attacker, and is insecure.

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

Also we can make these rotate with each request

+1 to the branding

Thanks! We've had polarizing feedback to it which we think is a good thing.

Trying to go for a nostalgic 90s anime vibe which we think is cool... and also might be relatable to other devs

The season of harvest!

code is the new no code!!

+1!! Workflow automation will be natural language in the future :)

Thanks for sharing your views, these are definitely insightful and valid points. Infosec can never be overstated, and it was perhaps a bit naive of me to just think "treating it seriously" would be enough.

To argue against both the points you made though, there are reverse ETL platforms like Hightouch and Census today which 1. have specific architectures to make data movement from a central warehouse to third-party SaaS platforms seamless and easy, and 2. also access the company's data stores directly. What's the difference between what they're doing, and this hypothetical third-party unifying data integrations?

that's what I thinking actually, using oauth to connect to a DB is definitely a new concept though, and most larger enterprises either use data warehouses or self hosted DBs (just a guess), so oauth may not be an option

If the SaaS target customers are smaller companies / startups, then this may be viable

I'd love to hear more about your idea though! would you mind sharing a little bit about it?

> If the SaaS target customers are smaller companies / startups, then this may be viable

I’m your target audience.

The #1 issue I have with this concept is, as a customer, I would have to trust that you understand the performance limits of my production database and that you won’t run (even accidentally) a burst of inefficient queries that takes down or impairs production.

One way around this would be to query against a replica / secondary, but even then you risk overloading a secondary/replica, which could have negative effects in a failover scenario.

Let me know if you end up researching this further and what the conclusion is. I think the best way to tackle this would be via an API the customers can give you.

The idea is a simple marketing tool to help businesses reach out to customers that didn’t convert fully through the funnel. So for example, user created a profile, but didn’t end up purchasing.

If interested, I can share the link (once it’s up) and would love to get your feedback.