This is a post I wrote, on the caching infrastructure work I did at Flickr:
Monday, March 16, 2015
Vert.x: Catching My AttentionI recently attended an awesome talk by Steve Pousty on Vert.x, and I found this technology so intriguing, I had to dig deeper myself. This post summarizes why I think Vert.x is so promising, and takes a look at my own exploration of the technology.
More About Vert.X
I think Vert.x has a really cool combination of features for or creating application servers. I will focus on the two aspects I find most powerful. First are the APIs that "enable you to write non-blocking network enabled applications." Vert.x is a productive abstraction over netty.io, with an API that makes it easy to set up servers. This feature lets one build servers in JS (or whatever), very similar to node.js. There are even projects for running node.js and Rack applications on Vert.x, but that is a topic for another day.
The second feature of Vert.x that I find so compelling is the built-in, distributed event bus, combined with an actor-like processing model. This allows developers to write clean back-end logic, in whatever language makes sense, and capitalize on concurrent and parallel processing, shielded from the gory details. A flexible deployment model allows you to distribute the pieces how you see fit.
If the potential of these features is still not grabbing you, let's look at the demo, and then I will try to drive it home at the end.
For my simple demo, I set up a dead-simple server that handles a few routes and responds with ugly plain text. There is not much to it, just a tiny sketch of how a restaurant site with ratings might work. The whole demo is on GitHub.
In the previous gist, line 2, we add a route to a routeMatcher object, then proceed to pull out the params in the handler. Later on, we set up a server that handles all the routes:
What's the Big Deal?
In addition to the single-process simplicity afforded by Vert.x, one can also deploy Verticles as separate nodes, and the distributed capability of the event bus will handle the interprocess communication, effectively turning a concurrent application into a parallel one. And changing deployment models should entail little or no change to core logic. I think this is awesome because one can develop quickly as a monolithic-style app, and then deploy as more of a microservices architecture--scalability options are there from the beginning.
In the future, I want to dig deeper into building application architectures on top of Vert.x (with suitable abstraction of the framework of course). I envision a JS presentation layer where some POJO logic is shared between the client and the server-side, with lightweight TCP communication between them. For the backend logic I want to explore how a clean or hexagonal application layer would look combined with a message bus API. Putting it all together, I have a foggy notion of a new stack that ultimately might have some frameworks or tooling around it. In my head I've been calling it "mystack." Stay tuned for further developments if you like where this is headed.
*Note: I have not experimented with the scalability of the distributed event bus, but I give Vert.x the benefit of the doubt for now.
Posted by John at 7:36 PM