The RND Stack

RND Logo

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:

Interested? Let me know. Next up, assuming there's interest? Demo.

More Posts