Legacy of Play
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.
On its first day of release, developers piled onto Guillermo, one of the creators of Next.js, to add custom server-side logic. While this will no doubt be a useful feature, I think it continues to miss the point: this is an opportunity to cleanly separate concerns between services, with technologies to match. The advantage of "Universal JavaScript" is not the opportunity to run our UI rendering alongside our business logic. Instead, it is the opportunity for UI Engineering to take complete advantage of the server independent of the business logic.
In short, Next.js is the ideal "front layer" (also referred to as the "presentation layer") solution. [For more discussion of what that entails, see here and here.]
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
Gemfile.lockornpm-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.
2nd of November, 2016
