RESTful Node.js: A Structured Approach
  • Book Cover
  • About the Author
  • Links and Resources
  • Part I: The Why
    • Foreword
    • Preface
    • Chapter 1: Introduction
      • The Rise of REST and Distributed Systems
      • Problem #1: Structureless Design, Structureless REST
      • The Emergence of JavaScript and Node.js
      • Problem #2: Structureless JavaScript, Structureless Node.js
      • Behold, the Solution: A Structured Approach
      • Summary
  • Part 2: The Theory
    • Chapter 2: REST Origins
      • A Brief History of the Web and the Birth of REST
      • REST vs. HTTP
      • REST - The Abstract Web Architecture
      • HTTP - A Peak at REST's Concrete Implementation
      • What does it mean for an API to be RESTful?
      • Measuring "RESTfulness" with Richardson Maturity Model
      • Pragmatic REST vs Dogmatic REST
      • Summary
    • Chapter 3: RESTful API Design Guidelines and "Best Practices"
      • Theories vs. Principles vs. Guidelines
      • URI Design
      • Method Verbs
      • Status Codes
      • Representational Design
      • Metadata Design
      • Versioning Strategies
      • Security Considerations
      • Documentation
      • Case Study: GitHub
      • Summary
    • Chapter 4: Structured JavaScript Architecture
      • The Monstrous Monolith and Its Downfall
      • Layered/N-Tier Architecture: The Unpopular Proven Way
      • Microservices and Distributed Computing: A Popular Misdirection
      • Summary
    • Chapter 5: The 8 Step Recipe
      • Route Name (URI)
      • Input Request
      • Middleware
      • Validation
      • Domain
      • Events
      • Output Response
      • Test, Refactor, Document
      • Summary
  • Part 3: The Code
    • Chapter 6: Introduction to the Bookstore API
      • The Bookstore API Endpoint Specifications
      • API Design and Code Structure
      • Project Setup
      • Summary
    • Chapter 7: Retrieving Books from our API
      • Retrieving All Books - Planning
      • Retrieving All Books - Implementation
      • Retrieving A Book By ID - Planning
      • Retrieving A Book By ID - Implementation
      • Summary
    • Chapter 8: Adding Authentication to our API
      • Registering the User - Planning
      • Registering the User - Implementation
      • Logging the User In - Planning
      • Logging the User In - Implementation
      • Getting Authenticated User - Planning
      • Getting Authenticated User - Implementation
      • Summary
    • Chapter 9: Adding the Create, Update, and Delete Operations to our API
      • Creating A Book Listing - Planning
      • Creating A Book Listing - Implementation
      • Updating A Book Listing By ID - Planning
      • Updating A Book Listing By ID - Implementation
      • Deleting A Book Listing By ID - Planning
      • Deleting A Book Listing By ID - Implementation
      • Summary
    • Chapter 10: Testing our API
      • Testing the Request
      • Testing the Middleware
      • Testing the Validation
      • Testing the Domain
      • Testing the Event
      • Testing the Response
      • Testing the Controller
      • Integration Test
      • Summary
  • Conclusion
    • Final Words
  • Bonus!
    • Refactoring to HATEOAS
  • Appendix
    • Sources & References
Powered by GitBook
On this page
Edit on GitHub
  1. Part 2: The Theory
  2. Chapter 4: Structured JavaScript Architecture

Microservices and Distributed Computing: A Popular Misdirection

PreviousLayered/N-Tier Architecture: The Unpopular Proven WayNextSummary

Last updated 3 years ago

When you go to a tech conference, you'll likely come across topics related to . In fact if you were to type "distributed architecture" into YouTube, would find a plethora of conference video recordings with hundreds and thousands of views.

What about if you tried typing in "layered architecture"? First, there would be less people talking about it in live conferences. Second, you would see a significantly less number of views on those videos. Third, nobody would type that in since it's so old and boring.

But wait… why is this the case, even though layered/n-tier architecture is indeed the more common architecture. In fact, we can agree that layered architecture is most likely more "popular" than any other architectural pattern. Almost all projects use the layered architecture in their application structure. As mentioned before, the most popular frameworks like Rails, Spring, ASP.net MVC, Laravel are all MVC and layered-based.

The problem is that microservices has been the most talked about topic of the previous decade. It is the hot topic, the shiny new object, and the buzzword in the past 10 or so years.

You want to know why? Here's why.

It also is interesting that these companies, who talk about these topics, also expect their future employees to know about them as well. In fact, all of these FAANG companies and their interview processes' involve a "Systems Design" portion. What is this "Systems Design" part of the interview about? It's about concepts such as: load balancers, caching, data partitioning indexes, redundancy, and replication. Notice how all these concepts are all about distributed systems and how to scale a system up.

On the other hand, If you hear someone's talk about MVC or layered architecture at a conference, people are going to fall asleep, even though it is clear that layered architecture is what is important for structuring scalable and maintainable code. Distributed systems and microservices often get mixed up with RESTful services, which in turn misdirects people's attention to something that is utterly unrelated to actual code architecture.

Therefore as JavaScript developers, we must not focus on the hot topic of the week and the trendy new technologies (I know it's hard). We have to go back to the "old school" ways of doing things and read some of the more classic books from the object-oriented world and bring those ideas into our own community.

Big tech companies like Amazon, Google, Netflix, Uber, Facebook, and Snapchat host large conferences are all talking about it. Amazon is talking about how they created their own cloud solution to scale their own internal systems to millions of transactions per day. Netflix is talking about how they scale their microservices architecture so that millions of people can stream video without delay also sounds really interesting. And who can forget Google, the granddaddy of them all. Google is talking about things such as and and how they scale to billions of users with 0 downtime. All those mentioned are really exciting and enticing to the public.

MapReduce
Big Data
distributed systems