Which back end framework for node.js fits well with the Ember way: Express, Hapi, or Sails?

From what I found, there is three main players: Express, Hapi, and Sails.

The Sane stack, using Ember and Sails, looked promising, but seemed to be discontinued.

There doesn’t seem to be any other prominent setups or conventions. I could only find a few, brief tutorials on getting set up with Express and Hapi, but they seemed to be outdated.

(Note: Another popular (non node.js) option that I considered is EmberFirebase, which seems dead simple to setup and get going; but I’m not sure how extensible it is, nor if it would be easy to exchange for a node.js solution if necessary.)

What backend framework would you recommend? With ember, would it be easier to use an unopiniated framework like express or an opinionated framework like Hapi? I know Ember has a specific way of doing things and I want to find a solution that fits well and better yet, that I know is widely used by the community.

1 Like

I’m still rocking with Sane stack. But my Ember project is just an old hobby that I don’t really have time for.

Have you seen Seeds? I think they near enough took off from where Sane finished. Pretty similar project. But not sure how active they still are…

There is a difference between ‘web framework’ and ‘web application framework’. Sails doesn’t fit in your enumeration, as it tries to be a full web application framework. Talking about Express and Hapi, one has also to mention Koa, which is the youngest among them and relaying on ES6 generators.

I was looking for a web application framework in the node ecosystem about a month ago. I decided to give Sails a try, only to find out it was a bad decision. I’ve found out it’s created and maintained almost by a single person. And that guy seems to not respond on GitHub except to keep mentioning that Sails is still alive. But it’s not maintained, it has many bugs, it’s outdated, the code base is imo a mess and it’s dangerous and a security risk. I can’t even imagine how people use that in production. There is a group or company among tjwebb which created the addons/plugins (in Sails it’s called a hook (?!)) sails-auth and sails-permission. They decided to split (read here an explanation of tjwebbs version) and started to create Trails. From that repository description:

Trails is a modern, community-driven web application framework for node.js. It builds on the pedigree of Rails and Grails to accelerate development by adhering to a straightforward, convention-based, API-driven design philosophy.

But Trails is nowhere near ready to use. To be honest, I’m not waiting for it. On my journey fixing bugs in sails, sails-auth, sails-permissions and waterline (an ORM used by Sails from the same creator) I lost too much trust.

For my project which has left MVP status and I start to show and invite people I know, I’m still running Sails as back-end. But as I mentioned above, it’s in my opinion a security risk:

  • It uses Express 3.x which was deprecated and you can read on their website:

Express 3.x IS NO LONGER MAINTAINED Known and unknown security and performance issues in 3.x have not been addressed since the last update (1 August, 2015). It is highly recommended to use the latest version of Express.

  • About Sails: building for production means there is different code paths (for performance reason I read somewhere). I figured some of them read my config files different. I couldn’t have two data adapters defined.

  • sails has so called ‘blueprints’, automagical CRUD endpoints for models/resources. Their documentation says they are safe to use in production. My unit tests against those endpoints tell me something different. I can update properties I am not supposed to, but for this, sails-permissions should jump in.

  • sails has different data adapters and stores. They have a convenient disk store… without unique key enforcement…

  • sails-auth uses PassportJS which is very nice, but, make sure you ‘reopen’ User and Passport and make email address and passwort a required field.

  • sails-auths logout endpoint is invokable with a GET request (let’s add an image or script tag, and the user is logged out :smile: )

  • sails-permissions turns your 403er (or better 404er) in 500er. Not something you want to disclose.

I could go on with this list. I could also extract these and more minor fixes from my codebase if you are interested. Oh, and I have ember-simple-auth authenticator and an ember-data adapter that plays nice with Sails RESTful requests/responses aswell as with ember-data DS.Errors, ember-cp-validation and ember-intl. Tell me if you need any of these.

So, to come back to your question: There is nothing I could find in the fields of ‘web application frameworks’. Everything that builds on top of Sails is useless (Sane?) or already abandoned (Seeds?). What you mean by ‘moving away from MVC framework’ I don’t understand. But Ember doesn’t have a specific way of doing things regarding on how it talks to your API. Therefore it doesn’t matter how opinionated your back-end is.

