In the the initial post of the  Event-driven microservices with Kafka series (see here  or  here ), I talked about the advantages of using event-driven communication and Kafka to implement stateful microservices instead of the standard stateless RESTful ones. I also presented the architecture and the source code of a related proof of concept application. In this post, I would like to show how to extend the asynchronous event-driven communication all the way from Kafka to the Web frontend passing through the Java backend. Hence, in the first post of this series, we got rid of HTTP as the communication protocol among microservices in the backend, and now we are also replacing it (with WebSockets) as the communication protocol between the frontend and the backend. Ok, but why would you do that? Because it provides a better experience to the end user!. Using WebSockets you can build legit  real-time user interfaces, the updates are pushed immediately from the server to the client

When talking about microservices architecture, most people think of a network of stateless services which communicate through HTTP (one may call it RESTful or not, depending on how much of a nitpicker one is). But there is another way, which may be more suitable depending on the use case at hand. I am talking about event-driven microservices, where in addition to the classic request-response pattern, services publish messages which represent events (facts) and subscribe to topics (or queues depending on the terminology used) to receive events/messages. To fully understand and embrace this new software design paradigm is not straight-forward but it is totally worth it (at least looking into it). There are several interconnected concepts which need to be explored in order to discover the advantages of event-driven design and the evolutionary path which led to it, for example: Log (including log-structured storage engine and write-ahead log) Materialized View Event Sourcing C o

First of all, sorry for the  tautology  in the title, a library can be either opinionated or un-opinionated (such as Vert.x  is), but an application can only be opinionated. However, I decided to include "opinionated" to help getting my point across even though is redundant. The Motivation  I am a big fan of Vert.x and the official documentation is quite good, yet it is not straight-forward to understand how it works and how to use it. There are a lot of blogs and articles describing Vert.x terminology and its concurrency model. There are also tons of "Hello World" Vert.x applications on Github, and the rest seem to be just variations of the already typical " Web chat application using Vert.x ". On top of that, many of them are outdated (using AngularJS instead of Angular2+, for example). The only two exceptions which I found are: vertx-microservices-workshop : a demo application by the Vert.x development team. ngrx-realtime-app : proof of conce

The Motivation I am an experienced Java developer and (surprise!) I like Java. I know it is not perfect but it works just fine for me (I enjoy type-safety and I do not consider verbosity a disadvantage, quite the opposite). I also know that some people dislike Java, which is also fine. But recently I decided to step out of my confort zone as developer, my goal isn't to be one of the "cool kids" neither trying to monetize a new skill in the job market. I have a quite practical motivation: I want to be able to build more (different) stuff. That's exactly the same reason why I learnt Android development by myself a couple of years ago. Web applications are ubiquitous, even more than native mobile apps, and thanks to cloud computing, one can easily and inexpensively release their idea/app to the World Wide Web. I already did some Web development in the past, in the bad old days of JSP and JSF, but the process was slow and painful. Nowadays the Web landscape h

The Twitter API was one of the first available from a major Internet organization and it is probably the most used API worldwide, even though in the past few years Twitter has been making it tougher for developers to use it, you may check this as an example. Not everybody is on Twitter but almost every company is, specially big telcos. Most of them even provide customer support through Twitter, and despite being usually terrible (the support), at least it is an open channel and you can share your frustration with other frustrated fellow customers. Motivation So when one of the major telecommunications operators in Spain started aggressively chasing my mom and my whole family because someone used her name and national identity number to fraudulently buy services from them which were never paid (it seems they intentionally? have barely any security controls in place), I decided to take revenge on Twitter. I've got very mad, Jazztel (the telco) was not interested in finding t

I have been reading quite a lot about  Vert.x  recently and finally the day before yesterday I sat down and spent some time exploring it by writing some code. Today I would like to present the outcome. A little bit of history Like all Reactive frameworks/tool-kits/libraries, Vert.x is inspired by Node.js. Back when it was released, Node.js shocked many Java developers who looked down on Javascript, on top of owning the Web client side, JS wanted to conquer also the server side! And thanks to its non-blocking nature, Node.js performed better than typical Java application servers such as Tomcat or Glassfish. Then the Java world reacted (pun intended) and today Vert.x is one of the most matured reactive technologies for the JVM. First Vert.x application  When trying to build my first super-simple reactive  (not really) application using Vert.x, I started following  this tutorial  from the lead developers of Vert.x. That's great stuff, but I found it a little overwhelming