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

Chapter 4: Structured JavaScript Architecture

The 2010's have been an extraordinary decade for JavaScript. What was once a "toy language" used for interactivity on small websites, is now the most popular and inescapable programming language of the world. Even at the beginning of the last decade, most large websites would sprinkle on some JavaScript and jQuery here and there. Adding JavaScript was merely an afterthought to large server-side rendered applications. If you were to have told me in 2010 that an entire application, or better yet, an entire business could be built on just JavaScript, I would have said, "use something more mature and proven like Java!". But this is the world that we live in now, a world where 100% of the stack could be built just on JavaScript and JavaScript alone.

This new and improved way of writing applications has introduced many problems which were previously unknown in the JavaScript community. There are now hundreds of large JavaScript-based applications that are unmaintainable, unscalable, and unfathomably horrific to work with. The good news is that we, as JavaScript developers do not have to reinvent the wheel, but rather take what has already worked in other communities and apply them to ours.

In this chapter, we will explore some of the problems that JavaScript developers face when building large applications. We will see why building a monolithic application does not scale a project properly in the long term and why the community has had such a hard time structuring larger applications.

We then take a page from domain-driven design (DDD) and learn about the layered architecture. We'll dive into the classic MVC pattern and then deeper into how we can extend MVC into repositories and services.

We will also take a look at the microservices architecture and why it has become the poster child of the past decade and why buzzwords like services oriented architecture and distributed systems are not what we, as JavaScript Developers, should focus on.

PreviousSummaryNextThe Monstrous Monolith and Its Downfall

Last updated 3 years ago