Ask HN: What would be your stack if you are building an MVP today?

rails, because it has so much baked into it

htmx & hyperscript because I made them

Thanks for making Avo! I'd been building something similar in the application I'm currently working on and it was nice to have something that already figured out much of the hard stuff to replace my shitty implementation.

AWS + Node.js + Lambda + Aurora + API Gateway + ElasticCache + CloudFront + SQS + MediaLive + MediaConvert.

We scaled up to hundreds of thousands of viewers + telemetry worldwide with no issues. Should be breaking into millions real soon now with our next few onboarding's.

We also have an express backend for the UI that's running on some puny EC2 instance.

I recently built a Web based MVP and used Node-Red as backend. Frontend was python+flask, postgres and everything dockerized.

I've mainly used sinatra and rails for Web apps and always found it difficult to define a clear api on which the frontend was based on (I.e in order later to build ios or android apps off).

Using Node-Red forced me to build an api for the frontend, the frontend has no direct contact with postgres.

Plus I found it to be more flexible than directly coding when I wasn't even sure what the database schema would look like.

Database modelling was done with pgModeler, I.e. No migrations and more pgsql functions and triggers.

Some potential reasons:

1. The data layer, if you want a high-quality ORM and migrations

SQLAlchemy + Alembic (or Django ORM + its built-in migrations) are battle-tested systems that I trust will scale to large teams and not break my data.

If you're more of the persuasion to write raw SQL, or to just use a SQL query builder, Python is less of a draw these days (although SQLAlchemy's query builder is quite nice and can be used independent of its ORM).

2. Ties to the data science + machine learning universe

If your back-end intersects with these in ways that are not cleanly separable into services, Python might be a good (or the only) option. Even if you can cleanly separate, you're effectively committed to managing Python on the back-end.

3. Stability

For good and ill, the JavaScript ecosystem churns far more rapidly.

4. Familiarity

To your point: there's nothing wrong about optimizing for creature comforts and/or velocity from just having done it before and fired the foot-guns.

---

I agree that using a single language provides an advantage at the API boundary. Curiously, my experience is that most modern javascript frameworks (like NextJS) don't have a lot to say about how to structure this in practice. Maybe that's fine, but I'd love to see some opinions emerge in the ecosystem.

Amongst other things, I typically want to:

- Share types (typescript `interface`s, etc.) between the front-end and back-end (while avoiding accidentally bundling back-end code into the front)

- Have run-time types (via `zod`, `io-ts`, whatever) for (at minimum) API request structures so I can validate my inputs

- Have a story about how API validation failures are shipped back to the client (and how the client exposes them to the users, e.g. error messages when filling out form fields)

- Differentiate between API types and my underlying data model (the `User` in my database is somewhat to very different from the `APIUser` I ship to my client)

In the python universe, Django, Flask, and FastAPI all have well developed opinions about run-time types, validation failures, and API types vs. data models.