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

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!

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

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

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?

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?

In my last startup, we were building a chargeback management tool for fintechs, and essentially whenever a chargeback came in, we'd only get the transaction ID, so we'd have to query the fintech's database to search for that transaction ID and pull additional data points like name of seller, email of seller, etc.

Now, when we did this, it was more of a scrappy workaround to the fintech not being able to dedicate engineering resources to send data to an API endpoint of ours. However, after a while, I thought to myself, there's nothing wrong with querying the fintech's DB as long as we're treating infosec seriously, and so now I'm curious to hear how common this practice is.

Maybe it's just me, but it feels like integrating with internal DBs could allow a startup to onboard and go live with customers much more quickly. For some reason though, I haven't heard much of this around, so to be completely honest, I'm thinking of starting a tool to make this process easier / standardised.

Before that though, I'm trying to wrap my head around the use cases for this so it'd be amazing to hear about your story of integrating directly with a customer's DB -- what was it for and how was the experience!

Comments URL: https://news.ycombinator.com/item?id=41424898

Points: 19

# Comments: 47

I made this tool to allow devs to build backend microservices really quickly, by auto generating all the boilerplate & repetitive code like route config, setting up a client for external services, and even GPT generating code for well known APIs like Firebase, Stripe etc, allowing you to quickly write specific functions relevant to your service

I know what you might be thinking: a UI for backend dev, that sounds stupid af?? And I definitely agree, but by now I've used it to quickly churn out several small scale backends with such ease and speed that I really believe in its value, and so I hope you guys might be able to give it a chance, go create that todo app that we all know and love, and if you hate Visual Backend then, by all means haha

But all jokes aside, I'd really appreciate any feedback, especially on specific use cases / niches that you think might truly benefit from this (been racking my brain trying to figure this one out for weeks to no avail) Cheers :)

Comments URL: https://news.ycombinator.com/item?id=38351510

Points: 2

# Comments: 0

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!

Comments URL: https://news.ycombinator.com/item?id=37919363

Points: 1

# Comments: 1

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!

Comments URL: https://news.ycombinator.com/item?id=37306242

Points: 3

# Comments: 1