Eclipse Vert.x based Framework URL Shortener Backend

Re­cently, I stum­bled upon Vertx. Event-​driven, asyn­chro­nized, light­weight, re­ac­tive, highly per­for­mant, poly­glot ap­pli­ca­tion frame­work. Ideal for writ­ing micro-​services. I played around with it for a while and re­ally en­joyed the con­cept of server­less ap­pli­ca­tions.

I de­vel­oped a few apps and cases and started to won­der how to run and de­ploy them so that I get a 100% re­li­able ser­vice. I sud­denly re­mem­bered the tech sem­i­nar that I at­tended re­cently, specif­i­cally ses­sion about server­less apps with AWS (Ama­zon Web Ser­vices) Lambda. Lambda is a server­less com­pute ser­vice that runs your code in re­sponse to events and au­to­mat­i­cally man­ages the un­der­ly­ing com­pute re­sources for you. Fairly sim­i­lar con­cepts Vertx and AWS Lambda, so maybe they com­ple­ment each other? As it turns out they do, Vertx can get most of your Lamb­das

Using the Server­less Frame­work to cre­ate, man­age and de­ploy your new Lamb­das I was able to get this micro-​service up and run­ning in no time.

Enough with the talk, lets see the im­ple­men­ta­tion.


Han­dler Class, entry point of AWS Re­quest.

The first issue that I had was the sync Event Han­dler that is pro­vided by AWS. So I had to by pass it with Fu­ture. In the Han­dler class I first ini­ti­ate Vertx in­stance in a sta­tic block and de­ploy few Ver­ti­cles that will do the work. This class only re­ceives the event, ex­tracts needed data from the re­quest and passes the data to Vertx Event­Bus. After the Con­sumers han­dle the re­quest, Han­dler class will gen­er­ate a proper re­sponse and fin­ish the AWS re­quest.

...waiting for Gist...

Line 4-18: This is where Vertx in­stance is cre­ated, Ver­ti­cles are de­ployed and Async JDBC client is cre­ated. I fig­ured out that it is bet­ter to cre­ated JDBC client here as in some cases I was time­out when that logic was in the Ver­ti­cle start method.

Line 27-36: These are helper lines, pars­ing and for­mat­ting the data so I can pass it to the Ver­ti­cles.

Line 38-45: I have de­cided to map the con­sumers to the ad­dress that is made of re­quest method and url path, ex­am­ple POST/api. This means each API re­quest is mapped to its own con­sumer in Ver­ti­cle class.

Line 47-77: This is noth­ing but a block of code that han­dles the re­sponse that was passed from Ver­ti­cles to the Fu­ture and gen­er­ates the final re­sponse that will be re­turn to API Gate­way.

UrlSer­vice, Vertx Ver­ti­cle.

Ver­ti­cle class is pretty for­ward. Con­sumers that will process the mes­sage, meth­ods for work­ing with JDBC and helper meth­ods for hash­ing/de­hash­ing id. The logic be­hind url short­en­ing is fairly sim­ple here. Each long url is stored in data­base with a unique id and few ad­di­tional columns. Row id is hashed and re­turned as short url. When re­triev­ing long url hash is de­coded to row id and long url is re­trieved. Later user is redi­rected to long url. With this im­ple­men­ta­tion, on 6 char short url (char­ac­ters after the do­main) you get 62^6 com­bi­na­tions which is 56 800 235 584 rows for stor­ing your urls. TinyURL is cur­rently at 6 long char urls (char­ac­ters after do­main). You can of course im­ple­ment meth­ods for reusing and re­cy­cling ids.

...waiting for Gist...

As said, this is all fairly straight for­ward, if you are al­ready fa­mil­iar with Vertx. If you are think­ing why have I re­peated the code for es­tab­lish a JDBC con­nec­tion, here is the ex­pla­na­tion (line: 10-16). I was get­ting Time­outs when cre­at­ing JDBC con­nec­tion in Ver­ti­cles. To avoid this I also added this code to my Han­dler class. This way con­nec­tion is cre­ated there and be­cause of the Vertx im­ple­men­ta­tion any later at­tempt to cre­ate it again will re­sult in just get­ting the in­stances from the first in­vo­ca­tion. This es­caped the need to pass the in­stances di­rectly from the Han­dler class when cre­at­ing Ver­ti­cle in­stances.

Server­less con­fig­u­ra­tion.

Lastly I would like to share the server­less.yml, con­fir­ma­tion file that al­lows seam­lessly de­ploy and man­age­ment of AWS Lambda. With just a few com­mands and lines of con­fig­u­ra­tion you are able to con­fig­ure all nec­es­sary steps for de­ploy­ing your AWS Lambda. Frame­work takes care of mak­ing con­fig­u­ra­tion of Api-​Gateway and other AWS has­sle that would oth­er­wise needed to be done by hand. In this case Lambda is in­voked by HTTP events.

...waiting for Gist...

Performance and Tests

Vertx async ca­pa­bil­i­ties eased the stress and mem­ory needs of tra­di­tional AWS Lamb­das with sync meth­ods. After per­form­ing load tests Lamb­das that were writ­ten using Vertx frame­work pre­formed 10% faster and con­sumed 40% less mem­ory. As I have read some­where in Vertx doc­u­men­ta­tion, Sync meth­ods will def­i­nitely fin­ish the first re­quest faster but in total Async will be faster in the end. This sav­ings in mem­ory and time will def­i­nitely re­duce the cost of run­ning your Lamb­das and the lit­tle over­head with ad­di­tional code is for sure worth it.


To fol­low the pace of de­mand­ing needs for fast and re­silient ser­vices we need to move from tra­di­tional Mono­liths. Em­brac­ing the micro ser­vice ar­chi­tec­ture alone will not cut it, not any­more. With the rise and rapid ad­vance­ment of Cloud so­lu­tions it has never been so easy to make a truly Server­less sys­tems build upon net­work of micro ser­vices. As you have seen Vertx with its async API makes the full ad­van­tage of AWS Lamb­das, em­brac­ing them while also im­prov­ing the per­for­mance and low­er­ing the costs. With the help from Server­less Frame­work writ­ing, de­ploy­ing and man­ag­ing your Lamb­das has never been so easy.

If you are in­ter­ested in the whole project, you can find it on GitHub.

This is a re-​publication of the fol­low­ing blog post

Next post

Eclipse Vert.x 3.5.1 released!

We have just released Vert.x 3.5.1!

Read more
Previous post

TCP Client using Eclipse Vert.x, Kotlin and Gradle build

In this blog post, I demonstrate how to write a very simple TCP client that keeps a connection open to a custom-written server in cloud.

Read more
Related posts

Real-time bidding with Websockets and Vert.x

The expectations of users for interactivity with web applications have changed over the past few years. Users during bidding in auction no longer want to press the refresh button.

Read more

Some Rest with Vert.x

This post is part of the Introduction to Vert.x series. Let’s go a bit further this time and develop a CRUD-ish application

Read more

Building services and APIs with AMQP 1.0

Microservices and APIs are everywhere. Everyone talks about them, presentation slides are full of them ... some people are actually even building them.

Read more