Why we chose Loop over Sails and Meteor

loop-over-sails

The Context for using Loopback for our application

We are working on the finalizing the technology stack for our product PipeCandy. PipeCandy is an intelligent outbound sales prospecting software (If you don’t like sending cold emails, PipeCandy is a no-brainer!). Our application would have to work with a lot of data, lend itself well to message-driven interactions.

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 and the business workflows.

For this, we decided on Node.js because it plays well in the context of a 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 http://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 Node.js web framework landscape there is no one clear winner with mass adoption unlike for Rails for Ruby or Django for Python. There are 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 had to drop 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 a fully integrated tool chain and very easy data to front end binding etc. But we had to drop it because the choice meant that we couldn’t have a pure Node.js runtime. Besides it was too opinionated , didn’t play nice with non-meteor specific third party components. Also, the front end was not switchable.

The decision then really 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 contributors

Loopback:

1705 commits, 44 branches, 95 releases, 62 contributors

Oh, well and we did not live happily ever after with Sails. The proverbial shit hit the roof for us when the Sails team splintered and a rival framework called Trails.js came up. Also, though Sails had some decent GitHub statistics, when we delve deeper most of it turned to be cosmetic changes like read-me updates.

The fallback to Loopback

Finally, we decided to go with Loopback, for the following reasons:

  • 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, the company behind Loopback which will only increase the commitment to the commercial suite of products and keep the dedicated team working on Loopback funded. Also, IBM has a good track record of contributing to open source projects like Apache Spark, Cloud foundry etc.

The jury is still out on whether our call is the right one. But we’ve been at it for a month now. If you are considering Loopback and want our detailed feedback, send me a shout out. I am Murali at our domain name if you are emailing me.

Author Bio

Ashwin Ramasamy

Slips poor jokes & gets away with a poker face. Carries a no BS attitude at getting things done. First to arrive at the office, Ashwin’s energy does not ebb through the day. Ashwin is one of the co-founders and he sets the tone for marketing, sales, design & culture.

  • Anatidae

    How’s Loopback for you so far?

    • PipeCandy

      Anatidae Some initial reactions:

      1. The documentation is very good.

      2. Built-in API explorer which means we don’t need to spend time creating API documentation.

      3. Clean separation between the API-Server and the client that consumes that API. It also has official AngularJS, Android, and iOS client libraries. FWIW, we are using React.js for the front end.

      So, we like what we see so far.

  • Anatidae

    How’s Loopback for you so far?

    • PipeCandy

      Anatidae Some initial reactions:

      1. The documentation is very good.

      2. Built-in API explorer which means we don’t need to spend time creating API documentation.

      3. Clean separation between the API-Server and the client that consumes that API. It also has official AngularJS, Android, and iOS client libraries. FWIW, we are using React.js for the front end.

      So, we like what we see so far.

      • raghu n

        Hi Ashwin,
        Can you share your expirience with loopback and react now that it is close to 6mths form the date of this posting

  • Pingback: Why we chose Loop over Sails and Meteor | Ideas2IT Technology Services Pvt Ltd()

  • Gagan

    Hey!
    We have also zerod in on Sail and Loopback. And it seems you have used both. One thought says that Sails offer MVC so we should be going that way.

    After using Loopback did you find it difficult or time consuming to have the MVC structure in place.

    • admin

      For us, Sails was a no go as the team has split and the original author is doing his own product and he pretty much said that no new features would come out in the near future. Also, we handle MVC on the client side. So server side MVC was not an evaluation criterion for us.

      I hope this answers your question

    • At Blu Frame we build our apps in React and from our point of view I can tell you that the lack of MVC is actually a plus! We just build the API in Strongloop and the front end in React ES6

      Works like a charm!

      Did you guys try doing that?

      • Gagan

        We started with Loopback but dev team soon started complaining about no MVC. They are all Java Spring background and kind of used to of MVC. I think we may switch back to Sails.js now.

        • Gagan

          Hey ASHWIN, What do you suggest?

          • PipeCandy

            I will ask my CTO to respond in a bit. He is travelling.

          • Do let us know. I have been playing around and zeroed down between Sails and Loopback. Meteor will be good too but I guess for building APIs, loopback would be better due to their API friendly features.

          • Murali Vivekanandan

            We considered Meteor too, but went with Loopback as it was more open for plugging in other components. Meteor was opinionated from frontend to backend.

        • ManuNZ

          Did you start to use Sails.js? I was decided to use it but I read bad post about the future. Now I am thinking in Koa but I am not sure, I would like a MVC framework too.

      • Martin Černý

        I have done the same with http://www.findoc.co.uk and I am really happy with it. It was the first time I used Loopback and React so everything was quite challenging. I started in June and I do not regret my choice.

  • I am trying to get Sails to work with React and I have not found a good solution, yet. How is your experience with Loopback so far? Any signs of IBM being a good partner to them?

    • Murali Vivekanandan

      Our experience building APIs using Loopback has been great so far. The IBM acquisition does not seem to have any material impact on the speed of development. Support is also a bit slow compared to MEAN forums.

  • Mohamed-Hassen Mami

    Hey,

    Thank you very much for the thorough insight !

    I’d be very interested in knowing how you have made your Loopback app working into a microservice context. Did you pick up others tools to perform this ? (docker ? kubernetes ? seneca ?) What are your guidance upon it?

    Thank you again.

    • Murali Vivekanandan

      We are evaluating Kubernetes vs Mesosphere.

  • ie5x

    Quick questions:
    1. Do you have client-side model validations? How are you doing that?
    2. What is your Flux strategy? Especially observing model changes and updating components accordingly.

    Thanks for the great writeup Murali!

  • Ravi Garg

    Hey, great read. That’s exactly missing on many other reviews and comparison. I am thinking of starting new app and after reading many reviews. did anyone try feathers or keystonejs framework, Just found both listed on expressjs site.

  • Are you still using loopback? If not what did you change to?

    • Jarred Filmer

      ^ would love to know how the decision panned out over a year later