About this Book

A brief history of Sails

The development of Sails began entirely by accident. Over the course of 2011 and 2012, Mike built several Node.js apps. Like many early Node.js users, he ended up organically accumulating code he could reuse across different projects. As you may already know, that works great for a while, but what he needed was a framework.

But there wasn’t an MVC framework for Node.js yet. Most projects at that time directly incorporated two modules—Express and Socket.IO—which are great but were never intended to be used as complete web frameworks. We had to write database queries by hand and make crucial structural decisions on a case-by-case basis. This made it hard to build (and especially maintain) Node.js apps without a great deal of prior experience—not only with Node’s core libraries and module system but also with backend apps in general.

Not to mention that back in those days the community was full of brilliant hobbyists and tinkerers, but the software industry scoffed at using Node.js on anything serious. Challenging that mindset was the grail for the first years of Sails.js—like many of us, Mike believed in the power of Node.js and wanted to use it at work. He proselytized for months. But alas, some things just aren’t meant to be.

So Mike started doing frontend web development in his free time (contracting as a hired gun), in hopes that he’d meet a client with an interesting use case or, better yet, someone who really got the promise of Node.js. Fortunately, he found two: first, a guy we’ll call “G,” who needed help building an entirely realtime cloud storage application for his enterprise customers, and then, a few weeks later, a woman named Jessa, who was building a social chat application but didn’t know how to go about it in PHP. Thanks in no small part to these folks, Mike was able to leave his job in 2012, form a team, and start using an early version of Sails on everything.

That’s when things got serious. Instead of relying on intermittent spurts of productivity to get stuff done, Mike and the core team were driven by paying customers to add new features and fix bugs. And because we were ultimately responsible for making sure everything worked, it meant that we were writing JavaScript on the server every day of the week.

The Sails framework really took off in the spring of 2013 (version 0.8) when Mike created a five-minute screencast that ended up on the front page of the popular tech news website, Hacker News. Almost overnight, Sails was being adopted for real-world projects by developers from all sorts of diverse backgrounds: everything from Django to Java to ASP.NET. The increasing popularity of Node.js itself fueled this even further; as more and more developers tried out Node and inevitably Googled “Node.js MVC framework,” they discovered Sails.

The second renaissance in web development

The web has changed dramatically over the past 10 years since Ruby on Rails and other developer-friendly Model-View-Controller (MVC) web frameworks were first introduced. These early projects popularized important ideas that are still prevalent in mainstream web development tools today. They also lowered the barrier to entry for becoming a full stack web developer, making it possible for a larger group of individuals to build web apps.

Because they were designed for building websites, traditional web frameworks needed to support only a single user-agent: the web browser. (A user-agent is a software application—like a web browser—that acts on behalf of a user to send requests to your Sails app. We reference a number of different types of user-agents throughout the book.) But the widespread adoption of mobile devices like the iPhone changed everything. Modern web applications need to support all sorts of different user-agents, from tablets to mobile handsets—even smart devices that don’t have screens at all!

Fortunately, the last few years have brought with them a sort of second renaissance in web development. JavaScript frameworks like Angular, React, Ember, and Backbone make it much easier to build rich browser interfaces. Meanwhile, the ecosystem for building iOS and Android apps has tons of great tools, and the manufacturers of new smart devices are making it easier than ever before for developers to build client applications for their platforms. What all of these frontend frameworks have in common is a need for an easy way to prototype and implement the backend of the application.

How this book is organized

The book has 15 chapters:

• Chapter 1 begins by defining Sails.js, what you can build with it, and its core features. The chapter also includes a primer on the fundamental concepts necessary to understand a web application.
• Chapter 2 outlines the tools necessary to create a Sails.js app. After creating and reviewing an initial project, the chapter concludes with an explanation of resources you’ll use throughout the book.
• Chapter 3 begins with a discussion of how to set up the frontend static assets in Sails.js. The chapter also discusses the frontend-first approach to API design using jQuery (and later Angular) as frontend examples.
• Chapter 4 illustrates using Sails.js blueprints to prototype an initial API.
• Chapter 5 transitions from automatic blueprints to custom backend code. The chapter also provides an introduction to using third-party npm packages and machinepacks.
• Chapter 6 is an introduction to using databases with Sails.js. The chapter discusses- the details of how to model a database and send queries using the Sails.js ORM.
• Chapter 7 goes deep into custom actions, with a few common use cases as examples.
• Chapter 8 provides a detailed understanding of server-rendered views. The chapter marks a transition from building a single-page application, instead applying a hybrid approach. For many apps, this affords some key benefits, including making pages more easily accessible to search engines.
• Chapter 9 describes the relationship between user authentication and sessions. This chapter provides a step-by-step example of implementing a login process.
• Chapter 10 outlines the means to control access to your API through policies.
• Chapter 11 demonstrates best practices for refactoring your Sails app to enhance its maintainability or when faced with inevitable changes to project requirements.
• Chapter 12 expands on chapter 6 to show how to store and retrieve related data through embedding and associations.
• Chapter 13 walks through the implementation of some often-requested features of web applications, including support for ratings, followers, and search.
• Chapter 14 takes you deep into enabling realtime features like chat using WebSockets.
• Chapter 15 wraps up the book with a detailed look at what you need to take your web application to production, including a discussion on deployment, security, and testing.

About the code

All of the source code for the book is available for download from the publisher’s website at www.manning.com/books/sails-js-in-action and from GitHub at http://sailsin-action.github.io/. There, you’ll find links to individual pages for chapters 3–15. Within each link, you’ll find, at the least, an ending GitHub repo—that is, a representation of what your source code should look like by the end of the chapter. If the chapter requires that you start from a particular state of code, there will also be a repo for the start of the chapter. Some chapters also include some other reference material.

Author Online

Purchase of Sails.js in Action includes free access to a private web forum run by Manning Publications, where you can make comments about the book, ask technical questions, and receive help from the authors and from other users. To access the forum and subscribe to it, point your web browser at www.manning.com/books/sails-js-in-action. This page provides information on how to get on the forum once you’re registered, what kind of help is available, and the rules of conduct on the forum.

Manning’s commitment to our readers is to provide a venue where a meaningful dialogue between individual readers and between readers and the authors can take place. It’s not a commitment to any specific amount of participation on the part of the authors, whose contributions to the Author Online forum remain voluntary (and unpaid). We suggest you try asking them some challenging questions, lest their interest stray! The Author Online forum and the archives of previous discussions will be accessible from the publisher’s website as long as the book is in print.