[HN Gopher] Launch HN: Fastgen (YC W23) - Visual Low-Code Backen...
___________________________________________________________________
Launch HN: Fastgen (YC W23) - Visual Low-Code Backend Builder
Hi HN! I'm Constantin and together with my co-founders David and
Mike we're building Fastgen, a low code API and workflow builder
with an integrated Postgres DB. You can use it to quickly build any
custom business logic, cron jobs or complete backends. We just
launched our public beta, you can try it out here:
https://fastgen.com/. You can find demo videos
https://youtu.be/O9IM7rLYIQU and https://youtu.be/Hc1CYJDEDQw. At
our previous company, a student financing platform, we built
several internal and external facing tools and encountered how
tedious it can be to create and maintain myriads of APIs/CRUD
operations. We especially felt that when building for edge cases
and "what if" scenarios, as well as integrating with lots of third
party services which receive, update and return data. In our case,
a custom servicing platform which handled student repayments had to
account for different student categories and repayment plans, while
factoring in data we received from our KYC and ACH banking partners
for each student. With Fastgen we try to eliminate boilerplate code
and make it easier to adjust and share your work in a visual
environment. We're low-code fans ourselves and believe it's
sometimes underappreciated how much complexity existing solutions
can already handle, and we are excited to contribute to that
market. The low-code space is crowded with front-end tools, but
with a comparatively small number of backend tools. There is lots
of busywork that comes with setting up a backend; we remove that
busywork. Also, most low-code tools restrict users in what they are
able to do. Our goal is to provide you with the flexibility and
control inherent in coding, while still making it easier to use and
faster to deploy. In Fastgen you sequence 'actions' to form rest
APIs and workflows through a drag-and-drop interface. Actions are
essentially functions that perform specific tasks such as sending
an HTTP request, checking for conditions or interacting with a
database. We support SQL for database operations, JSON for data
structure, and comparison operators similar to JavaScript for
decision-making in workflows. Everything you create can be deployed
and tested instantly in the platform and will be hosted for you.
Fastgen has a 'Debug Mode' that gives insights into the step-by-
step execution of workflows. This aids in pinpointing issues and
optimizing workflow performance. While some users have created
backends for full MVPs with us, others use the platform to build
automations for their data/operations teams. For example, one team
was missing functionality in Pipedrive for their sales team, so
they created a sequence of conditions and HTTP requests to the
Pipedrive API to create their own custom lead recycling process.
Other things our users have done include the creation of KYC
onboarding flows, a Chinese translation app using ChatGPT, an API
that retrieves a company's financial filings from the SEC for a
crowdfunding platform, a cron job that checks for the health status
of all other APIs in a code base, a categorizer of well performing
product launches, a sitemap checker for a SEO project, and others.
We would love for you to try out the platform and are excited for
your thoughts and feedback in the comments!
Author : cschreiber
Score : 203 points
Date : 2023-06-07 11:30 UTC (11 hours ago)
| crosen99 wrote:
| 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.
| cschreiber wrote:
| 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.
| mdaniel wrote:
| Wow, what was the motivation for using this abnormal syntax for
| array element indexing? https://docs.fastgen.com/getting-
| started/variables#indexing-...
| iamgopal wrote:
| Easy parsing ? Overall I like jinja syntax the most
| mdaniel wrote:
| You are misremembering, Jinja uses python syntax like a sane
| language so it would be `{% set foo = ["alpha", "beta"] %} {{
| foo[1] }}` not `{{ foo.[1] }}` like they use. I actually
| probably wouldn't have chirped about it if they used the
| alternate syntax (also supported by Jinja) of `{{ foo.1 }}`
| but the belt-and-suspenders of requiring the array brackets
| and the dot is just ... why?
| cschreiber wrote:
| `{{ 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
| cschreiber wrote:
| 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
| mdaniel wrote:
| I would suggest dropping the "you can use == or =
| interchangeably" since I doubt that adds as much value as
| "future syntax risk" it incurs
| cschreiber wrote:
| very valid point, ty!
| sidcool wrote:
| Congrats on launching!
| jayrosenkrantz wrote:
| this is awesome
| TobyTheDog123 wrote:
| 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.
| Tepix wrote:
| On Firefox/Mac, the animation of the word "backend" / "workflow"
| is broken somehow, the words disappear for a long time leaving
| only black.
| cschreiber wrote:
| Whoops, thanks for reporting - on it!
|
| Update: Fixed. :)
| jbeiss wrote:
| Looks cool! Will try it out later this week to build a ChatGPT
| plugin.
| cschreiber wrote:
| 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.
| Dave3of5 wrote:
| 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 ?
| cschreiber wrote:
| 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.
| jwmoz wrote:
| Nice product page
| easygenes wrote:
| 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/no...
|
| [3] https://unity.com/features/unity-visual-scripting
| cschreiber wrote:
| 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.
| instagary wrote:
| 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!
| cschreiber wrote:
| 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.
| makle wrote:
| Very cool!
| slig wrote:
| Congrats on launching! How do you differ from Windmill.dev (open
| source) / Airplane? Both backed by YC.
| debarshri wrote:
| I don't think the comparison is relevant. The platform is more
| close to a BPM than task automation and internal tools
| platform.
| rubenfiszel wrote:
| 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/co
| re_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.
| cschreiber wrote:
| 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.
| ushakov wrote:
| Is there a way to develop and run the APIs/workflows locally?
| cschreiber wrote:
| 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.
| 999900000999 wrote:
| 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.
| cschreiber wrote:
| 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.
| 999900000999 wrote:
| 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
| yla92 wrote:
| Looks awesome! What's it under the hood ? Is it gonna be open
| source ?(not expecting to be, just curious!)
| cschreiber wrote:
| 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.
| ilrwbwrkhv wrote:
| 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.
| cschreiber wrote:
| 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?
| jsunderland wrote:
| [dead]
| ilrwbwrkhv wrote:
| This does restrict me to build small toy apps. Because I do
| deep thinking and system building in my remote cottage
| without internet.
| ishbaid wrote:
| 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!
| fasteo wrote:
| 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!
| cschreiber wrote:
| 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.
| ushakov wrote:
| 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
| troebr wrote:
| 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.
| immortalloom wrote:
| Beautiful! Insanely easy to use
| heofizzy wrote:
| Congrats on the launch, really nice product! How does this differ
| from existing solutions like hasura or similar?
| cschreiber wrote:
| 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
| yajmch wrote:
| Congrats on the launch!
| aqme28 wrote:
| Deleted
| miketmahlkow wrote:
| I think this is the wrong post :)
|
| You probably wanted to comment in the other thread about the AI
| language teacher
| lerchmo wrote:
| Pricing is crazy. team plan with 2 million actions ($300 is
| already expensive for this) + $29k? This is not realistic in any
| way.
| chadash wrote:
| 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
| cschreiber wrote:
| 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.
| internetter wrote:
| 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?
| Dave3of5 wrote:
| Note in this case its actions not requests they charge for.
| If your endpoint does 10 actions vs one that does 1 it'll be
| 10 times the cost.
| nolanholden wrote:
| 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.
| conartist6 wrote:
| It's me. I'm building it.
| fiehtle wrote:
| This is the tool I was looking for! I can't wait to pair it with
| my NextJS project
| appleflaxen wrote:
| 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.
| cschreiber wrote:
| 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.
| andybak wrote:
| 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)
| cschreiber wrote:
| Makes a lot of sense. I guess the only requirement that
| would still be helpful is minimum password length?
| ceejayoz wrote:
| 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.
| cschreiber wrote:
| Very helpful, ty!
| [deleted]
| [deleted]
| jasfi wrote:
| What do you think of password-less sign-ins, e.g. email-based
| sign in or OAuth 2?
| ceejayoz wrote:
| The email-based "magic link" approach I'm seeing a lot more
| of lately, and I despise it.
| michaelmior wrote:
| 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.)
| danielvaughn wrote:
| Why do you despise it?
| ceejayoz wrote:
| 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.
| miketmahlkow wrote:
| 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.
| jsunderland323 wrote:
| Magic links are great because they essentially eliminate
| ATO attacks and allow startups to bypass SAML
| requirements by delegating to the mail provider. I'm 100%
| willing to forgo efficiency gains of passwords and
| managers as both a user and developer.
| ceejayoz wrote:
| > essentially eliminate ATO attacks
|
| They kinda _increase_ the blast radius of an ATO attack
| on your email account, though.
| ushakov wrote:
| Who is the target audience for this?
| cschreiber wrote:
| 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
| ushakov wrote:
| 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?
| cschreiber wrote:
| 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.
| Ferdinanddabitz wrote:
| We are using Fastgen for a couple of months now to automate a
| couple of internal workflows. For us it is a legit Zapier
| alternative. Can recommend checking it out.
| bezbac wrote:
| From the landing page, this looks great! Can I still connect to
| the underlying postgres database directly?
| cschreiber wrote:
| 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.
| johnsillings wrote:
| Congrats on the launch, guys!
| dgarnitz wrote:
| Wow! Amazing tool, love it!
| marcklingen wrote:
| 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.
| cschreiber wrote:
| 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.
| dizzydes wrote:
| 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? :)
| cschreiber wrote:
| 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 :-)
| claytongulick wrote:
| 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...)
___________________________________________________________________
(page generated 2023-06-07 23:00 UTC)