Why we built our ESB using Node.js
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.
Making life a bit easier with Node.js
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 the 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. Instead of relying on the platform to be reliable, it might be wiser to just assume the platform to be unstable and tackle such issues by design and cloud solutions.
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 common to find 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 a cache, and expose cached results through your API. Node.js makes a lot of sense as a composer of microservice architecture, as an integration tool and generally works as an ESB replacement everywhere.
Consider giving Node.js a try next time you’re evaluating ESBs or integration tools. You don’t have to go all in, start with a 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.