Behind the Scenes: NixMash Home Banner Management

If you're reading this post on might have noticed the Home Page Banner on your way here. Here's a screenshot for those who haven't. The photos are Creative Commons Licensed with the attribution displayed at the bottom of the page.

Each day a different random banner is displayed from the pool of active banners. Banners can be archived, or deactivated and removed from the pool. In this NixMash post I describe how banner images were displayed in Spring. Since rebuilding NixMash from the ground up in Bootique I moved most of the display selection logic to a MySQL Stored Procedure found in this Gist.

I had been changing the active status directly in MySQL Console since remoting in Linux is so seamless that it's like performing tasks on your own PC. But as a weekend project I decided to put a face on changing Banner Image Status and built a Management Component. We'll walk through the highlights of that Image Management piece here.

Technologies used: Jersey, JavaScript, REST, Microservices, Mustache

Here's the Banner Management feature. The Current Banner is displayed on the initial, active Banners page. The top right-hand button displays the archived Banners no longer in the random display pool.

The Code

We'll jump straight to the code highlights. The overall logic is this:

  1. The button of each Thumbnail fires a JavaScript function, passing the ID of the Banner Image as a parameter.
  2. The JavaScript function performs a @POST to a local REST Controller method in the Web Module
  3. The Web Module REST Controller passes the Banner Image ID and an Application Security Key to a Post Microservice endpoint
  4. The Post Microservice Resource validates the Security Key and if valid performs the action.
  5. If the action Response is SUCCESS from the Post Microservice, the JavaScript function removes the Thumbnail Area from the board. A FORBIDDEN Response displays a corresponding Error Dialog Box Message.

The Thumbnail HTML

Here's the Thumbnail HTML with Mustache doing its thing of inserting the siteImageId and other properties where needed.


The JavaScript Function

Next is the JavaScript function, for our current item, the activateImage() function.

The Local REST Controller

Here is the Web Module Controller Method, passing the request along to the REST processing stage for transmission to the Post Microservice Endpoint.

Web Module Service Layer

The Web Module Service Layer intermediary method passes the ID to the REST Request to the Post Microservice and returns a Boolean success/fail indicator.

Preparing the REST Request

Still in the Web Module we need to package the @POST Request to our Post Microservice. Interesting here that we're performing a @POST Request but aren't posting an Entity of any kind. Instead the action is in the Request @PathParams.

Post Microservice Processing

Here in the Post Microservice the process completes if the Application Security Api Key is valid. A FORBIDDEN Response Status is returned if the api key is not valid, which invokes a Processing Exception in the Web Module REST Packaging Method and sends back a success/fail from the Service Layer method to the Controller.

Finally, the Web Module REST Controller Method sends a Response to the client JavaScript method which acts according to the Ajax StatusCode of 200 or 500. Both of those processes are shown above.