51–60 of 118 posts
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!
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/n…
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.
Pricing is crazy. team plan with 2 million actions ($300 is already expensive for this) + $29k? This is not realistic in any way.
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!
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 examp…
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,…
Temporal, trigger.dev, encore.dev and SST are the one’s I look up to
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.
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 bet…
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.
Earlier quoted context omitted.
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 wo…
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…
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.