.png)
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.
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
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 is a lot of fragmentation with each framework having some nice features but with very little adoption.
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.
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 readme updates.
Finally, we decided to go with Loopback, for the following reasons:
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.
Update: Almost a year later, we decided to reflect on our decision to go with Loopback. You can read the article here
.svg){kind=logo}
RT @RangaEunny: Until recently the Amazon and Shopify systems were separate and distinct groups of entrepreneurs. But they have started to…
Every week we send out tidbits that capture the eCommerce industry and its evolution, right to your inbox. It's free. No spam. Choose to opt-out whenever.
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
