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

The season of harvest!

code is the new no code!!

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?

What kind of internal context are you retrieving? I'd imagine you would need access to the codebase to have a thorough enough understanding of the docs, because if not, I feel like most Linear issues + internal documents are not descriptive enough.

Hey everyone!

I've decided to make Visual Backend open source

It's essentially a low code wrapper around NodeJS, to help you rapidly build APIs by automating boilerplate actions like managing project directory, setting up clients for external services like Firebase, etc. I made this tool after working on many backends and realising that for simple services like internal automations or webhook handlers, I was spending way too much time on basic and repetitive tasks, and so I made Visual Backend to overcome this.

It's my first time making something open source, so I probably made a lot of mistakes. If you have any feedback about the tool, docs, or repo, I'd really appreciate it! Wouldn't mind a contribution too ;) Thank you and I look forward to hearing what you guys have to say!

Hey everyone! I'm currently working on Visual Backend, a desktop app which aims to make backend dev more efficient by eliminating repetition like setting up boilerplate code. Long story short, after working on many backend projects, I realised that some aspects are quite repetitive. For instance, when writing a CRUD function, I always follow the same steps of configuring the router and creating / editing new files before actually writing the actual function, so I decided to see if I could automate those processes.

I'd love to hear from you if this is a problem that you face as well and whether you think Visual Backend effectively solves it. Thank you!