Sign in

Separation from Milky Way. David Monje

Separation of Concerns in Routes, NodeJS

Trying to use MVC methodology, b̶u̶t̶ ̶n̶o̶t̶ ̶m̶u̶c̶h̶, let’s talk about each letter in the acronym. Beyond that, I gonna show you my vision why should be more letters in there, even to simplest applications.

— We gonna shuffle the presentation of MVC acronym starting from…

The class Controller should, just to write or read from the database, b̶u̶t̶ ̶t̶o̶ ̶m̶e̶, business rules should not be in there because of the separation of concerns.

Using REST-full API, is not interesting require whole pages from backend, so the Views maybe don’t have much meaning, but putting the static pages in there, could change that. Everything is required from some frontend, so It’s clear why we should have the letter V in MVC.

The M of Model never makes me any sense using NodeJS until I started to use SQL in backend. At least until I found a pretty useful thing to put in there (even using NoSQL), the validations! I think Celebrate is awesome tool for validation in NodeJS, using Joi and all that stuff. So it’s usual to think in one validation per route, but we gonna mesh things out and introduce a n̵e̵w̵ way to do this, we gonna use two validations per route.

A business rule is a method that does anything with the data to transform that in information, m̶y̶ ̶v̶i̶s̶i̶o̶n̶. Talking about REST-ful APIs, to me is pretty clear that most of the transformation, summarizing, t̵r̵a̵n̵s̵f̵e̵r̵ ̵f̵u̵n̵c̵t̵i̵o̵n̵, happens in backend. Sometimes for abstraction, for optimization (the backend could be more capable to realize some tasks faster), for language problem (part of backend could be done in another language, not javascript), for security (environment secrets could be robbed and compromise the business) o̶r̶ ̶j̶u̶s̶t̶ ̶b̶e̶c̶a̶u̶s̶e̶ ̶t̶h̶e̶ ̶t̶e̶c̶h̶n̶i̶c̶a̶l̶ ̶l̶e̶a̶d̶ ̶i̶s̶ ̶a̶n̶ ̶a̶w̶e̶s̶o̶m̶e̶ ̶w̶i̶z̶a̶r̶d̶ ̶a̶n̶d̶ ̶w̶a̶n̶t̶ ̶t̶h̶a̶t̶ ̶i̶n̶ ̶t̶h̶a̶t̶ ̶w̶a̶y̶.

You should agree with me, about the capability of that rule be immense, with much complexity and even encapsulating in one class, if you call them in the controller, gonna pass to the controller a responsibility that is not the main focus of it. In case of a thrown exception, the first target will be in the controller.

So, I purpose to create a new letter and a new directory to put all business rules in there, the name of the directory could be a rule ,and the letter in the new methodology should be R.

Rule, add a personalized date with moment timezone module.

In nowadays validation files are called for DTO acronym of (Data Transfer Object), so we gonna use D for name the validations in the new methodology.

DTO using Joi exporting schemes to Celebrate.

The route name its self a pretty awesome name, and summarize much for beginners, and this is a great goal. The concept of routes in Express with each middleware passing the parameters (request, response, next) to another, is awesome. B̶u̶̶̶t̶̶̶ ̶̶̶t̶̶̶o̶̶̶ ̶̶̶m̶̶̶e̶̶̶, the routes should be a map of all that happens in all microservices in that project, without any complexity and respecting the separation of concerns.

Thinking about remove complexity, the routes could be much messed with validations. So thanks to this Mr. Harrison Kamau on this article, I could found how to separate Celebrate from validations, even though I couldn't put Celebrate inside of some of the validators to become more similar with Clean Code (if you know to do this, send me a PR).

Important: If you require in routes, DTO, Rule and Controller as classes with static methods you don’t need (and can’t) instantiate the class. Your code gonna be more cleaner.

Routes become a map with the split of validations, rule added and two validations.

Two Validations
Initially, I just thinking in one validation, with it doing the validation of parameters that comes from frontend, and next the added parameters from business rule. But thanks to Mr. Sebastián Alvarez, that write a phrase in below on this article, which made me change my mind.

Avoid Invalid Requests to Your Express.js Server Using celebrate”

Initially, I just think about validation to not mess up the business rules, but with that, you don’t gonna even wait for an error, you gonna have the error faster as you can, if you pass wrong types or even parameters named wrong. If I didn’t put validation in the first chain of command, the user gonna have to wait for the error after business rule. T̶h̶e̶s̶e̶ ̶d̶a̶y̶s̶ ̶I̶’̶v̶e̶ ̶b̶e̶e̶n̶ ̶p̶a̶s̶s̶i̶n̶g̶ ̶f̶o̶r̶ ̶m̶u̶c̶h̶ ̶o̶f̶ ̶t̶h̶e̶ ̶w̶a̶i̶t̶i̶n̶g̶ ̶e̶r̶r̶o̶r̶ ̶p̶r̶o̶b̶l̶e̶m̶,̶ ̶s̶o̶ ̶I̶ ̶c̶a̶u̶g̶h̶t̶ ̶f̶a̶s̶t̶e̶r̶, ̶t̶h̶e̶ ̶i̶d̶e̶a̶,̶ ̶a̶n̶d̶ ̶d̶e̶c̶i̶d̶e̶d̶ ̶̶b̶r̶i̶n̶g̶ t̶o h̶e̶r̶e̶.̶

So, maybe you just have caught the why we need two validators, is just because the idea here, is adding the parameters that will return from business rule to request parameters.

I never, look in a good way for validations in the database, s̶i̶n̶c̶e̶ ̶f̶r̶o̶m̶ ̶a̶c̶c̶e̶s̶s̶,̶ ̶a̶ ̶p̶r̶e̶t̶t̶y̶ ̶f̶a̶n̶ ̶o̶f̶ ̶j̶a̶v̶a̶s̶c̶r̶i̶p̶t̶,̶ ̶l̶e̶t̶,̶ ̶a̶n̶d̶ ̶c̶o̶n̶s̶t.

These days I’ve met a database using in PostgreSQL that stores or read just using functions in PL/pgSQL, and I asked why having validations in the database, summarizing, I added a wrong validation (varchar to a number), and we spend 5 hours adding seven lines to production, and the error was disconnected at all with the problem. After that, it’s pretty clear to me that there is no gain validating anything in PL/pgSQL or in any database.

Later, I told the history to my girlfriend and ask her “Why two validations?” and the answer was “Because it is!”, and I asked again “Why not 10000?”, and now she answered kindly “Because exists two modules, backend, and database.”. She was right, but do the validation in a language like PL/pgSQL, was a complete nightmare. So if you have to do, do it in NodeJS using Celebrate.


  1. You must remove the parameters that will be not stored in the database, or not used in a query on the controller, to avoid errors (this parameter is not allowed) from Celebrate.
  2. You should validate each parameter used in the controller.

The methodology
The full methodology is focused in redesign the routes. So the route should be composed by:

Flowchart of idea.

The name
Based on the description above, the full name of the new methodology should be, t̶u̶n̶d̶u̶n̶t̶u̶n̶d̶u̶n̶t̶u̶n̶d̶u̶n̶, DRDC (DTO Rule DTO Controler).

Final observation
Maybe not even all routes should be in DRDC way, which may don’t make any sense in delete routes, if you don’t have authentication, like I didn’t have in this little demonstrated project.

Just to complement, more files of this project… The whole project is in below on Github.

Migrations using Query Builder Knex.
Cloud, have all configuration of database.
Controller reading, writing and deleting on db.
App express.
Server listener.

Fork this, in Github.

Electrical Engineer and Full Stack Developer

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store