Developing REST services with SailsJS

What is SailsJS?

✘ MVC backend framework for Node.js✘ Built on top of Express✘ Inspired by Ruby on Rails / Zend✘ Convention over configuration ✘ Ideal for real time applications, games, REST

services

Core features

✘ Database agnostic (Waterline ORM) ✘ Front end agnostic✘ Auto generated REST API✘ Auto generated model methods✘ DB migration support ✘ Easy web socket support ✘ Flexible configuration✘ Multiple environments support ✘ Localization support✘ Still allows to use Express

Installation and first application

✘ npm install -g sails✘ cd to your project folder✘ sails new [path]//path is optional✘ npm install //optional depends on version✘ sails lift

Running application

Project structure

✘ api/controller – controllers✘ api/model – models✘ api/policies – policies✘ api/responses – application responses✘ api/services – reusable services✘ assets – static assets✘ config – application configuration settings✘ views – application views✘ tasks – grunt cli tasks

Generate API Sample

✘ Sails generate api Category ✘ What just has happened:

✗ CategoryController is created✗ Category model is created✗ Sails created blueprint for route /category

✘ Let’s run the app✘ Note: Model and controller can be generated same

way

Migration options

Models

✘ Located at: Api/models✘ Describes:

✗ DB mapping✗ Validation rules✗ Custom functions✗ And other settings like: migration strategy,

schema, primary key properties✘ Please refer to Waterline ORM documentation ✘ Note: SailsJS supports polyglot persistence layer by

allowing models to be stored in different databases

Supported databases✘ PostgreSQL - 0.9+ compatible✘ MySQL - 0.9+ compatible✘ MongoDB - 0.9+ compatible✘ Memory - 0.9+ compatible✘ Disk - 0.9+ compatible✘ Microsoft SQL Server✘ Redis✘ Riak✘ Neo4j✘ OrientDB✘ ArangoDB✘ Apache Cassandra✘ GraphQL✘ Solr✘ Apache Derby✘ And many others

How does it work with multiple databases?

✘ It uses Waterline adapters concept✘ Waterline defines query language✘ Then each adapter knows how to:

✗ Connect to each specific DB✗ Turn query object into specific DB query✗ Read/Write data from the source

Model sample

Model blueprints

✘ following methods are available for each property:✗ findOneByPropertyName✗ findOneByPropertyNameIn✗ findOneByPropertyNameLike✗ findByPropertyName✗ findByPropertyNameIn✗ findByPropertyNameLike✗ countByPropertyName✗ countByPropertyNameIn✗ countByPropertyNameLike✗ propertyNameStartsWith✗ propertyNameEndsWith✗ propertyNameContains

Model blueprints

✘ find() – accepts object with query definition like {where: {name:{startsWith:”A”}}}

✘ Or it can an be called as chain: Category.find().skip(10).limit(10)

✘ Supports: ✗ Filtering✗ Paging✗ Sorting

Controller

✘ Full support for RESTful routes✘ Shortcut routes✘ Can have custom actions✘ Can be put in subdirs and subdir becomes part of

the route✘ Has standard methods for CRUD support which can

be overridden✘ Policies can be applied either per action or for entire

controller

Controller: custom action sample

Policies

✘ Used for authentication/authorization or like simple handlers

✘ Can be applied:✗ Globally✗ On controllers✗ On controller actions

✘ Can be integrated with Passport

Policy sample

Services

✘ Contains reusable logic across application✘ Automatically registered by Sails like Model or

Controller ✘ Sample: https://github.com/balderdashy/sails-docs/blob/0.9/services.md

Assets

✘ This folder is just for static content✘ Note: No need to add “/assets” in URL

Configuration

✘ Allows to configure: ✗ Environments✗ Locales✗ Blueprints – routing rules✗ Connection strings✗ Application bootstrap✗ Sessions✗ Sockets✗ View engine✗ Logging

Views

✘ View is simple HTML page✘ Multiple view engines are supported✘ Default is EJB

What about realtime?

✘ Based on socket.io✘ By default notifies of any changes in any model✘ Can notify of data requested✘ Allows to write custom endpoints✘ Does have scalability option by using redis as a

pub/sub storage✘ Has transport fallback (long polling or web sockets)

Demo

Sum Up

✘ Runs on any platform✘ Front end agnostic✘ DB agnostic✘ Good for prototyping✘ Speeds up implementation✘ Does not require sails to be installed in production✘ Provides fallback to express when needed

Cons

✘ Is not as fast as Express could be✘ Some adapters do not support native and effective

DB capabilities ✘ In theory switching from one DB adapter to another

go seamless in practice it’s a PAIN!✘ Mixing DB can be an issue when you do have

associations✘ Does not suit well for complex data structures✘ No transaction support

THANKS!Any questions?