From sails to kraken, or how I chose a framework

Good day, dear readers of Habr. Everyone has long known that in the node.js universe there is a large number of frameworks for every taste and color. Each of them satisfies its needs and contains a diverse set of possibilities and its own architecture, and sometimes, to make a choice, you need to look at each of these "animals" under the hood and conduct analytics. In my case, a framework was needed that already had a choice of its own architecture, between 4 tools: kraken.js , sails.js , meteor.js and derby.js . To find out how it was, please under the cat.

Derby.js vs. Meteor.js

These two frameworks have already been compared and I decided to merge them into one section. I will list only those qualities that seemed decisive for me in refusing these frameworks:

• Both allow you to perform JavaScript and render templates both on the client and on the server, the only question is how it is determined that the client and the server;
• Integrate with MongoDB (or Redis in the case of Derby.js), which significantly reduces the scope of their application (if they were independent of data sources, I would probably accept this code organization in the project);
• Package management system in the case of meteor.js;
• The lack of documentation in the case of derby.js (you need to go into the code when you need to understand “where your legs grow from”);

Perhaps, I would use some components or other, but on the whole the tools, no matter how praised and PR they were, seemed to me to be very specific and do not uphold the lives of the developers.

Kraken.js

Kraken.js is a MVC framework released by PayPal relatively recently, distributed as a npm module, with a primary focus on security and internationalization support in the application.
')

Composition

In addition to the core, the framework includes four more modules:

• Lusca - responsible for security in the application
• Kappa - implements a local proxy server for npm packages
• Adaro - add-on for dust.js template engine that adds various tools
• Makara - adds support for internationalization in templates

These modules are independent of each other (with the exception of makara, which relies on the functionality of adaro) and can be connected and used in any node.js application.

Application structure

By its structure, the application very much resembles the structure of any MVC application, with the storage of files for their functional purpose:

/config -   /controllers -  /locales - .property-  /lib -       (  ,       npm ) /models -   /public - web-   /public/templates -     /tasks -    grunt-      grunt-config-dir /tests -     index.js -    

Configuration

At a time when node.js has CommonJS modules with which we can implement dynamic application configuration, kraken.js uses two .json files for development and production environments, which significantly limits our capabilities. But, despite these limitations, because kraken.js is based on the express.js framework that has already gained popularity among web developers , its application can be configured using any methods you know directly in the index.js file or using a self-written module configuring the application. In addition, there is an additional meddleware module that greatly simplifies middleware's configuration in your application.

Routing

Here we can say that he seems to be there, and at the same time he is not. All routing is performed manually in the controller file, whose main function is access to the router object, and it looks like this:

 module.exports = function (router) { var model = new IndexModel(); router.get('/', function (req, res) { res.render('index', model); }); }; 

This of course provides more flexibility in configuration, but you don’t think that the framework is primarily a tool that is designed to reduce the number of manual actions applied by the programmer (now probably rotten tomatoes will fly into me, but in general this is the way it is). When your application grows to an acceptable size, managing paths with such routing will not be that pleasant either ...

Models

Here, the creators of the framework decided to give the developer complete freedom of choice, the fact is that the models in kraken.js are ordinary JavaScript objects with their own properties. So, choose any ORM that you like, install it through npm and go ahead!

Templates

There is nothing to complain about. The template engine supports filters, block sections, conditional constructions, in general, provides the developer with all the necessary tools and even allows to compile templates for use on the client.

Internationalization

Translation support is only present in templates, which significantly limits our capabilities on the server, because we can not just take and pass a dynamically assembled translation string in a template variable. In addition, the module performing the translation itself relies on the use of .property files, the organization of which itself does not inspire much confidence in:

 index.greeting=Hello {name}! index.bye=Bye {name}! 

Perhaps in the case of simple sentences it still somehow works, but imagine what will happen in the case of complex sentences ...

Sails.js

Sails.js was designed and developed by Mike McNeil to create scalable real-time applications.

Composition

