(M) VC Framework Locomotive

For several days I have been engaged in the selection of the Node.js framework for solving several demo tasks. I passed 4 frameworks ( Locomotive , Express , Geddy , Sails ) and I decided to start the cycle of my articles with Locomotive.

Locomotive came to my attention upon the recommendation of my friend, who told me: “Listen, there is an interesting new framework implementing MVC over Express.” - and that interested me, which later resulted in the addition of Locomotive to the list of “experimental”.

Locomotive architecture and common concepts

Locomotive presents itself as: “Strictly adhering to the MVC pattern and REST principles, which is good to write with well-designed applications“ - but I don’t want to talk about “ MVC ” inside Locomotive; to end. Such a statement came about as part of the “Model” in my opinion should be implemented at least in some form, but in the documentation of the Locomotive the author referred to the article “polyglot persistence” and said that you can choose Database & ORM yourself and “tie” to the framework, this author’s approach has been a bit rastroil, since the calculation was, when choosing this framework, to the fact that he really implements MVC (Model2) in full. Let's return to what is implemented there.
“View” is implemented by Express, which in turn is integrated with such templates as Jade , Ejs and many others .
“Controller” is basically fully implemented, there is a base controller class, you can actually process the Request from the client and return the Response. Inside each method is the action of the controller, inside each action it is possible to get the parameters of the routing directly from the current context:

var SearchController = new Controller(); SearchController.find = function() { this.query = this.param('query'); // execute search query... } module.exports = SearchController; 

')
Also available are “action assistants” allowing you to climb right before / after performing a particular action (in Locomotive this is called “ Filters ”):

 PhotosController.before('show', function(next) { var self = this; if (this.param('id')) { next(); } else { return next(“Error”); } }); PhotosController.show = function() { this.render(); } 

In this example, we insert the “action helper” to be executed immediately before the “show” action, thereby adding a layer where we can check the identifier parameter and decide whether to continue the execution of the request or its completion. You can also add an “action helper” that will be executed before any action in the controller:

 PhotosController.before('*', function(next) { //       PhotosController }); 

Well, besides “action assistants”, Locomotive has support for the “content negotiations” mechanism (http://en.wikipedia.org/wiki/Content_negotiation), that is, there are several ways to display the submission within the action depending on the format requested by the client. In short, it looks like this:

 PhotosController.index = function() { this.respond({ 'xml': { template: 'feed' }, 'html': { template: 'index' } }); } 

That is, the PhotosController controller will return the presentation in one of two formats, depending on which format the user requested in the headers. With this value of the Accept header, the action will automatically return the registered index template:

Accept: text/html;

In fact, there are a lot of “big buns” around these opportunities, but I will not go into details, I see no reason to rewrite the documentation.

And the last thing I found interesting in Locomotive is how they expanded Express routing . They implemented match () which allows you to create routes with “placeholder”:

  this.match('songs/:title', { controller: 'songs', action: 'show' }); 

and added in my opinion an interesting “sugar”, registration is not just routes but the whole resources manipulated through REST. That is such a line:

  this.resources('photos'); 

Will make available to you such routes as:

Method:	Route:	Promapit on action:
Get	/ photos	index
Get	/ photos / new	new
POST	/ photos	create
Get	/ photos /: id	show
Get	/ photos /: id / edit	edit
PUT	/ photos /: id	update
DELETE	/ photos /: id	destroy

And you will be able to describe the behavior of these routes by the PhotosController controller with the corresponding actions from the column “Promapit to action”. The functionality itself is simple but sometimes useful to save time. There are a lot of customizations around these “tweaks” so you don’t need to think: “AAAAAA, what to do if I only need show and edit” - the developer took care of that too.

Testing the ease of installation and configuration

“I did it, I installed and configured Locomotive + Socket.io and did all the demos I wanted,” I would like to say so, but there were a lot of problems. Locomotive can be installed as easily as Express:

 npm install locomotive -g 

and then create a project:

 lcm create project 

and run:

 cd project && lcm server 

Everything is fine, bye, if you open the browser at http: // localhost: 3000 then Locomotive will greet you cheerfully.
But my goal was to set up so Locomotive so that it could properly handle Web socket requests and download files.
There are no problems with uploading files, since Locomotive is built on top of Express, and also how it works in Express is the same with Locomotive.
But with Web Sockets there was a little not pleasant situation. For some reason, the developer of Locomotive considered that the creation of an Express (app) object should be closed as part of the framework, thereby cutting off any possibility to wrap an Express for example in Express.io (of course, you can stupidly patch the code, but this is not our method). Then I abandoned the idea of ​​using Express.io, although it was best suited to Locomotive, since Express.io is an excellent fit for Express, over which Locomotive is written. Then I decided to connect Socket.io directly, but even here I was disappointed. For example, references on which people cannot solve this problem without “castes” , and the developer of Locomotive is not particularly in a hurry to “merge pull requests” on Github . Yes, and how the development of a campaign in general does not go over this framework, judging by the history of commits on Github.

Finally

In conclusion, I can say that in principle, the Locomotive add-on is not bad, but in my opinion it is not absolutely expandable, that is, I wouldn’t risk further expanding on it, since I would have to patch the framework itself a lot.
But if your tasks, such as making “Landing Page”, “Business card”, then Locomotive is very suitable for this.

Used literature:

http://locomotivejs.org/guide