Launch HN: Fastgen (YC W23) – Visual Low-Code Backend Builder
Hi HN! I’m Constantin and together with my co-founders David and Mike we’re building Fastgen, a low code API and workflow builder with an integrated Postgres DB. You can use it to quickly build any custom business logic, cron jobs or complete backends.
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!
Body validation is too simple, for example I want the be able to configure the min max from the DB or interdependent validation i.e. if you pass in and Id and a search string I want to return an error.
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 ?
Thanks a lot for your extensive feedback! It's detailed comments like this that help us improve and meet users needs.
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.
There is something increasingly misaligned with SaaS companies offering mission critical products (like databases or backends), that's bordering on delusions of grandeur.
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.
And Quantum Metrics is a good example of how to do it wrong - no easy way to export and/or migrate. Vendor lock-in sucks.
What happened to the previous company that you raised $100M for? Is it a SaaS? Is it still operating?
wow. Seriously you're probably expecting too much from a low-code solution! No platform is going to have everything you can imagine in it.
I worked at low code pioneer Mendix previously. 10 years ago we had all of these things. For enterprise grade low code platform you definitely need all of these features and a lot more.
Low code is hard, not only do you have to deal with insane technical challenges but also need to make sure you’re building the right level of abstraction. I wonder if it’s better to focus on very specific niche applications instead of being a “backend” builder.
No checked the other reply the dude from the company is saying all this will be in their product eventually. I think they launched very early.
My question is: who is the intended customer?
As a software dev who is confident with coding I would not use this because I don't want to lock myself to a platform (vendor lock-in). Someone who is a rookie might use it but it seems that it requires more than basic knowleadge (e.g. REST, SQL, auth, etc).
I started playing around with it and came to the conclusion that it needs a bit more development before it’s ready for me.
My use case: I’ve been meaning to build a simple backend for a chatbot that’s active in a community I frequent. The functions I want to add to the chatbot are just for fun, and my time on this is 100% voluntary. All I need is a backend to handle two types of requests, one which inserts a record into a persistent data store, and one which retrieves the count of records associated to the requesting user + the date of the first and the most recent records.
There’s nothing there that I don’t know how to code and deploy. But even the time it would cost me to compare prices of the various services which offer backend hosting is more than my little use case is worth. Then I still have to figure out the deployment path for my code, and stamp out the code itself.
The 1000 requests per month + 50k db records you get for free from this service would have been more than enough for what I’m doing. But unfortunately the functionality that I need isn’t quite there yet.
If you're looking for a similar solution that has 0 vendor lock in, checkout https://www.flyde.dev. It's still WIP but Open-Source and comes with a VSCode extension. I'm planning on launching it soon as well :)
I signed up and want to try it out. The one thing on the account creation page that absolutely grinds my gears, though, are the password requirements. Some use pass phrases. Please please please consider changing these rules, and use 2FA as a security guarantee instead.
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.
Noted, thanks for the feedback! Will consider changing the requirements for the password.
2FA is on the roadmap and we’re planning to release it within the next two weeks.
The official NSA advice for several years has been "do not enforce restrictions on characters in passwords".
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)
Makes a lot of sense. I guess the only requirement that would still be helpful is minimum password length?
See 5.1.1.1 & 5.1.1.2 on https://pages.nist.gov/800-63-3/sp800-63b.html. Eight minimum, accept at least up to 64 characters, forbid breached passwords, dictionary words, aaaaaaa style passwords, and usernames, but beyond that:
> 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.
Very helpful, ty!
What do you think of password-less sign-ins, e.g. email-based sign in or OAuth 2?
The email-based “magic link” approach I’m seeing a lot more of lately, and I despise it.
I generally find it annoying too, but I think it's reasonable as an option. (Although if it is added as an option, ideally make sure it's possible for password managers to fill in both the email and password in one shot.)
Why do you despise it?
My password manager is faster and easier (and the email flows tend to make that slower, hidden behind a "login with another method" small grey link), email often has deliverability delays, and it's insecure to boot.
I can second that. I prefer password logins over magic links via email. It adds too much friction. I can understand that it might be easier for people who are not using a password manager.
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.
Magic links are great because they essentially eliminate ATO attacks and allow startups to bypass SAML requirements by delegating to the mail provider. I’m 100% willing to forgo efficiency gains of passwords and managers as both a user and developer.
All you're doing is punting your security to my email provider. It's annoying how many companies assume I have absolute trust in my ISP/Google/Miscrosoft/IT.
> essentially eliminate ATO attacks
They kinda increase the blast radius of an ATO attack on your email account, though.
Replying too late, most likely. But with access to your email account someone could reset your password to what they want it to be and gain access.
Pricing is crazy. team plan with 2 million actions ($300 is already expensive for this) + $29k? This is not realistic in any way.
Appreciate the feedback. We launched our pricing plan this week after being in private beta with a different pricing strategy. We did chat with our private beta users about what would be important to them but are very open to change pricing over time based on feedback from the community. Keep in mind we're providing more than just the execution of actions i.e. offering a visual development environment, an integrated Postgres database, instant deployment, and hosting as part of the package. That being said, we certainly see the need for a competitive pricing strategy and will reassess our rates.
As others have already said, you can get millions of executions of serverless functions for literal pennies on other platforms.
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.
As a point of comparison - cloudflare workers costs 0.30$ for the same (2 million) requests, plus a 5$ monthly fee. If my math is correct, in their eyes the visual aspect is worth 100,000x as much?
edit: it's actually 200,000x, the cloudflare base fee includes 1 million requests. Is it possible that they added an extra couple zeros?
I also was surprised about the pricing. But it's getting a bit better if you check the FAQ. They basically dont charge for "basic" actions and 0.25 per db action. So if you just do some read and write to the db, its basically 0.25 per request.
Dont know why they hide it that crazy (usually its the other way around)...
Note in this case its actions not requests they charge for. If your endpoint does 10 actions vs one that does 1 it'll be 10 times the cost.
2 million actions. Also known as what any modern CPU can run in less than a second. Or probably 1$ on AWS Lambda if counting API Gateway calls.
It’s always been one of my pet peeves when it comes to low / no code solutions like Zapier.
But this is egregious.
In the end, is suspect none of these tools will be able to gatekeep hosting (especially with outrageous rates). The dev process is their key offering, not hosting. The moat on hosting will be nil, totally commoditized. If they were totally charitable, this would be an open source tool letting people export stuff.
Anybody could build that, and someone probably will.
It's me. I'm building it.
I agree that the pricing for 2M actions is so high, that why even show it? But this doesn't seem like a typical use case for rapid prototyping, which is what this seems to be made for
I'm always excited by tools like this.
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? :)
Bubble is a solid platform, but we definitely saw lots of opportunities for enhancements. We’ve talked to lots of users of low-code tools before starting to build and lack of performance was a common complaint which is why we designed Fastgen with a strong focus on performance, UX and scalability. As for the debug mode, while it doesn’t yet show execution times for different steps, that’s an excellent suggestion - we’ll explore! Addressing the bonus question: we don’t currently support custom code/scripts, but rest assured, it’s on our roadmap as part of our commitment to having as minimal restrictions as possible :-)
I wanted to give this a whirl by creating an event triggered workflow, but I got stuck pretty quickly.
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.
Sorry to hear, that the first experience was not as imagined. You are correct that the event system is currently only consisting of internal events. With the next batch of integrations coming in the next couple of weeks we plan to also incorporate the events of these third party applications. This will enable users to build workflows around events being triggered when i.e. a stripe, airtable or google docs event occurs. For now this would need to be implemented via webhooks and API routes. We are also already experimenting with additional events emitted by our system so that the user can build logic that reacts to data changes in the database or routes being called.
That's pretty steep pricing for a product that has a lot of free/open source competition that are more capable and mature (node red, supabase, Directus, strapi, etc...)
Wow, what was the motivation for using this abnormal syntax for array element indexing? https://docs.fastgen.com/getting-started/variables#indexing-...
Easy parsing ? Overall I like jinja syntax the most
You are misremembering, Jinja uses python syntax like a sane language so it would be `{% set foo = ["alpha", "beta"] %} {{ foo[1] }}` not `{{ foo.[1] }}` like they use. I actually probably wouldn't have chirped about it if they used the alternate syntax (also supported by Jinja) of `{{ foo.1 }}` but the belt-and-suspenders of requiring the array brackets and the dot is just ... why?
`{{ foo.1 }}` is supported and initially was the only syntax to index arrays. But with the need to index arrays with the help of other variables came the introduction of optional `[]` to encapsulate nested vars from the the top level var. Will update the documentation page in the next hours to also showcase `{{ foo.1 }}`. Thanks for the heads up
Spot on! :) But we already have it on the roadmap as one of our next items to clean that up properly and migrate away from it
I would suggest dropping the "you can use == or = interchangeably" since I doubt that adds as much value as "future syntax risk" it incurs
very valid point, ty!
I've been using Fastgen for the past month or so and really enjoy it for basic use cases.
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!
How does this handle load ?
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.
Let me address each of your points:
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.
Thanks for the response, I definitely wish you luck but I think you're going to have to focus more on a non-developer niche. So maybe add more integrations to outside APIs. From the YouTube video it doesn't seem like this is too accessible to anyone without a strong technical background .
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
I really don't see who this is for.
It seems like I have to build most of the important things manually, like the SQL queries, and it doesn't look like anything is typed or checked. So in the end, this seems like it would only be useful for extremely simple things(like sending a message to slack when a customer signs up, or something), but that is already only a few lines of code in javascript, making the value proposition of this rather dubious to me. Especially considering that I can either a) be vendor locked into this platform and completely dependent on what it can and can't do, while all the important bits of my code are smeared all over your visual editing tool or b) write a few lines of typescript which isn't going anywhere, runs anywhere, etc etc.
> We’re low-code fans ourselves and believe it’s sometimes underappreciated how much complexity existing solutions can already handle
Just because you can stuff complexity into a thing, that doesn't automatically make it a good idea. These low code solutions scale extremely poorly(in terms of usability and maintainability) as complexity grows.
Also, is the integrated database maximum size really only 8GB for all tiers? That seems laughably small, especially considering the price you are asking past a few actions. The pricing model really seems to put you in a place where the customers you are going to get are only going to be small fish that need to send themselves text messages a few times a month, or something like that. No enterprise is going to blow $29k a month on 2 million serverless calls and an 8 gigabyte database when they can pay a single developer a fraction of that for a week of development time and a few bucks a month for serverless functions and a managed DB solution such as supabase.
Congrats on the launch!
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!
Happy to hear that you like the demo, we added it to the website this week. We worked with multiple Frontend developers in our private beta and the common theme was that they enjoyed the simplicity with which they could deploy APIs on top of their data. There is still much to build but our goal is to make the backend work as easy as possible. Would love to have you on board and would also appreciate any feedback you have once you start using it for a side project.
Hi, I like this! I'm curious what drove the decision to use the vertical block builder style you chose. I'm partial to node-based editors and have been building things with React Flow recently. LangFlow [1] is a good example, but there's lots of UIs that use a similar interface (e.g. Blender [2] and Unity [3]).
[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
Hi there! Ah, the design of our interface... You've just touched on a topic that's seen more passionate debates in our team than whether pineapple belongs on pizza.
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.
The workflow UI looks really good. Nice work! Was that totaly built in house or is it based on a library?
I see the "visual" aspect of the low-code movement in the frontend, but not on the backend.
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!
I see it the same way. Instead of no-code, give me a framework with batteries-included that allows me to start and iterate faster
Temporal, trigger.dev, encore.dev and SST are the one’s I look up to
I can confirm, we use Temporal and used Tray.io for a bit. They're not operating at the same level at all, Tray/Zapier kind of drag and drop wire things together can be great to solve some quick pain points, but I would not build a product on top. Temporal has been great, it's also allowed us to significantly simplify our infra around workflows and made it a lot easier to understand what's going on, especially when things go wrong.
Thank you for your insights & appreciate the suggestions!
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.
Congrats on launching! How do you differ from Windmill.dev (open source) / Airplane? Both backed by YC.
Founder of windmill.dev here, airplane is not backed by YC but the founder is an alumni.
Aside 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.
Hey there, thanks for asking!
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.
Is there a way to develop and run the APIs/workflows locally?
At the moment, no. Our focus has been on providing a cloud-based low-code experience that you can access from anywhere without the need for local setup. However we are exploring ways to support it. For more details check out my other comment in response to a similar question.
I don't think the comparison is relevant. The platform is more close to a BPM than task automation and internal tools platform.
I got really excited for a second thinking this was infrastructure orchestration.
Like AI, I want my no-code tools to enhance my current setup, not replace it. If I could visually build CDNs that connect to APIs that connect to databases, with end-to-end type-safety, authentication, validation, etc etc etc built-in -- that's super compelling. But in terms of the trade-offs between a no-code logic tool like this (price, lock-in) and writing code, this doesn't really fit the bill.
I mean maybe the use-case here is prototyping and MVPs for non-technical founders? I don't know if tech companies would want to be locked into something like this though.
Congrats on the launch! Played around with fastgen some weeks ago and liked the focus on creating APIs and workflows. I have built many API endpoints with Make.com in the past as it made it easier to manage external connections compared to using lambdas but felt limited by the Make.con data model.
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.
The last couple of weeks we were mainly focused on transition between the private and public beta, so that the development of new integrations had to be paused for a bit. For the coming weeks we have the next 9 integrations planned as well as external DB connectors to various sources. We’ll definitely consider your input and see which integrations are requested most.
We are using Fastgen for a couple of months now to automate a couple of internal workflows. For us it is a legit Zapier alternative. Can recommend checking it out.
Workflow creation for non-dev users seems like a good use case. In some ways it seems similar to an AWS lambda in functionality.
I did something similar back in the 90s. Basically implemented full state machine engine including nesting, graphical editor and debugger with the ability to hook custom actions. It was marketed as business process server. It was a product that was used to integrate various business processes in multiple orgs in telecom industry.
Congrats. This looks excellent. I have tried the frontend ones like Webflow and Bubble and they are all clunky, not meant for any serious work.
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.
At the moment, Fastgen doesn’t directly support local development. Our focus has been on providing a cloud-based low-code experience that you can access from anywhere without the need for local setup. However, we do recognize the value of local development, and we’re exploring ways to support it. That being said, we already offer an experimental feature to call your route from your local environment through for example curl or postman. We plan to extend on this by allowing the user to call and test the currently unpublished fastgen route from the local environment as well as also having multiple environments (dev/staging/production) to switch between within your projects. Does that answer your question or is there something else you are concerned about?
This does restrict me to build small toy apps. Because I do deep thinking and system building in my remote cottage without internet.
[dead]
This is so awesome, congrats on the launch. You have made a lot of this quite usable. A while back I started working on something similar (app.stitchbits.co). How do you plan on widening the breadth of integrations?
On Firefox/Mac, the animation of the word "backend" / "workflow" is broken somehow, the words disappear for a long time leaving only black.
Whoops, thanks for reporting - on it!
Update: Fixed. :)
This is awesome, I am building a visual tool to build frontend workflows, I'd love to talk to you to see where we can match.
Congrats on the launch, really nice product! How does this differ from existing solutions like hasura or similar?
Thanks, appreciate it!
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
Looks awesome! What's it under the hood ? Is it gonna be open source ?(not expecting to be, just curious!)
We use a combination of RabbitMQ, Centrifugo, and Redis with a backend written in golang and our own job scheduling engine. Everything is deployed on AWS EKS. While we thought about it a lot, no plans to open source it at the moment.
From the landing page, this looks great! Can I still connect to the underlying postgres database directly?
Yes, you can. We give you the keys to the database we host for you. Alternatively, you can host the database somewhere else and connect it to Fastgen to build APIs and workflows on top of it.
if i cannot export the code as nodejs or some programming lan raw code , this is a big lock in risk and noway i will use it in a serious project
Who is the target audience for this?
You can separate the target audience into three main camps:
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
I don’t think you can make everyone happy.
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?
That is a fair point you’re raising, and we agree, we will not be able to build a tool that is right for everyone.
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.
This is the tool I was looking for! I can't wait to pair it with my NextJS project
Looks cool! Will try it out later this week to build a ChatGPT plugin.
That sounds great. Keep us posted on how it goes. If you run into any issues, we have a slack community where the whole team is answering questions. We are also building out our educational content in our documentation and will post some GPT showcases there soon.
Congrats on launching!
Nice product page
How is this different from Strapi?
How can a query for data using logical operators? Example:
GET all log entries from 1/1/2022 until 1/1/2023 AND created by Joe OR Mary
Hi there, Mike CEO of Fastgen here, jumping in for Costa.
Strapi is a headless CMS and focuses on Content Delivery to a Frontend. Fastgen is a lowcode backend builder and is putting a stronger focus on application logic, triggering workflows, and moving data around between different sources. So there can be a slight overlap but it is not very large.
If you want to query data from the connected database in Fastgen, you can do so by using our SQL action block. For your example you could use something like the following statement:
SELECT * FROM log_entries WHERE (created_by = 'Joe' OR created_by = 'Mary') AND created_at >= '2022-01-01' AND created_at < '2023-01-01';
The SQL Action would then return the requested data and you can reuse it in any of the following actions, send it to your frontend, a slack channel, a different api or any destination you want. You can also trigger additional logic or workflows based on the results.
Ok, so this is like Camunda?
Beautiful! Insanely easy to use
Congrats on the launch, guys!
Wow! Amazing tool, love it!
Congrats on the launch!
Deleted
I think this is the wrong post :)
You probably wanted to comment in the other thread about the AI language teacher
Very cool!
this is awesome
[flagged]
This is so clearly written by ChatGPT, as are a few other comments in your history
So you are a potential 'customer' for this product you say?