Sails.js consists of a kernel that is built from npm modules created and maintained by other developers, but among them there is one very interesting module - this is the ORM waterline , which can perform database migrations in semi-automatic mode, and written specifically for sails , and easily connected to any node.js application. In addition, the kernel has support for generating code that can be used directly from the command line . In addition, there is websocket's built-in support that allows you to process a request received through a socket, like a normal request.

Application structure

The structure is very similar to the MVC application, with more detailed fragmentation in functionality.

 api/ controllers/ -  models/ -  policies/ -       ... services/ - singleton-     assets/ -        public   config/ -   tasks/ config/ - grunt- register/ -  grunt- ... views/ -  Gruntfile.js -      grunt-    app.js -    .sailsrc -     

More information about the purpose of each file can be found in the documentation , which allows you to know its purpose with a single click on the directory or file.

Configuration

Sails.js is also based on express.js, but unlike kraken.js, it does not provide the developer with direct access to the application object and the entire configuration is done through .js files, which are CommonJS modules that export objects that are responsible for configuring one of kernel components. This mechanism allows you to separate the database settings from the HTTP server settings from each other, but it severely limits the ability to configure specific properties of the application, for example, it caused me to change the default path from where the templates will be rendered. If it comes to middleware, then you can easily connect it by placing it in the middleware section of the config / http.js file.

Routing

There is nothing to complain about. Routing is configured by specifying the desired path in the config / routes.js file in the corresponding section and looks like this:

 module.exports = { 'get /signup': { view: 'conversion/signup' }, 'post /signup': 'AuthController.processSignup', 'get /login': { view: 'portal/login' }, 'post /login': 'AuthController.processLogin', '/logout': 'AuthController.logout', 'get /me': 'UserController.profile' } 

This mechanism is very convenient, and allows you to configure settings without specifying the HTTP method, perform template mappings without a controller, specify the data to be transferred to the template, access policies that need to be checked before giving the user access to a specific controller method.

Models

As mentioned above, sails.js includes a very powerful ORM, which is based on the use of adapters in various data sources that exist for many well-known databases. The model is represented as a CommonJS module of the model's exporting properties, which will later expand the base class of the Waterline.Collection collection. The ORM has built-in support for several additional field types that apply specific validators throughout the model’s life cycle (for more information, see the documentation), as well as the ability to specify for each model a specific database connection that will be used to write and read model data. In addition to all this, there is built-in support for pagination, sorting, and event handlers.

A typical example of a model file:

 module.exports = { connection: 'disk', attributes: { firstName: { type: 'string', required: true }, lastName: { type: 'string', required: true, } } }); 

When changes are made in the model structure, ORM automatically detects them at startup and if the automatic resolution of conflicts cannot be made, conducts a dialogue with the developer.

Templates

Sails.js has the support of most well-known template engines for embedding the use of the consolidate.js library from the author of the express.js framework, which undoubtedly simplifies the use of templates in the application. Just choose and use!

Internationalization

Translation support is present in sails.js throughout the entire life cycle of an application, be it a server code, a template or a .js file, because inside sails.js it uses the i18n library. The translations themselves are added into .json files, and can be added automatically when trying to translate text that is not already in the file. On the one hand, automatic filling creates problems for timely translation, but you can always create a grunt task that scans the contents of the necessary files and collects all the text for the translations.

So what did you choose?

Summing up, the following classification table was formed in the mind, according to the five-point system.

	Confguration	Routing	Models	Templates	Internationalization
Meteor.js	3	five	four	four	2
Derby.js	five	3	4.5	3	2
Kraken.js	five	2	five	four	3
Sails.js	four	five	four	five	four

It is not difficult to guess that my choice fell on sails.js, because the structure of the project used by the framework and the possibilities it provides out of the box is closer to me in spirit. Of course, it has drawbacks regarding configuration and internationalization, but these are the drawbacks with which in my case, you can accept or implement, if you think in accordance with the framework concept. By this article, by no means do I incline you in the direction of this or that instrument, choose for yourself what is close to you in spirit, and may the force be with you!