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