Just curious to see the different answers. I find myself constantly thinking about what the best way to quickly build a good + scalable product from the get-go is. With things like Supabase, Firebase, AWS, Vercel, Netlify, Hasura, etc, I find it hard to make up my mind.<p>I'm currently defaulting to React + Next.js + Vercel for the FE, and Node.js + GraphQL + Dynamo + Lambda for the BE (All TypeScript).<p>I feel like there might be other stacks that people find better to quickly build stuff out, so just wanted to gauge that.
It would depend a lot on what I was doing.<p>If it was ordinary web application software I wouldn’t disagree with your FE choice but would probably stick with the JVM on the back end unless I felt really good about the cloud native route (dynamo + lambda) for a db they say you can’t get fired for picking Postgres today but I am one of the few and the proud who likes arangodb.<p>Personally I have some interest in A.I. work which might involve PyTorch, Tensorflow or something like that. Also I am interested in embedded, for that I wish I could give up on C and just write assembly.
I would use .NET 6 (aka cross-platform .NET Core) for the backend, and I would do as much server-side rendering, simple forms, and the PRG pattern as I can. Minimal javascript, JS frameworks (maybe React) for highly-interactive pages. Standard RDBMS (likely Sql Server), with some initial planning on how to achieve horizontal scale as the clientbase grows, but not get too lost in the weeds on planning for a future that may never come. Maybe sprinkle in some Redis, a cloud queue/service bus, and some blob storage as needed.
Dynamo is great until you have a lot of traffic. Unless you design from the ground up to avoid hot partitions, you’ll get throttled pretty hard. If you designed to avoid that, great. But you’re going to blow a hole in your pocket.<p>I worked at Amazon for 10 years. For any non Amazon project, I use Postgres. It’s a damn Swiss Army knife.<p>You don’t need GraphQL by default. It’s just another service. Client code generation is nice I guess. But unless you’re trying to join together 10 services and simplify discovery of schemes and APIs - in a large scale project - I’ve found it to be overkill.<p>On the front end, pick whatever. Even Angular 1x probably works fine still (dunno about any known major issues).<p>For back end, I’d use a JVM language, mainly because fine tuning it isn’t too bad, and there’s a credible library for just about anything. Also because that’s what I’m most comfortable with from my time at Amazon.<p>For any serious project, I’d avoid tying yourself to AWS or any specific cloud provider.
Youre right speed is king!<p>Like most 0 to 1 it depends on how little tech I can get away with in the tech stack.<p>For example <a href="https://cashflow.vc" rel="nofollow">https://cashflow.vc</a> is csv files on gumroad. It was the minimum viable version to test if people would pay for it. Will likely upgrade it to a combination of nocode tools next (paytable is the frontrunner)<p>However for a Crypto related project im going up one level to Nextjs + Hasura as it gives me just enough control to meet all the user requirements but still gives me a development speed boost over if I grabbed nodejs, python or elixir for the backend.
I learned a lot building <a href="https://sqwok.im" rel="nofollow">https://sqwok.im</a> and am currently building a brand new project using most of the same stack (use what you know!).<p>The project calls for a consumer mobile app with an administrative web app.<p>The stack:<p>- Cloudformation all the things (front/back/deploy/routing/etc)<p>- Python Starlette rest api<p>- Dynamodb<p>- Cognito (not using their web ui)<p>- Ember.js for the web app<p>- React-native for the mobile app<p>Using whatever tech you're familiar with is the best bet to getting a project off the ground quickly in my opinion.
Take the one you already know! Time is your most precious resource. Use it to validate the business or build stuff, but don’t spend time learning new stuff.<p>Plus your goto stack sounds fine.