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.

Code

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.

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.

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.

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.

Conclusion

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.