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 I: The Why
  2. Chapter 1: Introduction

Problem #2: Structureless JavaScript, Structureless Node.js

Unlike traditional object-oriented oriented languages like Java and C# that contain structure, JavaScript has always been the wild west. Whereas Java and C# would have Oracle and Microsoft give "best practices" and guidelines to their developers, JavaScript’s version of “best practices” has always been the community itself.

Because JavaScript was malleable, because there were so many web designers, you would see different schools of thought on how to use it… I think that's actually an advantage… we're not telling you there's the one way to write it, here's the one true object-oriented paradigm, here's the only way you should ever make a reusable abstraction. it's not unmixed… it's hard for beginners, and people reinvent certain wheels... If I had done something more rigid, I think the odds are, it pretty much would have failed.

-Brendan Eich, Creator of the JavaScript Language

Just like how Brendan Eich envisioned JavaScript to be malleable, Node.js followed suit. The developers (and designers) who came from that originally malleable background began to write code on the server side. The backend and the server - what was once a playground for only the Java, C#, and C programmer became the playground for the average JavaScript developer. What was once a very object-oriented playground became a "not-so-structured jungle". What would have been built at the enterprise or commercial level with a robust language like Java or C#, would now be built entirely in Node.js.

This produced many problems as the habits of the old-school web developer who came from that jQuery and pre-2010 JavaScript background were now working in large scale applications written in JavaScript. Because everywhere you go, you would see JavaScript on the server side - you would see messy codebases that were not maintainable, not scalable, and not robust enough to work with on a long term basis.

PreviousThe Emergence of JavaScript and Node.jsNextBehold, the Solution: A Structured Approach

Last updated 3 years ago