Microservices Chatbot and Coronavirus

A few weeks ago I shared a short post about a new initiative of mine to have a fun bot to make life much easier in connection to the Coronavirus running these days. The project is around providing a new fun bot to ease the isolation that became part of Coronavirus for many of us.

Here, technically wise, I’m going into details and share my journey.

Microservices are well spread these day, most of the modern projects are built around Microservices.

In terms of ease of development and DevOp activities Microservices take it by far. As this article is not around Microservices, I won’t put many words here, but you can read about that or Google for more details.

Details on chatbots can be found here , here or using Google.

What I’m going to discuss here is the integration between the two, Microservices and the bot itself, more of a description of the journey I passed.

First let’s take a quick look at the overview of the system:

And we’ll start with the Back-end.

The Back-end runs under Vert.x. Vert.x can be found here. In general, Vert.x is an open source to build asynch, reactive and functional code that runs on JVM (jdk8+). Vert.x is well known and very popular and enables us to speed writing code. Basic application can be built in a few days with the help of Vert.x and app-microservice (another open source that is about to go public soon and provide services like ServiceDiscovery, Authentication/Authorization, Vault, Resource uplaoder and many more).

The pipeline is run by the main mediator. And it goes like this:

1. The incoming sentence is move thru a transformation process, where typos are removed (‘the correction’, for instance, ‘adress’ goes to ‘address’), contractions (‘the contraction’, for instance, ‘I’m’ goes to ‘I am’) are handled, and a few more are taken care of, for instance,’ the formatter’ that removes CR, so at the end we get a valid sentence.

2. When ready, the Bot service takes control and generates a response (‘the bot service’).

3. The final stage is the postprocesing that, for instance, capitalizes the first word if written in English.

So in term of flow we get something like this:

The Back-end is driven by a dynamic resource system. For instance, communications between Microservices and the Front-end are based on JSON that’s validated by schemas that are loaded by the resource system. Each time the protocol between the units is changed, we only need to drop a new version of the new schema, and the resource system will do the rest.

The same goes to any other resource that’s used by the Microservices system. For instance, we can upload a new version of and updated of the ‘corrections’ without restarting the system.

Hazelcast is used, in conjunction with Vert.x, to scale the request via a distributed EventBus. So the system can easily scaled just by running more instances. That’s because the Microservice doesn’t hold a state.

The Front-end is quite simple and runs by three open sources, JQuery, Revive and Vert.x SockJS event bus bridge. JQuery and Revive provide the UI. Communications go via WebSocket (WS) that is integrated seamlessly by Vert.x and the bridge.

The system was tested successfully to run more than a few dozen of thousands of concurrent connections on a single VM with a very low CPU.

I hope to find some more time to drop a few words on the DevOp design on a separated article.

A live demo of the project can be found here: https://backupserver.info.gs:8080

Thank you all!