Launch HN: Fastgen (YC W23) – Visual Low-Code Backend Builder
We just launched our public beta, you can try it out here: https://fastgen.com/. You can find demo videos https://youtu.be/O9IM7rLYIQU and https://youtu.be/Hc1CYJDEDQw.
At our previous company, a student financing platform, we built several internal and external facing tools and encountered how tedious it can be to create and maintain myriads of APIs/CRUD operations. We especially felt that when building for edge cases and “what if” scenarios, as well as integrating with lots of third party services which receive, update and return data. In our case, a custom servicing platform which handled student repayments had to account for different student categories and repayment plans, while factoring in data we received from our KYC and ACH banking partners for each student. With Fastgen we try to eliminate boilerplate code and make it easier to adjust and share your work in a visual environment.
We’re low-code fans ourselves and believe it’s sometimes underappreciated how much complexity existing solutions can already handle, and we are excited to contribute to that market. The low-code space is crowded with front-end tools, but with a comparatively small number of backend tools. There is lots of busywork that comes with setting up a backend; we remove that busywork. Also, most low-code tools restrict users in what they are able to do. Our goal is to provide you with the flexibility and control inherent in coding, while still making it easier to use and faster to deploy.
In Fastgen you sequence 'actions' to form rest APIs and workflows through a drag-and-drop interface. Actions are essentially functions that perform specific tasks such as sending an HTTP request, checking for conditions or interacting with a database.
We support SQL for database operations, JSON for data structure, and comparison operators similar to JavaScript for decision-making in workflows. Everything you create can be deployed and tested instantly in the platform and will be hosted for you. Fastgen has a 'Debug Mode' that gives insights into the step-by-step execution of workflows. This aids in pinpointing issues and optimizing workflow performance.
While some users have created backends for full MVPs with us, others use the platform to build automations for their data/operations teams. For example, one team was missing functionality in Pipedrive for their sales team, so they created a sequence of conditions and HTTP requests to the Pipedrive API to create their own custom lead recycling process.
Other things our users have done include the creation of KYC onboarding flows, a Chinese translation app using ChatGPT, an API that retrieves a company’s financial filings from the SEC for a crowdfunding platform, a cron job that checks for the health status of all other APIs in a code base, a categorizer of well performing product launches, a sitemap checker for a SEO project, and others.
We would love for you to try out the platform and are excited for your thoughts and feedback in the comments!
117 comments
[ 3.8 ms ] story [ 215 ms ] threadAside from the obvious open-source aspect, here is one notable difference. We explicitly do not provide an integrated DB but offer simply a K/V store api, and recommend to use some dedicated services for persistence storage like supabase/neon.tech/aurora/s3: https://docs.windmill.dev/docs/core_concepts/persistent_stor.... We do not believe we can build both the fastest workflow engine at scale and the best DB so we leave the last bit to others.
From what I can see, the assumption of the userbase look a bit difference. Although we have a hub (hub.windmill.dev) where users can share premade actions, we focus on script/code in typescript/python/go/bash as the unit for workflows. From there, we focus on building workflows with most of the same primitive as temporal (suspend/resume also called reactivity, error handlers, retry, etc, and some others like caching of step results) and running arbitrary code on your own infra and being able to use your full nodes without overhead. The code for the steps can also be developed locally and deployed from your github repo.
Last we have a retool-like + react app capability which seems to be out-of-scope. So to summarize, although you can use windmill to do backend prototyping or as your product backend given that we generate per script/workflow webhooks, we focus on workflows with code and internal tools with enterprise scale requirements such as complex permission per-user/groups.
Windmill and Airplane have done some cool stuff and while we do share some common elements with both, there are a few key distinctions. Here’s how we think we’re carving out our own niche in the space:
1. Visual Flow Builder - We've gone all-in on making the interface really interactive and visual. Drag-and-drop actions to build rest APIs and workflows - it's super intuitive and handy for rapid prototyping.
2. Integrated Database - Fastgen has an integrated Postgres database, providing a unified environment for managing your data.
3. Debug Mode - We've got a 'Debug Mode' that throws light on how flows are churning away under the hood, step-by-step. It makes troubleshooting issues and optimizing workflow performance much easier.
4. Flexibility - We understand the need for a tool to be both accessible to less technical users and powerful enough to not restrict more advanced ones. With fastgen we try to strike that balance without compromising very technical users.
In short, we believe Fastgen adds a unique flavour to the broader low-code space with a blend of its features and focus on user experience.
A couple of differences are that Fastgen is fully hosted, we offer visual workflow building, easy third-party integrations, and a built-in Datahub interface for data management.
Check out my other comment in response to a similar question for a bit more detail
It makes me dread that I'm going to get a mandatory password reset demand in a month, at which point I have to revert to cycling between insecure password versions.
2FA is on the roadmap and we’re planning to release it within the next two weeks.
It's simple to calculate the actual entropy and check against a list of common weak passwords (large lists are easily obtained and kept up to date)
> Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.
For most services I prefer a combination of password and authy-based 2FA. For very specific purposes, some kind of hardware-based authentication, for example with yubikeys makes sense.
They kinda increase the blast radius of an ATO attack on your email account, though.
Technical people at startups. In smaller companies that can be the CTO, in larger companies it is usually individual contributors. They are using Fastgen to extend their existing product or build the backend for small internal/external tools.
Solo entrepreneurs or small bootstrapped teams that are using low code tools to power most of their business. They would use a Frontend builder like Webflow or WeWeb for their Frontend and Fastgen to power the backend.
Freelancers and Agencies. They are enabled to quickly prototype and build projects for their clients. The visual nature of Fastgen makes it easier for clients to understand and provide feedback on the processes.
Before our launch today, we were running a private beta for 3 months. We had users from all the categories above participate and worked closely with them to improve the product
As a backend-developer I’d never use your tool, because it is limited to the set of building blocks you’re offering.
As a no-code developer “REST APIs, CRUD operations and dynamic workflows on top of a Postgres DB” are foreign words to me. Why would I even need that? And even if I needed that, why would I use something that is limited instead of a low-code tool like Windmill, Retool or Trigger.dev?
I think you really have to think about who is going to be using the product and what are their requirements. Maybe the type of customers didn’t even need an API in the first place?
Our hypothesis is that if we give users the right tools (rapid API development + DB) they are enabled to create a large variety of applications (either full MVPs or extension of an existing product) and that should be beneficial to different types of developers. That being said, there are many tasks you want to execute as a backend developer that we will not be the right fit for as every platform that is not pure code will have some kind of limitation by definition. Similarly, if someone does not have any technical understanding whatsoever, Fastgen will not be the right fit for them either.
We agree that focus on a user group is key and we will keep a close eye on how ours is developing over time to build a great product for people that get the most out of the platform.
How do you feel about Bubble and how it compares? One thing that put me off Bubble was reports of it not scaling very well past a certain point (slow) - unsure why. Is this something you have heard/considered? I see debug mode, but if performance issues were to occur, could one x-ray the generated code or PSQL DB to rectify?
One bonus question, what can't it do right now that a Django or Rails API can? :)
Update: Fixed. :)
The DB Query editor is too simple requiring the user to manually create sql queries rather than visually build them.
The DB editor doesn't allow foreign keys and complex DB relationships to be defined visually as well.
The response editor is also not powerful enough. For example I want to send back links (HATEOAS Style) to the objects just created. I also want to send the object just created back in the response.
There is no Authorization only Authentication.
To be honest this isn't really that useful other than very simple Apis that have no real logic in them.
Pricing on Actions is an insane pricing strategy. The pricing looks too high to be reasonable. Even a simple Api would cost me a lot with the pricing strategy.
I see the UI component is coming soon. Without a way to build a nice UI to connect to my Api this isn't really a low code solution.
No details on hosting on this either. Is my api hosted in the US/Europe/Asia. This will make a big difference to most as I don't want long roundtrip times on my UI.
If I'm going to build my next big thing on a Platform I need confidence that the company won't shut down next week and my app is toast. Is there some way that I could be convinced that you won't run out of money and shutdown tomorrow and leave my project dead with you ?
Let me address each of your points:
Body validation, DB Query editor & DB features: Definitely understand your need for more complex validation and query building. We're still in public beta, and building out and refining our features is a continuous process. We're working on improving these areas for more advanced use cases and will consider your feedback as part of that.
Authorization: More granular control over authorization is on our roadmap.
Pricing: Appreciate your concern about pricing. In our private beta we had a different strategy and we have launched the new pricing plan this week after talking with our private beta users about what would be important for them. We'll certainly take your feedback into consideration as we adjust our pricing strategy.
Hosting location: Currently everything is hosted in the US, that being said region selection has been requested and is on the roadmap as well however we'll likely not not ship this feature before EOY. Till then, will include more information about the current hosting region on our website.
Long-term Reliability: We understand the reservation about how long Fastgen will exist since we just launched. We have not announced any funding for Fastgen yet but we are already well-funded for the next couple of years. It might also help to know that the whole core team has been working together for multiple years before we started Fastgen. While it was a different company, we raised more than 100M dollars for that one and are experienced in navigating different fundraising environments. We're in it for the long haul.
If you are offering anything that has to deeply and critically integrate with my company and you are not exactly google, you will have to make it super obvious how I can practically outlive you without paying an insane price, before I would even ever consider adoption. Considering the trajectory that most startups take after a couple of years, it's just irresponsible to take it on as an additional risk.
That means practically, if you want to sell me on your SaaS (which I am happy to pay for, as long as you can offer it) I need a clear and guaranteed way to migrate to self-hosting if I must, without me asking. Right now, Vercel is a good example of how to do this right.
[1] https://github.com/logspace-ai/langflow
[2] https://docs.blender.org/manual/en/3.5/interface/controls/no...
[3] https://unity.com/features/unity-visual-scripting
In the end, we chose to go with a vertical layout mainly for simplicity and intuitiveness. The vertical block builder provides a linear, straightforward visual representation of the workflow, which can be easily understood at a glance and aligns well with regular standard vertical scrolling. Another factor was visual clarity i.e. presenting a clear view of the sequence of operations, also helping make the flow easier to understand and debug.
That said, we understand that more complex workflows can benefit from a node-based editor's flexibility.
I really enjoyed the simple demo on the landing page. I think this has great potential to be a better alternative to Firebase/Supabase for frontend developers.
Especially if I never have to worry about what is happening under the hood or integrate a cluncky SDK into my project. I look forward to trying it out on a side project!
No code for the backend actually might be the better usecase so I would love to try it out / see how it evolves.
One concern I have here is local development.
How/when do you plan to
- catch up on integrations other workflow tools have already built? E.g. my workflows often rely on data in CRMs/Notion/GitHub.
- integrate with alternative databases and datawarehouses? I don’t necessarily want to sync all state to the fastgen-managed Postgres.
edit: it's actually 200,000x, the cloudflare base fee includes 1 million requests. Is it possible that they added an extra couple zeros?
Dont know why they hide it that crazy (usually its the other way around)...
Anybody could build that, and someone probably will.
These serverless platforms already tend to cost A LOT more than running traditional servers, but your offering is 200,000 times pricier than an already costly option.
One thing to note here is that those traditional providers charge per request, while your product is priced on actions, which are blocks in the request flow. Realistically, any non-basic API will have several blocks for each request, thus considerably inflating your numbers.
To put things in perspective here, 1 Req/s is 2.5M Req/Mo which is already over your highest plan, and while it may be a considerable amount of volume for a medium app, it’s still something you could run on a $5 VPS and have 99% of your CPU sitting idle. For your proposed pricing, you could literally deploy tens or hundreds of dedicated servers around the world for each client that signs up and still end up being ridiculously overpriced.
As another example, given the current Reddit debacle, we know that an average user of theirs makes ~380 API Req/day. This means that 175 users would saturate the 2M actions in your highest Team plan. How would you justify 30.000$ for 175 MAU?
If these prices are somehow based on your costs for hosting the API you seriously need to rethink your internal efficiency
That said, I like the style and concept of the product, but there are still too many missing features, especially to justify a price that’s many orders of magnitude higher than anyone else.
It’s always been one of my pet peeves when it comes to low / no code solutions like Zapier.
But this is egregious.
Does each customer get their own VM to run requests against?
Do you have a rare limit built in ? What if I need to do something more complex, is it possible to have a block of say Python code that executes?
Honestly I'm not sure who this is meant to serve,AWS has a rather robust API offering with the added bonus of integrating with AWS services.
Anything more complex than that might be better served by coding it yourself in Python or another high level language.
Is it possible to export the API with source code if I need more control. That would perk my interest.
Performance: When we began planning to build Fastgen, our most important consideration was how it should handle load. Therefore, most of our design decisions have been deeply influenced by this. We have autoscaling go backends that are trimmed on performance, handling all customers together. With RabbitMQ we distribute the load and offload expensive operations to different micro services. Redis as our Cache and Centrifugo for real time messaging complete the picture at the moment. Everything deployed on AWS’s Kubernetes system.
Rate Limit: We have rate limits for the Free and Starter tiers while the Pro and Team plans enjoy no rate limit.
Restrictions: We currently don’t support custom code, but rest assured, it’s on our roadmap as part of our commitment to having as minimal restrictions as possible. That being said, it is not possible to export your API, but rather the goal is to give the user as much control over the API as if they have the full source code.
At that point, why not spin up your own API. That said this is a very profitable sector so I do think your company will do well. Good luck
It's pretty much the fastest way to spin up an API. I'd really love to see how this adapts to serving more advanced use cases in the future.
Great work, team!
For the backend, my pain point is setting up a whole project for a small task (for example, I need to process a webhook from provider X; it is just saving some fields of the payload to a given DB table). In this case, I would prefer a "platform" to quickly code and deploy these tasks.
The value here is not the ease of coding, but the ease of spinning up a new project and having some basic development services available (versioning, JSON parsing, orm, some form of temporal storage, some form of cache, maybe some work queue mechanism, ability to run periodic jobs, etc) glued together in a consistent API available in some scripting language (Javascript, Lua). On top of this, basic DevOps features (deployment, observability, monitoring, etc).
Just my 2 cents.
Congrats on the launch!
Temporal, trigger.dev, encore.dev and SST are the one’s I look up to
We absolutely agree that a large part of the value prop is about the ease of the project setup and deployment rather than just simplifying the coding process.
That said, we do believe that the visual aspect brings benefits to backend development as well. While traditional coding requires a level of abstract thought to envisage data flow and logic, visual tools offer a concrete representation that can make this process more intuitive. This can help developers to better understand and manage complex workflows, data relationships, and API structures, which in turn can boost productivity and reduce errors.
Additionally, our hypothesis is that it offers a way for non-technical team members like PM & BI roles or even clients, to contribute more effectively. By visualizing workflows, logic, and data models, people can improve communication, minimize misunderstandings, and contribute to a better final product.
However if you still prefer coding, we have a Custom Code Action on the roadmap that will let you do exactly that and still benefit from some of the guardrails we provide.
I had imagined creating a workflow that would be triggered by the occurrence of some external event, such as a row being added to a Google Sheet. But after struggling with the UX and documentation for a bit, I think I finally worked out that this is not consistent with Fastgen's concept of an event triggered workflow, and that these workflows can actually only be triggered within an API call or workflow that occurs within my Fastgen environment.
Is that correct? If so, I don't believe it's clear or obvious, so perhaps it makes sense to spell this all out more clearly in the UX and documentation. Also, the sort of event trigger I had in mind is an essential aspect of many similar low code tools (i.e. make.com, bubble.io), so it may be worth considering adding this functionality unless you want Fastgen to be all about inbound API calls.