The RND Stack
Last week, ZEIT released a new framework for Universal React applications: Next.js. Unlike previous attempts, Next provides a complete solution for rendering and routing React applications in a single dependency (transitive dependencies notwitstanding, of course). No amount of configuration is required for Webpack, or Babel, or React itself. Furthermore, no convention is imposed on React beyond the way Next.js handles routing. It's an incredibly elegant solution.
What should we use for business logic and communicating with the database, then? Rails.
Where the front layer can benefit from "just enough" flexibility as provided by Next.js, API tiers are best served by convention. Where the front layer can take risks and dodge the rigor of test coverage (though React and Redux benefit from their rich testing story), the API tier is the primary line of defense against data corruption, leakage, and loss. Rails remains a mature solution in this domain; I know no comprehensive argument that it's done anything but continue to prove this to be true.
Not to leave out some of the nuanced practicalities of these suggestions, I propose the name "RND Stack" for two reasons:
- This is a stack to start with. The best stack for your application is the one that's already providing value, but the zero-to-sixty story of both Next and Rails is more than sufficient for an expedient start to any project. Where better to do R'n'D than on the RND Stack?
- The D: Docker. The biggest operational risk to splitting resources
across Rails and Node is the deployment environment, whether local or remote.
On one hand, maintaining two complete environments (runtimes, OS dependencies,
etc.) is a nightmare. On the other, Docker (or any imaging solution) provides a
better byte-for-byte identity guarantee than either
npm-shrinkwrap.json. On a foot, Docker brings with it a rich suite of tooling for orchestration and management: Terraform, Triton, Kubernetes, etc.
Interested? Let me know. Next up, assuming there's interest? Demo.