Live data from Hacker News

Launch HN: Fastgen (YC W23) – Visual Low-Code Backend Builder

news.ycombinator.com

61–70 of 118 posts

Re: Launch HN: Fastgen (YC W23) – Visual Low-Code Backend Builder

#61
post #56
post #54

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,…

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.

Re: Launch HN: Fastgen (YC W23) – Visual Low-Code Backend Builder

#62

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 workflo…

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.

Re: Launch HN: Fastgen (YC W23) – Visual Low-Code Backend Builder

#63

Earlier quoted context omitted.

Why do you despise it?

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.

Re: Launch HN: Fastgen (YC W23) – Visual Low-Code Backend Builder

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

Re: Launch HN: Fastgen (YC W23) – Visual Low-Code Backend Builder

#66
post #43

Pricing is crazy. team plan with 2 million actions ($300 is already expensive for this) + $29k? This is not realistic in any way.

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.

Re: Launch HN: Fastgen (YC W23) – Visual Low-Code Backend Builder

#67
post #25

Earlier quoted context omitted.

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?

Re: Launch HN: Fastgen (YC W23) – Visual Low-Code Backend Builder

#68
post #20

Earlier quoted context omitted.

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

Re: Launch HN: Fastgen (YC W23) – Visual Low-Code Backend Builder

#69
post #25

Earlier quoted context omitted.

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.

Re: Launch HN: Fastgen (YC W23) – Visual Low-Code Backend Builder

#70

Earlier quoted context omitted.

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…

Very helpful, ty!
Post reply on HN