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

Houghton Mifflin Harcourt: Why we built our ESB using Node.js - Reaktor

<b>Integration is one of the core problems in the IT industry.</b> 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 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&nbsp;to just assume the platform to be unstable and tackle such issues by design and cloud solutions.

<b>Node.js is a surprisingly good integration platform in itself</b>, but can be made better with a little bit of extra help. <a href="http://bluebirdjs.com/docs/getting-started.html">Bluebird</a>, 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. <a href="https://baconjs.github.io">Bacon.js</a> 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 common&nbsp;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&nbsp;composer of microservice architecture, as an integration tool and generally works as an ESB replacement everywhere.

Consider giving Node.js a try next time&nbsp;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.

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.

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. <a href="https://reaktor.com/cases/hmh/">Read more about our work with Houghton Mifflin Harcourt. </a>

Related content

“It’s all about the money” – Our takeaways from AWS re:Invent 2022

So you changed your website. How do you now measure success and avoid common A/B mistakes?

Is Recoil What Will Kill Redux?

How to deal with life after heroku

MLOps: Making machine learning production work

GraphQL academy — How Reaktor has allowed me to go from a junior developer to a specialist and instructor

Little server patterns: failing quickly

Little server patterns: dependency parameters

Serverless-side rendering: dropping it like it’s hot without breaking the internet