To Sail or not to Sail

Experience with Sails js as production system

This is an account from my experience while building system for Thirstt during March-July 2014. This might be a bit old as compared to current Sails version, but it is still apt for anyone looking into web app development. I have kept the steps/ incidents in the sequence they happened so that readers can criticize the process.

The Problem

As with any start-up, the key to growth was faster prototyping of the ideas. In the process many lose out on a key factor of formal specifications of requirements. We took care of that by having a Business Requirements Doc which was prepared by stakeholders other than the developers. It was in descriptive form (in plain English).

Now with development, we wanted the prototype to replicate the production environment as closely as possible. We could not afford to rework for production environment with such a small team for performance improvements. The new feature integration should be simple and fast enough to deliver to the stakeholders, as well as should not cause major problems with system’s performance.

We needed an architecture for a Semi-formal as well as Quick and Dirty development.

The Solution

Framework

I was a newbie in node js when I started the project with Manish Kumar, and Mandeep Singh Gulati. I had just enough exposure to advocate that having a JS based system will alleviate the problem having a small team. Since everyone is working with JS, anyone can take up a process related problem, be it at front-end or at back-end of the system.

After several days of research into plethora of JS frameworks, Sails turned out to be a nice fit. For people who are familiar with Rails framework in Ruby, Sails was an instant click. A few other frameworks worth mentioning are MEAN, Meteor and Tower. [MEAN back then was not as friendly as Sails as it is today. That may have been a reason for choosing Sails over Mean too!]

We followed this tutorial casts by Ponzi Coder. These were extremely helpful in getting upto speed with sails.

Architecture

This was an interesting phase of process. I would be able to define only the Server and Server-Client interaction (Backend), as Manish was the person driving the Client-side (Frontend). Since we already chose Sails, the pattern was “Three-Tiered / SLD” and the style on Server was MVC. The MVC part was extremely confusing at first, but it made more sense when we went ahead in building the application.

As with all web-apps, we have a Server which can be accessed via API system from virtually any platform that supports HTTP 1.1 standards. Clients (Applications) interact with the Server to save content and retrieve it while viewing / editing. All usual stuff.

Yay Sails!

The command-line way of generating an API was simply amazing. In other words we called Sails as “API-churning-framework”. You literally had nothing to worry about adding an API endpoint. Just run “sails generate User”, bam! you have everything ready!

Sails helped us keep the code highly organized with controllers and services, otherwise which is a nightmare for a start-up. (Later on we found more ways that Sails has “Services” for modularizing the code)

The EJS template engine worked out really nice (for a while only ☹). For a while the frontend guys not even worked on Sails. They created HTML mock-ups and passed on to Backend to put in the assets as templates. Pretty efficient I would say.

Improvs

Actual problems

After successful kick off of the development, it was time to move to the performance sides of things, mostly related to information storage & retrieval and template rendering.

Faster Services.
Well, this was a no brainer. We needed external services to be fast, very fast! Or atleast we can make them look like they are fast ☺. Like mentioned before, Sails has provisions for making your server run designed on service oriented architecture. The API endpoints’ service routines can be broken down into smaller modules of services (be it internal or external interfacing like facebook, twitter, etc) and then shared across the system. Since everything is in JS, getting asynchronity was not a big problem. (Contrary to that getting synchronity sometimes was huge problem!)

DB Concerns.
Sails provides its own ORM : Waterline. This a DB agnostic ORM, meaning you can use a generic model to represent your data stored in any type of DB. e.g. A model ‘User’ having attributes id, name, address, etc can be used in either in MongoDB or SQL. Later on we came up with a plan to use both MongoDB and Postgres. Postgres handled the relational side of the the information, whereas MongoDB handled the data (large enough) for dump storage. See the article by Mandeep below

Templates : Needed speed up.
EJS is server side rendered. We needed something like Angular that enforces Client side rendering, but not put too much load on client for doing it. A half-baked template sent to client on request would be the perfect solution in our case. We decide to move ahead with Dust. It was around the time when Yusuf joined us, after 3–4 months of development of product. He was in charge of the task and being a fresh graduate, he had his fair share of learning experience with Sails and template integration. From my point of view, it was not that direct to use Dust with Sails.

Final words

I agree that the article provides just a synopsis of the 5 months development, but I hope I captured the essential parts of the utilization of Sails in the main problem areas. There are articles by my colleagues which point out the specifics of Improvs mentioned.

Situation NOW

Support with Sails has been on neutral area. Sometimes we didn’t get straight answers and had to move with our gut-feeling. Many good and super-useful features from Sails came in their v0.10 release in August, which was quite late than the expectation. Still our team is not in a good position with the migration from v0.9.x to v0.10.

There are always ups and downs with an infant framework. A word of caution is,

Don’t go for something completely new if you are not in a position to face failures in some future point.

Luckily for us, failure did not affect the system operations. The whole journey had been a great experience with tinkering around a framework. Working with npm made it easier to reverse engineer things (sometimes!).

All in all, Sails worked out great in past. But the migration was to be taken more into consideration while they released their latest version. The fact that not many people even on stackoverflow can answer to your problems shows that what uncharted territory we are exploring.

To become a pioneer means to leave your comfort zone aside and ride against the waves.