Visitor Logging in a Microservices Application

I described the all new NixMash.com Microservices application in a recent post. In it I mentioned that many processes are more complex with Microservices because we're passing data among the various application components. In this post we will observe why even simple processes like logging visitor activity are more complicated in a Microservices Application.

Before getting into the code, here's a review of the layout of NixMash Microservices. The Web Module communicates with the Post Microservice through REST, which in turn communicates with the Util and Solr Microservices through RabbitMQ Message Queues.

The Process

With our application design, the process of logging visitor activity goes like this:

1. Obtain client info in the browser and pass it to a Controller in the Web Module as JSON.
2. Extract the ClientInfo object to apply any business rules, then convert it to a JSON Entity and pass it to a Resource Endpoint in the Post Microservice with REST
3. Extract the ClientInfo object in the Post Microservice and pass it to a RabbitMQ Queue as a Byte Array
4. Pick up the ClientInfo object from the RabbitMQ Queue in the Util Microservice and save it to MySQL.

The process of logging visitor activity in a Monolithic Application, on the other hand, would be this:

1. Obtain client info in the browser and pass it to a Controller in the Web Module as JSON.
2. Extract the ClientInfo object to apply any business rules, then save it to MySQL.

Obtaining Client Info in the Browser

This step would be the same in any application design. What's interesting is the use of Mustache to obtain the Post ID and how we're determining if someone is using an Ad Blocker by seeing if any iframe elements are present on the page.

The Web Module

The ClientInfo JSON is sent to our Web Module Controller method, then packaged for transport to our REST Post Microservice Endpoint. Here's the REST packaging of our ClientInfo object for the microservice.

Post Service Module

In the Post Microservice the ClientInfo object is retrieved…

and placed on the RabbitMQ Queue as a Byte Array.

The Util Microservice

The Util Microservice monitors the RabbitMQ Queues as the Server, with the Post Microservice the Client. We're using two RabbitMQ Queues for our Utility processes, a one-way Queue and a two-way communications RPC Queue. Here we're using the one-way Queue, not requiring any response from the Util Microservice for our logging task.

Our task key is LOG_CLIENTINFO where you see we extract the ClientInfo object and can finally, finally, log the visit in MySQL.

We covered a lot of code here, and didn't even display all of the code involved in the process. The important point here is that if we were coding a Monolithic Application, the utilService.logClientInfo() call would have appeared in our Web Module /log Controller method and we would've been done.

Microservice design trade-offs…