Switching web programming paradigms with vert.x

When I first combined the Internet and programming it was the second half of the 90’s and all I knew was Java applets. Oh, there was also CGI but I somehow managed to skip over it. The approach was then quite natural: write small programs which will run in the browser and grab data from other programs – run in either other browsers or on the server. Or on other servers. I’m not saying the idea was easy and I only got that far before I moved on to other professional areas. Later when I came back to the web, things had settled differently: you had a servlet specification, a multitiered application to support them, big servers and everything was clear. Of course there was some bit of fight over technologies, gradual improvements here and there but the model was there already.

Fast forward. We are witnessing today full MVC frameworks running on the client side – heresy! We see web servers reduced to data services called over very basic interfaces like REST. We have full blown applications requesting data from servers all over the world, synchronizing real-time information and transacting your information (or your money) all over the place. I’m not talking only about gaming or e-banking – even what it might look to you like a regular website could be very well following the same model behind the scenes. If I look around today I’m tempted to say the paradigm is shifting, or rather is switching back to the distributed computing model I was barely scratching twenty years ago. You know something? I’m really thrilled by this! (I probably never managed to outgrow my distributed model, see also my older blog entry reaffirming it)

When I ran into the vert.x platform I was immediately and without any obvious reason intrigued. I mean, if it’s different from anything I used so far, why should I just fall for this event bus – not nearly as famous as Akka? Or why would I care about its polyglot programming, when I never wrote more than 50 JavaScript lines in any project I worked and all my applications are Java and maybe C++? I started slowly with my own tests trying to figure out WHY is this platform existing, and why would I care about it. I perused the mailing list, talked to people at its core or power users and after a few months I think I will just have to like it some more.

Vert.x is a kid of the modern times, I have no doubt about it anymore. I don’t say this because it builds upon Netty (and HazelCast)… Its heavy features are unfortunately not so obvious from the website and if you’re coming like me from building web applications chances are big you will overlook them. What am I talking about? For example, how quick are your DevOps firing you new instances of your application? True, with today’s virtualization, cloud thinking and sophisticated deployment and configuration management tools it works almost fast enough, but what if you don’t want a new machine but just a few more instances on this one? Well, how much time you need for entering a value in one vert.x config file? That was the answer to your upscaling issue, with no other configuration, installation or anything. If you don’t see this as advantage maybe your application just never had to support more than hundred users. Hey, there’s nothing wrong with that! There’s always a place for the “traditional” web applications, but if your brainchild happens to grow it feels comforting to have such flexibility at your fingertips. But… you will ask, how do you reliably pass data among so many cheap instances? Enter the vert.x event bus. No, it’s no RabbitMQ über fancy Erlang based solution, instead again a minimal thing built on purpose – which just works, say many happy power users. Before you ask the answer is yes, you can secure it as well (and you should) and not only when it works over WebSockets. Right, you can reach to this event bus even from your browser tier and you won’t ever need special web services be they RESTful or not (unless you really want to, but that’s your decision). Your web page won’t become the semantic web poster child anymore but if you actually build web applications, chances are you will care less. What you will have instead is a fully asynchronous application and top fast at it (as the TechEmpower benchmarks constantly show) where you can still plug synchronous workers if your really want to: JDBC, Spring, you name it. If it’s not there you can easily build and plug it in because it’s an event bus – by definition modular.

The vert.x way is not everybody’s way, of course. It would be very naïve to think so – although I can see this kind of reasoning whenever somebody ponders the change to a new environment. The fact is, it’s not always about reusing your skills, sometimes it’s about adapting to new realities. Riding the wave if you want to, or putting it for the more conservative thinkers, just taking advantage of the new world. A new world of extremely powerful clients and multicore backend machines*.

PS: and polishing in the meantime your mastering of reactive programming (and maybe promises) won’t hurt either…

*) I know, I could have mentioned fast internet as well, but with the advent of the mobile platforms your web page loading time might feel like the 90’s all over again.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.