Convincing the boss about sails.js

[voltron]

Actually, I have already convinced the boss about using hapi.js(http://spumko.github.io/) after seeing the videos(http://spumko.github.io/resource/videos/).

Things are a bit different now, I discovered sails 2 days ago, and I am really impressed. Auto-generated routes, Grunt integration, asset management have already won me over, but there are a few issues that need to be discussed before I make a new recommendation.

What is Sails standpoint on these issues?

1. Express middleware positions matter( One of the main gripes mentioned by the hapi.js dev)

2. Speed? Is there any overhead caused by using 2 framework stacked on top of each other? (Express -> Sails)

3. API endpoint validation

4. Body parser limitations

5. Batch requesting

Thanks

[Mike McNeil]

Hey @voltron,

Questions answered inline:

1. Express middleware positions matter( One of the main gripes mentioned by the hapi.js dev)

In Sails, Express middleware can be included for both sockets and http requests as policies.  Policies are applied at the controller/action level, and run before the relevant controller method-- technically as part of the express.router() middleware.  Sails lays down reasonable conventions for sessions and bodyParser that you can override in the configuration files.

 

2. Speed? Is there any overhead caused by using 2 framework stacked on top of each other? (Express -> Sails)

No numbers on the current release, but as of 0.9.0, @particlebanana ran a C10K with Sails and achieved comparable results.  Sails binds Express routes at "lift-time" (along with some simple middleware) and then gets out of the way.  It also allows routes to be triggered via events using node's EventEmitter interface (this is how it hooks up to Socket.io, along with some other code which normalizes the Connect session and simulates req and res objects.  This is how you can use the same code base to handle socket.io and normal http requests.)

 

3. API endpoint validation

In some scenarios, we use policies to achieve parameter validation, but in most cases, your controllers should be thin enough that you don't necessarily need to pull the parameter validation out of them (just like in other MVC frameworks).  As for ORM validation on models, that was added in the 0.9.0 release.

 

4. Body parser limitations

In general, the goal with Sails is to capture the existing best practices for Node.js apps, then make them better.  For now, we are using the default Express body parser (with the addition of a default file upload size limit).  As you might already know, this is not always the best bet for many use cases (e.g. uploading TB files) since it buffers to disk by default.

I'm working on providing a more versatile default for easily uploading and downloading files as streams.  Working example here.  Made a lot of progress so far-- if you're feeling adventurous, you can check out how that example includes the file-parser if you'd like to try it out in your app.  There are pending TODOs for automatically encrypting and decrypting the byte streams as they flow in/out of the adapter.  Any help on that is more than welcome :)

 

5. Batch requesting

Not 100% familiar with the terminology, but assuming you mean an endpoint that processes a chain of requests sent as JSON, you'll have no problem building that functionality into a controller.  To implement something like what the facebook guys are doing, you'd grab want to grab req.param('batch').  In that example, since they're using a weird mix of JSON and URL param notation, you'll need to parse the value of the parameter as JSON (you'll probably want to wrap that in a try/catch-- you can check out how the built-in CRUD blueprints do something similar)

Hope that helps!

Mike

--

Mike McNeil

Founder

    

       C      O
      NFI    DEN
      TIA   L i
      nfo  rma
      tion in
       tended
    only for t      he addressee(s).
  If you are not the intended recipient, empl
 oyee or agent responsible for delivery to the
  intended recipient(s), please be aware that
   any review, dissemination, use,distribut
     ion or copying of this message and its
       contents is strictly prohibited. If
      you receive this email in error, ple
    ase notify the sender and destroy any
   paper or           electronic copies    immediately.

[voltron]

Thanks for the reply Mike!

A few more, bear with me please :)

1. So the position of middleware does not really matter in terms of policies as in traditional middleware in express?

2. There is no additional overhead induced by sailsjs? 

3. In regards of "Batch requesting" I meant something a little simpler. As I mentioned before, we had chosen hapijs to be the base of all of our app, HapiJS supports this, see here(https://github.com/spumko/bassmaster) I was just wondering if something similar could be achied using SailsJS

Thanks 

[mikermcneil]

1. Sails (like Express 4) merges the concept of routes and middleware
2: Very little, and in load tests, we have been unable to identify any meaningful negative impact on performance.

3. This is certainly possible to implement in a custom hook, but I'm also more than happy to accept a pull request to core- I think it would be a cool feature.