Dynamic Routing in Serverless Microservice with Vert.x Event Bus

Serverless framework

The Server­less Frame­work has be­come the De Facto toolkit for build­ing and de­ploy­ing Server­less func­tions or ap­pli­ca­tions. Its com­mu­nity has done a great job ad­vanc­ing the tools around Server­less ar­chi­tec­ture.

How­ever, in the Server­less com­mu­nity there is de­bate among de­vel­op­ers on whether a sin­gle AWS Lambda func­tion should only be re­spon­si­ble for a sin­gle API end­point. My an­swer, based on my real-​world pro­duc­tion ex­pe­ri­ence, is NO.

Imag­ine if you are build­ing a set of APIs with 10 end­points and you need to de­ploy the APIs to DEV, STAGE and PROD en­vi­ron­ments. Now you are look­ing at 30 dif­fer­ent func­tions to ver­sion, de­ploy and man­age - not to men­tion the Copy & Paste code and con­fig­u­ra­tion that will re­sult from this type of set-​up. NO THANKS!!!

I be­lieve a more prag­matic ap­proach is 1 Lambda Func­tion == 1 Mi­croser­vice.

For ex­am­ple, if you were build­ing a User Mi­croser­vice with basic CRUD func­tion­al­ity, you should im­ple­ment CREATE, READ, UPDATE and DELETE in a sin­gle Lambda func­tion. In the code, you should re­solve the de­sired ac­tion by in­spect­ing the re­quest or the con­text.

Vert.x to the rescue

There are many ben­e­fits to using Vert.x in any ap­pli­ca­tion. With Vert.x, you get a rock-​solid and light­weight toolkit for build­ing re­ac­tive, highly per­for­mant, event-​driven and non-​blocking ap­pli­ca­tions. The toolkit even pro­vides asyn­chro­nous APIs for ac­cess­ing tra­di­tional block­ing dri­vers such as JDBC.

How­ever, for this ex­am­ple, we will mainly focus on the Event Bus. The event bus al­lows dif­fer­ent parts of your ap­pli­ca­tion to com­mu­ni­cate with each other via event mes­sages. It sup­ports pub­lish/sub­scribe, point to point, and request-​response mes­sag­ing.

For the User Mi­croser­vice ex­am­ple above, we could treat the com­bi­na­tion of the HTTP METHOD and RESOURCE PATH as a unique event chan­nel, and reg­is­ter the sub­scribers/han­dlers to re­spond ap­pro­pri­ately.

Let’s dive right in.

Goal

Cre­ate a re­ac­tive, message-​driven, asyn­chro­nous User Mi­croser­vice with GET, POST, DELETE, PUT CRUD op­er­a­tions in a sin­gle AWS Lambda Func­tion using the Server­less Frame­work

Serverless stack definition:

Solution

Use Vert.x’s Event Bus to han­dle dy­namic rout­ing to event han­dlers based on HTTP method and re­source path from the API input.

Lambda Handler:

Code review

Lines 14-19 ini­tial­izes the Vert.x in­stance. AWS Lambda will hold on to this in­stance for the life of the con­tainer/JVM. It is reused in sub­se­quent re­quests.

Line 17 reg­is­ters the User Ser­vice han­dlers

Line 22 de­fines the main han­dler method that is called when the Lambda func­tion is in­voked.

Line 27 sends the Lambda func­tion input to the (dy­namic) ad­dress where han­dlers are wait­ing to re­spond.

Lines 44-66 de­fines the spe­cific han­dlers and binds them to the ap­pro­pri­ate chan­nels (http method + re­source path)

Summary

As you can see, Vert.x’s Event Bus makes it very easy to dy­nam­i­cally sup­port mul­ti­ple routes in a sin­gle Server­less func­tion. This re­duces the num­ber of func­tions you have to man­age, de­ploy and main­tain in AWS. In ad­di­tion, you gain ac­cess to asyn­chro­nous, non-​blocking APIs that come stan­dard with Vert.x.

Server­less + Vert.x = BLISS