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.
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.
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.
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
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.
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.
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.