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.
`{{ 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
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.
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 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.
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.
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 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.
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.
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.
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.
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
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 :-)
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.