Preface
Last updated
Last updated
The fall of 2014 was when I got my first major breakthrough as a software developer; although I was still in university at the time I managed to land a high-paying contract gig at a local digital agency. I was hired to build a large property management web application. Prior to being hired for this contract my work experience mostly consisted of freelancing and a couple of short-term jobs at startups. At the time I was hired by the digital agency I had just over two years of experience under my belt building real-world professional software. Education and experience aside, I had successfully secured this year-long contract job and I was tasked to lead the development of the entire backend system.
The technology stack for this project was PHP with Laravel and Node.js with Express in the backend along with jQuery, Backbone.js and AngularJS in the frontend. I spent an entire year working on the backend for this project from beginning to end. I initially started building the entire RESTful API on the PHP and Laravel side, but later transitioned to working more on the Node.js side. By the end of the project, I had created a staggering number of API endpoints: over 150. These endpoints included modules for user authentication, permission management, messaging, payment integration, and many more.
Let's take a step back for a moment and summarize the situation: I was a (relatively) new software developer hired to design and develop a complex backend system for a widely-used property management application. At this point, you may be wondering: "So Yichen, how did everything turn out?"
To summarize what that year was like, all I can say is that it was… hell.
I was expected to deliver high-quality software, but instead, I managed to give my boss, my CTO and my client all near-death heart attacks. I was sloppy with my code and I had no idea how to design maintainable software that could scale. Many of my APIs would break unexpectedly, and without proper tests to back them up, I often did lots of manual regression testing to keep my anxiety in check. When it came time to clean up and refactor my code - just kidding, I never cleaned up or refactored code during this period of my career. Don't even ask me about documentation - I didn’t have any.
The chaos and hellishness of that year of work taught me a lot of valuable lessons about backend software development, and it is my hope that this book can help you avoid learning things the hard way and making the same mistakes that I did.
I often take notes at work and in my day-to-day life so that I can revisit them later on, and this book actually began as a collection of items that I wrote in my Evernote. By the time the property management software was launched I had hundreds of pages of notes written in my notebooks over the course of that year.
These notes were actually filled with more questions and uncertainties than anything else. In fact, the initial commit to my GitHub repository was called "things-to-learn" and was full of random notes and questions that I had transferred from my Evernote notebook stacks. Some of these questions included:
What is REST (actually)?
What is HATEOAS (really)?
What are the "correct" ways to create REST APIs?
What is the difference between HTTP and REST?
How do you structure a REST API in Node.js?
Where are all the Node.js architecture books?
And many, many more...
And because I was curious, I wanted answers...
My curiosity and desire for answers didn't go away after the conclusion of my difficult project, and I did a lot of research with the intention of trying to answer all of these questions. I was able to compile an exhaustive list of all the things to consider before creating any RESTful APIs, and that list has evolved into the book you’re reading right now. I wrote this book with the goal of answering the questions listed above and clearing up any doubts for Node.js developers as they conceive, build and maintain REST APIs throughout their careers.
