Depends on the project. If its monetary, you need to approach it with a business mindset and the Domain Drive Design standard works well here (although it can be overkill at times)
For everything else I think design should drive the backend development. Annotate some figma mockups and you can build your schema off of that.
I've read a couple answers on here regarding the situation, but they were all from ~3-5 years ago. The landscape has probably changed quite a bit since then. I feel the market is over-saturated and clients outsourcing to ultra-low bids is a real hurdle. Every freelance site has thousands of these bids. Can be discouraging at the least. Fingers crossed!
I'm curious. I've used GoLang's simple web server before, but I'm interested in what GoLang provides over Node. To me, it seems Go is especially well suited for microservices and tasks requiring a lot of CPU intensive processes while Node is better when working with small requests over the wire.
In other words, what is Go's main selling point in competing with Node in terms of its http server, TCP sockets, etc...
Can Go's awesome concurrency patterns be used to optimize server requests? Can it be well utilized as a proxy?
React and postgres are great. I think you already have a solid stack with just those two. React offers a lot of what a large framework can eliminating a lot of the fluff things like Angular seems to include. That being said, I don't use frameworks and code in pure TS -> JS these days and borrow things a specific project needs from more popular frameworks, tweaking it for what I need.
Meteor is good for prototyping and getting something up fast. I find it very amateurish and highly abstracted. If you're a green developer, you aren't going to learn anything using Meteor. Also, I believe support for this framework is dying. Its highly, "Meteor's way or the highway"
Express is more just glue between your front end and your server/backend that uses Node as its adhesive. Its pretty great for eliminating a lot of boilerplate you would otherwise run into.
Depends on how advanced you want your routing to be I can see going with the from scratch rout, but that means you'll need to spend time writing unit tests..
You might as well fork and delete/modify a bunch of code.
They keep warm containers of your instance in their orchestration