|
|
Body validation is too simple, for example I want the be able to configure the min max from the DB or interdependent validation i.e. if you pass in and Id and a search string I want to return an error. The DB Query editor is too simple requiring the user to manually create sql queries rather than visually build them. The DB editor doesn't allow foreign keys and complex DB relationships to be defined visually as well. The response editor is also not powerful enough. For example I want to send back links (HATEOAS Style) to the objects just created. I also want to send the object just created back in the response. There is no Authorization only Authentication. To be honest this isn't really that useful other than very simple Apis that have no real logic in them. Pricing on Actions is an insane pricing strategy. The pricing looks too high to be reasonable. Even a simple Api would cost me a lot with the pricing strategy. I see the UI component is coming soon. Without a way to build a nice UI to connect to my Api this isn't really a low code solution. No details on hosting on this either. Is my api hosted in the US/Europe/Asia. This will make a big difference to most as I don't want long roundtrip times on my UI. If I'm going to build my next big thing on a Platform I need confidence that the company won't shut down next week and my app is toast. Is there some way that I could be convinced that you won't run out of money and shutdown tomorrow and leave my project dead with you ?
|
|
 |
|
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.
|
|
|
|
|
Easy parsing ? Overall I like jinja syntax the most
|
|
|
|
|
I think this is the wrong post :) You probably wanted to comment in the other thread about the AI language teacher
|
|
|
|
I signed up and want to try it out. The one thing on the account creation page that absolutely grinds my gears, though, are the password requirements. Some use pass phrases. Please please please consider changing these rules, and use 2FA as a security guarantee instead. It makes me dread that I'm going to get a mandatory password reset demand in a month, at which point I have to revert to cycling between insecure password versions.
|
|
|
|
Noted, thanks for the feedback! Will consider changing the requirements for the password. 2FA is on the roadmap and we’re planning to release it within the next two weeks.
|
|
|
|
The official NSA advice for several years has been "do not enforce restrictions on characters in passwords". It's simple to calculate the actual entropy and check against a list of common weak passwords (large lists are easily obtained and kept up to date)
|
|
|
|
Makes a lot of sense. I guess the only requirement that would still be helpful is minimum password length?
|
|
|
|
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.
|
|
|
|
|
What do you think of password-less sign-ins, e.g. email-based sign in or OAuth 2?
|
|
|
|
The email-based “magic link” approach I’m seeing a lot more of lately, and I despise it.
|
|
|
|
I generally find it annoying too, but I think it's reasonable as an option. (Although if it is added as an option, ideally make sure it's possible for password managers to fill in both the email and password in one shot.)
|
|
|
|
|
My password manager is faster and easier (and the email flows tend to make that slower, hidden behind a "login with another method" small grey link), email often has deliverability delays, and it's insecure to boot.
|
|
|
|
I can second that. I prefer password logins over magic links via email. It adds too much friction. I can understand that it might be easier for people who are not using a password manager. For most services I prefer a combination of password and authy-based 2FA. For very specific purposes, some kind of hardware-based authentication, for example with yubikeys makes sense.
|
|
|
|
Pricing is crazy. team plan with 2 million actions ($300 is already expensive for this) + $29k? This is not realistic in any way.
|
|
|
|
As a point of comparison - cloudflare workers costs 0.30$ for the same (2 million) requests, plus a 5$ monthly fee. If my math is correct, in their eyes the visual aspect is worth 100,000x as much? edit: it's actually 200,000x, the cloudflare base fee includes 1 million requests. Is it possible that they added an extra couple zeros?
|
|
|
|
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.
|
|
|
|
In the end, is suspect none of these tools will be able to gatekeep hosting (especially with outrageous rates). The dev process is their key offering, not hosting. The moat on hosting will be nil, totally commoditized. If they were totally charitable, this would be an open source tool letting people export stuff. Anybody could build that, and someone probably will.
|
|
|
|
I agree that the pricing for 2M actions is so high, that why even show it? But this doesn't seem like a typical use case for rapid prototyping, which is what this seems to be made for
|
|
|
|
I've been using Fastgen for the past month or so and really enjoy it for basic use cases. 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!
|
|
|
|
I wanted to give this a whirl by creating an event triggered workflow, but I got stuck pretty quickly. 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.
|
|
|
|
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.
|
|
|
|
I'm always excited by tools like this. How do you feel about Bubble and how it compares? One thing that put me off Bubble was reports of it not scaling very well past a certain point (slow) - unsure why. Is this something you have heard/considered? I see debug mode, but if performance issues were to occur, could one x-ray the generated code or PSQL DB to rectify? One bonus question, what can't it do right now that a Django or Rails API can? :)
|
|
|
|
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 :-)
|
|
|
|
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 better served by coding it yourself in Python or another high level language. Is it possible to export the API with source code if I need more control. That would perk my interest.
|
|
|
|
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.
|
|
|
|
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, 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!
|
|
|
|
I see it the same way. Instead of no-code, give me a framework with batteries-included that allows me to start and iterate faster Temporal, trigger.dev, encore.dev and SST are the one’s I look up to
|
|
|
|
I can confirm, we use Temporal and used Tray.io for a bit. They're not operating at the same level at all, Tray/Zapier kind of drag and drop wire things together can be great to solve some quick pain points, but I would not build a product on top. Temporal has been great, it's also allowed us to significantly simplify our infra around workflows and made it a lot easier to understand what's going on, especially when things go wrong.
|
|
|
|
Congrats on the launch! I really enjoyed the simple demo on the landing page. I think this has great potential to be a better alternative to Firebase/Supabase for frontend developers. Especially if I never have to worry about what is happening under the hood or integrate a cluncky SDK into my project. I look forward to trying it out on a side project!
|
|
|
|
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.
|
|
|
|
Congrats on the launch! Played around with fastgen some weeks ago and liked the focus on creating APIs and workflows. I have built many API endpoints with Make.com in the past as it made it easier to manage external connections compared to using lambdas but felt limited by the Make.con data model. How/when do you plan to - catch up on integrations other workflow tools have already built? E.g. my workflows often rely on data in CRMs/Notion/GitHub. - integrate with alternative databases and datawarehouses? I don’t necessarily want to sync all state to the fastgen-managed Postgres.
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
This is the tool I was looking for! I can't wait to pair it with my NextJS project
|
|
|
|
Congrats on launching! How do you differ from Windmill.dev (open source) / Airplane? Both backed by YC.
|
|
|
|
Founder of windmill.dev here, airplane is not backed by YC but the founder is an alumni. Aside from the obvious open-source aspect, here is one notable difference.
We explicitly do not provide an integrated DB but offer simply a K/V store api, and recommend to use some dedicated services for persistence storage like supabase/neon.tech/aurora/s3: https://docs.windmill.dev/docs/core_concepts/persistent_stor.... We do not believe we can build both the fastest workflow engine at scale and the best DB so we leave the last bit to others. From what I can see, the assumption of the userbase look a bit difference. Although we have a hub (hub.windmill.dev) where users can share premade actions, we focus on script/code in typescript/python/go/bash as the unit for workflows. From there, we focus on building workflows with most of the same primitive as temporal (suspend/resume also called reactivity, error handlers, retry, etc, and some others like caching of step results) and running arbitrary code on your own infra and being able to use your full nodes without overhead. The code for the steps can also be developed locally and deployed from your github repo. Last we have a retool-like + react app capability which seems to be out-of-scope. So to summarize, although you can use windmill to do backend prototyping or as your product backend given that we generate per script/workflow webhooks, we focus on workflows with code and internal tools with enterprise scale requirements such as complex permission per-user/groups.
|
|
|
|
Hey there, thanks for asking! Windmill and Airplane have done some cool stuff and while we do share some common elements with both, there are a few key distinctions. Here’s how we think we’re carving out our own niche in the space: 1. Visual Flow Builder - We've gone all-in on making the interface really interactive and visual. Drag-and-drop actions to build rest APIs and workflows - it's super intuitive and handy for rapid prototyping. 2. Integrated Database - Fastgen has an integrated Postgres database, providing a unified environment for managing your data. 3. Debug Mode - We've got a 'Debug Mode' that throws light on how flows are churning away under the hood, step-by-step. It makes troubleshooting issues and optimizing workflow performance much easier. 4. Flexibility - We understand the need for a tool to be both accessible to less technical users and powerful enough to not restrict more advanced ones. With fastgen we try to strike that balance without compromising very technical users. In short, we believe Fastgen adds a unique flavour to the broader low-code space with a blend of its features and focus on user experience.
|
|
|
|
Is there a way to develop and run the APIs/workflows locally?
|
|
|
|
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.
|
|
|
|
I don't think the comparison is relevant. The platform is more close to a BPM than task automation and internal tools platform.
|
|
|
|
|
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 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?
|
|
|
|
On Firefox/Mac, the animation of the word "backend" / "workflow" is broken somehow, the words disappear for a long time leaving only black.
|
|
|
|
Whoops, thanks for reporting - on it! Update: Fixed. :)
|
|
|
|
|
I got really excited for a second thinking this was infrastructure orchestration. Like AI, I want my no-code tools to enhance my current setup, not replace it. If I could visually build CDNs that connect to APIs that connect to databases, with end-to-end type-safety, authentication, validation, etc etc etc built-in -- that's super compelling. But in terms of the trade-offs between a no-code logic tool like this (price, lock-in) and writing code, this doesn't really fit the bill. I mean maybe the use-case here is prototyping and MVPs for non-technical founders? I don't know if tech companies would want to be locked into something like this though.
|
|
|
|
Looks awesome! What's it under the hood ? Is it gonna be open source ?(not expecting to be, just curious!)
|
|
|
|
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.
|
|
|
|
Congrats on the launch, really nice product! How does this differ from existing solutions like hasura or similar?
|
|
|
|
Thanks, appreciate it! 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
|
|
|
|
From the landing page, this looks great! Can I still connect to the underlying postgres database directly?
|
|
|
|
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.
|
|
|
|
That's pretty steep pricing for a product that has a lot of free/open source competition that are more capable and mature (node red, supabase, Directus, strapi, etc...)
|
|
|
|
|
Looks cool! Will try it out later this week to build a ChatGPT plugin.
|
|
|
|
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.
|
|
|
|
|
|
|
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
|
|
|
|
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, 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.
|
|
|
