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
Launch HN: Fastgen (YC W23) – Visual Low-Code Backend Builder
61–70 of 118 posts
Re: Launch HN: Fastgen (YC W23) – Visual Low-Code Backend Builder
#62I 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…
Re: Launch HN: Fastgen (YC W23) – Visual Low-Code Backend Builder
#63Earlier 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.
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
#64Like 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
#65Re: Launch HN: Fastgen (YC W23) – Visual Low-Code Backend Builder
#66Pricing is crazy. team plan with 2 million actions ($300 is already expensive for this) + $29k? This is not realistic in any way.
Re: Launch HN: Fastgen (YC W23) – Visual Low-Code Backend Builder
#67Earlier 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)
Re: Launch HN: Fastgen (YC W23) – Visual Low-Code Backend Builder
#68Earlier 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.
Re: Launch HN: Fastgen (YC W23) – Visual Low-Code Backend Builder
#69Earlier 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?
> 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
#70Earlier 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…