Yea, sorry, that was worded a little poorly. My point was just from a monolith you are smarter to add caching first before breaking it up anyway. So monolith will get you to point A on the map, adding caching will usually get your further to say point B, then finally you'll need to break the application apart to scale further. That was my point.
Nothing evil about a monolith when you are starting out. I'd argue it is the correct way to start out in fact.
Looks to be pretty similar but it may be better for asynchronous applications since it runs on ASGI. The only thing I would be hesitant about is sometimes with newer frameworks it takes them a while to gain maturity and a robust collection of plugins and community support.
These are a no-go. Why should I use a proprietary solution when there are superior free open source offerings? Sure it's more effort to spin up an aws ec2 instance but that's very well worth it. I then have full control over my database and I don't have to deal with proprietary sh*t.
> RPC-named express routes is more than sufficient
Yes RPC is exactly what I was looking for. It's super simple. I don't need all that REST and GraphQL stuff.
> REST solves
Honestly, I don't understand what REST solves.
> over-engineering a simple app can lead to greater confusion.
Yes simplicity is key.
> RPC-named express routes is more than sufficient
Actually for Node.js there is Wildcard API[1] which I discovered yesterday. It's even simpler than express routes.
