Architecture

Let me start off by stating that no architecture is a one-size-fits-all. This stack is what I would use for a full-featured and serious personal project (like this one). I would simplify it for smaller projects, and would replace some parts of it depending on the context if there are specific requirements.

My requirements

I want this stack to:

Be able to handle data becoming more complex and relational over time.
Be serverless for a great scalability, pay only for the traffic I get, without configuring servers.
Give a full-featured rich user experience on the front-end.
Use only one language for the whole stack, to take advantage of isomorphism and keep things DRY.
Be SEO-friendly, Open Graph-friendly, and crawlable in general.
Provide a great developer experience via tooling and user-friendly services.

And you might not need any of that! Making a private internal app? No need for SEO, an SPA is simpler. Your team has Python or Ruby developers? Drop the whole Node back-end. Don't need much interactivity? Drop React and use jQuery or Vue. Need websockets? Say bye-bye to serverless functions. Making a chess game? Use a document-oriented database, not a relational one. It all depends on your needs 🙂

So, given my very specific requirements, this stack is what I personally consider the state-of-the-art.

Diagram

I know it looks daunting, particularly if you come from a monolithic framework background. But it follows the Unix philosophy of having each piece do one thing well, which means each piece is swappable for an other if it becomes a better fit. And that's something I really appreciate in the JavaScript ecosystem. It's fun for me to figure out what my favorite pieces are.

This project documents the reasoning behind each choice, and how to set things up. Each "chapter" of this documentation is the consequence of the decision of the previous ones. That's why I do not talk about any Vue library since I picked the React path for instance. It is essentially a flattened decision tree.