There is one more thing I was looking at. If you find yourself in a situation where you might look at microservices to do all your work, there is an interesting framework called SenecaJS. The core of SenecaJS and many plugins are production ready I guess, but plugins around front-end needs are poorly crafted and neither seneca-user, seneca-auth nor seneca-web is production ready. It’s also nice to build a Prototype/MVP and that sort… But what I want to say is: If you are looking at SOA or microservices, you don’t need a web application framework that talks to databases or does database migrations.


PouchDB can be run on Node but I like CouchDB more. It is API compatible. I also use https://cloudant.com/ and it is free for small project like http://bloggr.exmer.com/ ( https://github.com/broerse/ember-cli-blog )

See also: https://github.com/nolanlawson/ember-pouch

1 Like

Two other JS frameworks I’ve looked at but haven’t used yet (used or worked on by Ember folks): http://denali.js.org/ http://adonisjs.com/

Denali is more clearly tilted toward Ember needs.

But to answer your larger question, the Node backend framework options are still quite balkanized with no commonly agreed on solution :worried:

I’ve been using koa.js + sequelize on the backend for a little less than a year now and things are going smooth.

1 Like

Thank you for the pointer on AdonisJs. I’m going to try this one. Denali states on their page:

Heads up! Denali is still in alpha. We don’t recommend using it for production apps just yet.

seems pretty great, but this

“# If you already have io.js installed…”

makes me wonder if they are keeping things up to date.

I like how denali.js says right away

You won’t find any templating languages, views, or other HTML rendering support out of the box. Denali is unapologetically focused on APIs first.

because I’m always confused why my backend has a templating solution when I’m going to use Ember for all of that jazz anyways.

PLUS, look how well they play together Denali and Ember

1 Like

Thanks for posting this - Will update that part of the docs haha. The current release of Seeds is targeted at LTS Node v4+.

The next release of Seeds will target node 6+ and we are moving away from Sails to a newer JSON API framework called Lux as soon 1.0 is released (Currently 1.0.0-rc.5 - almost there!)

To answer the OP take a look at Lux for a backend framework for Ember! It’s really close to 1.0 release and is really clean, lightweight, fast and focused on developer happiness.


  • Automatic CRUD actions in controllers
  • Automatic pagination, sorting, filtering via query params in controllers
  • CLI for eliminating boiler plate
  • JSON API 1.0 compliant out of the box
  • Optimized database queries based on serialized attributes and associations
  • Highly extensible - just write reusable JavaScript functions
  • Pairs nicely with client-side JavaScript applications :wine_glass:
  • Easy to contribute
  • Routes are stored and accessed via a Map not an Array
  • Embraces ES2015 and beyond
    • Classes
    • Modules
    • Promises & async/await
    • Arrow Functions
    • etc.

I think express is a awesome choice, i love it.

I’ve made a small API implementation that although it is meant to develop the back end using google cloud (Functions or GAE) , it is a standard express server that you can use anywhere. It even has a generic router that handles all CRUD operations for all your models out of the box and you can use pagination , etc using query params. By default it auto populate relationships that i find good to optimize the way ember data works and saves a lot of small queries to db. You need to set the ember-data to use embedded records. If you need extra router process, you can easely expand the router and only add what extra code you need but reuse the generic part as well.


  1. Install
  2. Define your models (uses waterline/sails ORM)
  3. Run Done! generic CRUD api just like ember likes it.

I checked out Lux, it looks promising and simple to use, but the documentation is scarce. Would you recommend it for a beginner?

Hi I’m the author of Lux! The docs are scarce but it is something that we are actively working on. To compensate for the lack of documentation, I try to do the best I can to respond to issues as well as messages in our Gitter room. I recommend using Lux to beginners as it’s strong opinions keep the workflow and mental model simple (much like Ember).

In my opinion Express.js is the best framework for Node.js You should check this article - The best Node.js framework for your project: Express.js, Koa.js or Sails.js

Just a quick ping…since Lux shipped v1.0.0 about 5 months ago now I am wondering if Seeds is still alive. The docs site appears to be down, and I don’t see any open PRs or Projects on the Seeds github repository page. Bad news?

I also used sequelize, with express for a time. I really liked it, way more than waterline, more permissive, easy to set up and great documentation.

Haven’t tried this stack recently thought, but Koa is looking at me, along with loopback.

Denali looks interesting.