While you may consider this blog as a standalone transcript of our talk, we also welcome you to check out the slides linked here to follow along.
Rails 3.1 made “assets first class citizens”.
This also meant your User Interface…well, it was just an asset. Which was probably fine for smaller Ajax powered interactions and some DOM manipulations and fancy animations.
6 years later, with the release of Rails 5.1., we finally got a promising solution with the integration of NPM and Webpack to handle our UI dependencies.
This might not be the hippest approach nowadays but for simple UI/UX requirements, it’s definitely one that is less complex and requires less JS skills.
While, in the classic MVC layered application, features tend to distribute over all layers, this also applies to the Modern Rails strategy — and therefore requires some discipline to keep the codebase clean. But with easier testability (by having everything in one place) comes good maintainability.
On the plus side, with this strategy your application supports usually any device that can show HTML.
Rails is still a very good framework for building web applications and with the new versions it’s even easier to integrate rich client-side frameworks like React, leaving us with the strengths of both ecosystems to build clean solutions even for complex interactions.
But this strategy is certainly one that comes with trade-offs.
You always need to decide which part of your application is responsible for which part of your business logic. Especially when you’re building very complex user interfaces with many dependencies.
Still, we had a positive experience applying this strategy while modernizing the frontend of a really big legacy application. The barrier when integrating component based design, thus staying flexible, is very small.
SPA with Rails API
Being the most flexible and advanced approach, this comes with complexity on a variety of topics, including a harder Setup, development, testing, deployment, security and/or error handling for your API layer.
This strategy might make sense for very big teams with separate departments and parallel projects.
Summed up: Which approach for whom and what?
Your mileage may vary, and we don’t say it’s not possible for a team of three to go the SPA + API way … but as a rule of thumb we would recommend to challenge decisions against the following graphic.
In the end it’s a matter of preference or business constraints. Don’t just follow the hype and build microservice architectures and SPAs just because “everyone does it.”
A lot of very large companies are super successful with a much simpler architecture. 🙂
The talk and the slides were done by Marco and Jakob.
Want to talk about Rails and React in more details? Check out our Twitter or visit our website. Let’s chat ❤