The Monstrous Monolith and Its Downfall
PreviousChapter 4: Structured JavaScript ArchitectureNextLayered/N-Tier Architecture: The Unpopular Proven Way
Last updated
Last updated
In software engineering, a monolithic application describes a single-tiered software application in which the user interface and data access code are combined into a single program from a single platform.
-
Below is a Monolithic application in which most of the application is neither horizontally distributed nor vertically layered. There is all but one application and one layer. There are few levels of abstractions, and most of the time, it could just be one single file.
The JavaScript community is notorious for not having structure in their code and not following any design patterns or principles. We are known for getting things out the door quickly and for not having to think too much about scaling to more than just a 1 or 2 man team. The question is, why?
Unlike the developers in the Java community or even the Ruby community, we as JavaScript developers tend to want to get things done very quickly. And due to the easiness and the nature of being able to spin up a Node.js application with express in a matter of seconds, most projects start off as a monolithic application. However, as a project matures, so does the complexity of the code.
From my experience, these are the three most common things that happen to most node.js projects:
Everything is put into just one file, usually named app.js.
No abstraction layers and encapsulation of any sorts; I mean we just have one file called app.js anyway, so why bother.
People don’t break things down, they magically forget to use built-in features like express' middleware feature and forget to create re-usable helper functions.
When was the last time someone asked, "Which website do you use to learn JavaScript?", and your answer being, "Google, duh!".
The sad fact is that there is no real central authority for learning JavaScript and Node.js. Most of the material out there are by third party developers and open source contributors. Rarely do we see a set of standards that are reinforced by one central source, but rather, a set of guidelines and standards become adopted through individuals in the community over time. Take Microsoft for example, they have official documentation on the C# language.
They also have official guides on how to structure code in the .NET ecosystem.
Not only that, they have a bunch of certifications and courses you can take as well.
The same goes for Oracle when it comes to Java. Oracle provides official training for their products through their certification and training courses, they are all under the umbrella of Oracle University. They have the ever so popular Java certifications like the OCA (Oracle Certified Associate) and OCP (Oracle Certified Professional). They also provide very well documented tutorials on learning Java if you wish to learn it from an official source.
Here are a list of (mostly well known) books:
Domain-Driven Design: Tackling Complexity in the Heart of Software, by Eric Evans
Clean Code: A Handbook of Agile Software Craftsmanship, by Robert C. Martin
Design Patterns: Elements of Reusable Object-Oriented Software, by Erich Gamma, Richard Helm, et al.
Head First Design Patterns, by Elisabeth Freeman, Kathy Sierra, et al.
Cracking the Coding Interview, by Gayle McDowell
Do you see a pattern?
If it is not so obvious, all these books are written in either Java, C#, or C++. To put it in more general terms, all these "classics" are written from the object-oriented paradigm. This isn't to say that there are no good JavaScript books, but the lack of literature when it comes to structuring JavaScript code over the years has been a big issue in the community.
Imagine as a Java Developer trying to learn how to write "clean code". There are a plethora of books and resources that teach you how to write better code. Now imagine a JavaScript Developer who just graduated from a coding bootcamp. He would have to scour the web trying to find the correct book only to find that most books that talk about structuring code are written with a traditional OOP language.
Even the annual conferences like and are held officially by each of the respective companies. This is not to take away anything from , but having a central authority that tells the developers what is "right" or "best practice" is what the JavaScript community lacks in comparison to the other communities.
