Why we Choose Loopback over Sails and Meteor

[Updated with more frameworks and our experience so far with Loopback]The Context for using Loopback for our applicationOne of the first things we do in a typical Node.js project is to pick the appropriate Node framework from the plenty of choices available. Current state of Node.js frameworks - Good: Lots of choices; Bad: No clear winner with a lot of momentum like Rails for Ruby.

Our decision framework

We took a typical polyglot approach to a technology stack. The platform has 2 main components: one for intelligence (Data Crunching, Machine Learning, Text Analytics and so on). For this, we finalized a stack of LUIGI, Elastic search, Spark, R and Python with a little bit of MongoDB thrown in.The second part of the platform is a typical business web application to expose output of the intelligent platform, business workflows etc.,For this, we decided on Node.js because it lends itself well for micro-services architecture. Some of our UI is message driven. Having decided on Node.js, we needed a web application framework (if you are only looking for an API backend, there are other good options like senecajs.org for rapid application development. Some of our selection criteria were

Integrated a la Rails
Quick CRUD development
Automatic API generation from CRUD
Good horizontal starter functionality
Integrated build, deploy, debug, monitor capability
Critical mass adoption
Ability to get to barebones node when needed
Embedded socket.io for push messaging
Decent ORM with auto managed associations etc
Not tied to a front end framework as we want to use React
Isomorphic Javascript compatible

We considered the following frameworks:

Sails.js
Loopback
Total.js
Koa.js
Meteor.js
mean.io/mean.js

Unfortunately, in the Node.js web framework landscape there is no one clear winner with mass adoption, unlike Rails for Ruby or Django for Python. There is a lot of fragmentation with each framework having some nice features but with very little adoption.

The choices (Meteor vs. Sails vs. Loopback)

After the initial research, we quickly dropped Total.js and Koa.js because of considerations like lack of momentum, the strength of the organization behind it, etc.We quickly dropped mean.io and mean.js because they are tightly married to Angular and retrofitting React is a lot of work.We gave more consideration to Meteor as it has nice features like:

Fully integrated tool hain
Very easy data to front end binding etc

But dropped it because the choice meant that we couldn't have a pure Node.js runtime. Besides it was too opinionated, and doesn't play nice with non-meteor-specific third-party components. Also, the front end was not switchable.Then it boiled down to Sails and Loopback. Sails had the most adoption and Loopback had the most recent momentum.

Sails it is. Sails it isn't.

We picked Sails because of the maturity, adoption, good documentation, availability of many useful plugins and our developer knowledge.Sails:5438 commits, 23 branches, 173 releases, 195 contributorsLoopback:1705 commits, 44 branches, 95 releases, 62 contributorsBut quickly switched to Loopback because of 2 events.The Sails team has fragmented with most of the developers going to start a competing framework Trails.js (read this discussion: shit hit the roof. Also, though Sails had some decent GitHub statistics when we delve deeper most of it turned to be cosmetic changes like readme updates.

The fallback to Loopback

Finally, we decided to go with Loopback:

Isomorphic model definitions
Strong support for API creation - plays well with our Microservices strategy
Clean separation between API server and client
Baked in mobile client SDKs
Powerful ACLs
Secure with baked in cross XSS
Good core code quality
Good suite of surrounding tools like StrongLoop Arc, visual API composer, CLI code generators etc.
Great recent momentum
Pedigree of the core developers
Commercial tools from StrongLoop which gives them a business incentive to keep investing into LoopBack

IBM has acquired StrongLoop which will only increase the commitment to the commercial suite of products and keep the dedicated team working on Loopback funded. And IBM has a good track record of contributing to open-source projects like Apache Spark, Cloud Foundry etc.Update:Our experience so far with Loopback:Loopback has mostly lived up to its promise and it's easy to roll out REST endpoints. But the pace of new features is not as fast as we thought. For instance, the new features in 3.0 release are mostly incrementalAlso, support has been fairly slow. Since Loopback does not have inbuilt multitenancy support, we created the functionality and gave a pull request and still waiting.More choices now:Some of the other frameworks that caught our attention since then:Feathers:Nice framework with excellent support for isometric Javascript and plays nicely with React.js.Seneca:If you are planning on Microservices from the get-go, Seneca is a great framework.Keystone:Good breadth of functionality out of the box and is very Rails-like."Originally posted at PipeCandy by Murali Vivekanandan"Are you looking to build a great product or service? Do you foresee technical challenges? If you answered yes to the above questions, then you must talk to us. We are a world-class custom .NET development company. We take up projects that are in our area of expertise. We know what we are good at and more importantly what we are not. We carefully choose projects where we strongly believe that we can add value. And not just in engineering but also in terms of how well we understand the domain. Book a free consultation with us today. Let’s work together.

Ideas2IT Team