Integration is one of the core problems in the IT industry. You know the drill – every business has legacy systems waiting to be connected to new services. Sometimes you need to compose a new application out of a fistful of microservices, at other times you agonize over the best platform on which to do your SOA orchestration.

This is where enterprise service buses, ESBs, come into play. Every big brand – Oracle, IBM, Microsoft, the list goes on – has their own, and there are multiple open source alternatives that compete with the big brands.

The thing is, all of them suck just as much.

In software development, the best tool for a certain task is often the one that offers the right amount of abstraction. Too much, and you limit the things you can do, or too little, and you end up wasting time.

Evaluating ESBs is no different. You want the one that enables you to solve the problem at hand, with minimal amount of work, and you know what: there is no particular reason why your ESB should be a product. Sometimes it is good to think outside the box or certain market niche.

Six months ago, we were tasked to help Houghton Mifflin Harcourt (HMH), world-leading educational publisher, to integrate their backend systems to two new services.

We set off by selecting Node.js as the platform for integration.

Speed of development was what we considered the most important factor of success. We also felt that Node.js would offer just right level of abstraction for this case. You can build the most complicated and time-consuming features, and it is still easier to fetch and compose data with Node.js than with most traditional ESB products.

We marked that Node.js enjoys a bad reputation of being unstable and not “enterprise ready.” While partly true, no application platform is a hundred percent stable, and instead of relying platform to be reliable, it might be better to just assume platform to unstable and tackle such issues by design and cloud solutions.

Node.js is a surprisingly good integration platform in itself, but can be made better with a little bit of extra help. Bluebird, one of the most popular promise libraries, offers that extra little bit of control in orchestrating asynchronous calls, whether you want things done in parallel or sequential fashion. Bacon.js does the same, but we found Bacon.js buses to be at their best as the main structure of an integration. The asynchronicity of javascript really plays well in integrations.

One of the advantages of using the Node.js ecosystem as an ESB is that you can boost the performance of your legacy services rather easily. It’s typical to find out that some of your existing APIs are lacking in performance, and improving them might either be costly or near impossible.

With Node, you can easily add things like Elasticsearch as cache, and expose cached results through your API. Node.js makes a lot of sense as composer of microservice architecture, as an integration tool and generally works as ESB replacement everywhere.

Consider giving Node a try when you are evaluating ESBs or integration tools next time. You don’t have to go all in, start with proof of concept and expand from there. It might be the best decision you ever made.

Take it from us:

Being an educational publisher, HMH has a strict yearly cycle – the back-to-school season is in the fall. Weeks before back-to-school start we had the first version running, tested and in production, ready to support eager students returning to school.

Oh, and we were a year early.

We attribute the success mostly on selecting the right tool, but also focusing on what was the absolutely minimum set of features for a viable product. Read more about our work with Houghton Mifflin Harcourt.

The post Why we built our ESB using Node.js appeared first on Reaktor.com.