Microservices, Javascript Frameworks, and Testing


Ruby developers are in a war of ideology over monoliths and microservices. As dramatic as it sounds, this war is ancient like one set of developers on a side of the room yelling “Emacs!” and another set on the other side of the room yelling “Vim!”

In this podcast from February 2020, David Hanmier-Hanson takes a while to riff on some of the more meta trends that are seen in the industry today. This tension between the old and the new will always exist. I saw it in 2005 when the .NET developers all got out of work. React is not the worst thing to have happened to web development. It is often more complicated than Rails, and slower, so in many (most?) cases he’s probably right you don’t need any thick client app. However, as interactions move more and more into the front-end (think Slack, TikTok, Instagram, any new app in today’s modern age), Rails Turbolinks isn’t going to last– we just need more app code on the front end and there’s nothing wrong with that. There’s plenty of ways to build beautiful code that creates developer happiness in React and/or the front end.

“There’s TDD proponents that say, if you write code that’s easy to test that means it’s better code…. BS! I did a whole series with Martin Fowler and Kent Beck on this topic — back in 2014 I provactively pronounced ‘TDD to be dead’…I pronoucned it to be ‘dead’ in the Nietzsche sense of the word… [when[ Nietzsche said ‘God is dead’ — it’s not that God doesn’t exist, it’s that he doesn’t hold the central focus in our universe anymore.. and that’s how I felt about TDD.”


DHH spends a lot of time describing how to think about testing.

keep your eye on the prize

Focus on 1) what you’re actually testing, and 2) do the tests actually catch regressions. The reason that this tension is important is that Rails currently exists in the critical dialectic:

On the one hand, the best and the brightest devs will always write specs. On the other, the person paying you to write code will never understand why they should pay for them.

Jason Fleetwood-Boldt

DHH says:

“Actually I’ve stopped calling it “unit test,” what we call it now? We call it model tests cause some purists took offense to the fact that when we do unit tests in rails, in particular, we often end up talking to the database, right? Which is a big no-no when it comes to unit tests. Instead, isolate all dependencies one by one.

“And, um, Test only in isolation, both for speed and for repeatability and blah, blah, blah. And I just went like, do you know what? I’m not interested in that. Those kinds of tests do not reveal anything interesting for me.

“Uh, I want to be able to test all the way down to the database layer when I test my models, because that’s where I often find the bugs or the issues or whatever. Uh, and I don’t really like mock or stub data. I find that it often introduces all sorts of bugs. Then I need to deal with those and da da da da da.

DHH continues

“We write some model tests and I think model tests are great. And then we also write some sort of controller tests which happened at the layer above. And those controller test also do not stub anything out. They actually call the real models and those real models call real database calls and so on. And then above that we whole system tests that flex the system for the job and driving a browser and so on and so forth. I don’t need to replicate everything down to a unit test level because I have to level of confidence than I need or want in my code. So we’re done.”

What DHH is saying here: 1) Regression, 2) speed of the test run, and 3) speed of the software development (these are related). Because if you write too many tests, you actually can hurt yourself in the long run. But if you commit features to master without specs, you’re a crazy person. So it’s the right balance that gets it just right.

If you commit features to master without specs, you’re a crazy person

Jason Fleetwood-Boldt / TheRailsCoach.com

the faddism of microservices

Rails apps get big. When they get large, we call them “Rails monoliths.” DHH has famously called them “majestic monoliths” meaning they are, indeed large, and that’s OK: they are beautiful in their way. Although his way does not seem prevalent, Rails does continue on.
For the Rails developers, microservices are seen as a faddism the is the privilege of the large company— the Amazons, Facebooks, Microsofts, Google Cloud Platform (all heavily microservice architecture environments)— because when you have thousands of developers, it makes sense that you would need a separation of concerns, literally, for orchestrating all the microservices together. The Rails diehards see microservices as to software development what Dadaism was to modern art — a cacophony of interoperating services all responding at different times, all giving the end-user an everywhere/nowhere experience. We are both present in our internet experiences and, as we present them to the user, making dozens and dozens of interoperating microservice connections. Art? the Railsista will say, this isn’t art, this is chaos.

Unfortunately for the Rails world the Javascript world will march forward, React and VueJS and Angular as the modern apps push the needs of software further and further. As the demands and expectations of the end-user go up, the Rails apps will adapt. Although Rails will not go away, it will become less modern, like 70s decor — tacky yet comforting in this way.

The Rails diehards see microservices as to software development what Dadaism was to modern art — a cacophony of interoperating services all responding at different times, all giving the end-user an everywhere/nowhere experience.

Jason Fleetwood-Boldt / TheRailsCoach.com

the --api flag

Most devs tell me the Rails-XYZ combination, where XYZ is any of React, Angular, VueJS, etc— is where most modern apps are moving towards. That is, as explained in the Rails guide here, you can use the --api option when running rails new. This strips Rails of most of its view and rendering capabilities and lets you build an API-only Rails app. You have the power today to use Rails in the way that suits you.

no answers

In the quest of Rails, there aren’t really any answers: only more questions. What will become of an endpoint? What is a service if it is bundled into a larger context? How big is a monolith and how big is too big? Can innovation happen with small, more self-directed teams?

0 Replies to “Microservices, Javascript Frameworks, and Testing”