Hack Day 2018 was centred around giving ‘Power to the People’ — offering users a more hands-on approach to application configuration that hides complexity.
Inspiration
The Caplin Deployment Framework (DFW) manages the deployment of Caplin Platform components, and it is one of the most used products at Caplin. The DFW’s command-line interface already significantly reduces the complexity of deploying the components in a Caplin Platform stack, but in the interest of giving ‘Power to the People’, we set ourselves the goal of making it even easier to use by giving it a GUI.
The team
Grafical Dudezz is:
- Faris McKay
- Andy Sciascia
- Dylan Hamerzstein
- Jack Revell
Approach
We divided our work between a Node.js application running on the client and a Java process running on the server hosting the Deployment Framework. The Node.js application on the client served a JavaScript REACT front end, and the Java process on the Deployment Framework’s server managed interactions between the front end and the Deployment Framework.
To make the interface between the Java process and the Deployment Framework’s command-line interface (CLI) easier to write, we wrote a wrapper script for the CLI that transformed its output to JSON.
The front end
The front end communicates the user’s intentions to the Deployment Framework. It sends the server process a POST message containing an operation code that corresponds to a Deployment Framework command. The Java server process receives the operation code, executes the Java handler associated with that operation code, and returns a JSON response to the client. The front end displays the JSON output of the process in a small panel in the bottom corner of the GUI, formatted as a legible response message.
The front end detects blades dropped into the GUI and transfers them to the Deployment Framework using FTP.
All responses made by the server are either in JSON format or include an OK in the HTTP header, indicating that we can begin file transfer or that our message has been received and processed.
The back end
We wrote our server process in Java and packaged it as a Jar.
The server was written with an extensible architecture that modelled each operation as a class. The server listens on a Netty server socket for client requests and maps them to operation classes using the operation code included in each request. Some operation codes take parameters. For example, the operation code for the DFW command ‘deactivate’ includes a parameter naming the blade to deactivate.
For Hack Day, we concentrated on writing operation classes for the following core Deployment Framework commands:
- Start
- Stop
- Deploy
- Validate
- Activate / Deactivate
- Clean
We also created an operation class for uploading kits for later deployment. The operation reads the kit from client via FTP and writes the kit to the Deployment Framework’s kits directory.
Technology stack
Our technology stack comprised:
- Java server with Netty networking
- JavaScript React front end
Final word
With more time we would have redesigned the front end to manage multiple servers, and to allow deployment of licences and Deployment Frameworks too.
A future improvement would be to integrate the Java server process with the Caplin download site. This would remove the need for the client to FTP kits to the server.
Also, given more time, we would have liked to improve the design of the GUI, as it was quite basic and none of our team members specialise in UX.
Lastly, it would have been nice to allow users to download packet logs and other useful information from the server to help with diagnostics and support.