cschreiber

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.

very valid point, ty!

`{{ 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

Any other PM books you found had a significant impact on your role?

Very helpful, ty!

Makes a lot of sense. I guess the only requirement that would still be helpful is minimum password length?

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.

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.

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.