Developing a cloud based application

 

I was introduced to a new tool, swagger and  I didn't realize the wonderful development trip it would take me on.
I job was to create a cloud application and I was adamant I would work on the server side of the project and leave the GUI to more capable coders.

Swagger creates great documentation for the rest interface. The definition language uses the OpenAPI specification (formerly known as the Swagger Specification). An OpenAPI document that conforms to the OpenAPI Specification may be represented either in JSON or YAML format. I created my document in YAML format as per the "Petstore" example that comes with the swagger editor.


I initially decided to just create documentation for an api  interface. I figured once I generated the interface I could code the interface with one of the many different bindings to creating rest servers.

The online editor is used to create and validate the swagger rest specification file ver 2.

I wasn't sure how or if the OpenApi specification could be translated to code but swagger produced great documentation and was happy to use it as just as a great documentation tool.

Using the OpenApi specification I documented a few interfaces, but where to next?

The tool also comes with a code generator that generates client & server code bindings. It brings with it over 50 client and server bindings which you can incorporate into your code base.


With over 50 bindings I spent a great deal of time trying to determine which server/client code I should generate with the swagger code generator.

The GUI coder wanted to create a server in nodes.js.

I wanted to create a server in quick time written in Java as I liked the IntelliJ IDE and wanted to code in Java.

I settled on the spring boot binding as it compiled out of the box and could service rest api calls straight from generated code.

The front end was being written in React a toolkit from facebook.

The react generated javascript could call rest endpoints directly so we generated client javascript bindings which could be easily incorporated into the react code base and springboot server bindings.

Springboot was also a great revelation, its massive code base made creating a rest server with a backing database easily and resilient.

The springboot framework was extensive and mature. I
entered the world of:

• Java JPA (Postgres to Pojo)
• pki authentication/certificates
• Jackson Json conversion (Pojo to Json)
• Mochito testing
• Roles/User management
• ...

Springboot like java is a world unto itself but it's longevity and maturity meant that my requirements were fully catered. I added Lombok a java library that automatically plugs into intellij editor. Lombok provides us with Kotlin like semantics.

The backing store I chose was postgresql which fitted seamlessly into Java JPA bindings. I chose postgres as it was free and mature. I was actually quite happy with it and it's performance on my VM server was startlingly quick. I tried to switch to testing with in-memory DB server with little success.

Using git with my favorite version control tools, gitk, git gui and gitlab working in a team was not a problem and use the gitlab application to perform code reviews meant the team (of 2) could spread the knowledge base for the application between us both. When we created a code merge on gitlab, gitlab causes Jenkins to run our test suite. The results of the test are incorporated into the merge request. So when doing the code review if the test suite passed the code review could proceed. If the test suite failed the programmer was sent back to his desk to make the the regression test suite pass.

Drawing for schemas and process workflows was done using graphviz my favourite graphic drawing tool. The advantage of using graphviz is that the source of the graphs can be put into version control.
The project was managed using the Atlassian Kanban model for agile software development, with Atlassian Jira handling ticket management and the Atlassian Kanban board.