Category Archives: Techniques

New Techniques: Single Page Application

In my previous blog, I wrote that I’m developing a new tool: Featrz (featrz.com). Go ahead take a sneak-preview. You can see some Demo-features by selecting a Project from the top-right corner.

Bootstrap

For the GUI, I used a Single Page Application. I was a bit hesitant at first, because it meant for me to learn a lot of JavaScript as well. But the architecture makes more sense to me: initially loading all the HTML, CSS, and JavaScript and after that it is just REST messages going back-and-forward. At least this makes more sense for this application.

I made a choice for Bootstrap where it could have been Vue.js, Angular or any other framework. At that time Bootstrap was just what I heard most around me. Nowadays I probably would have picked Vue.js. It will be interesting to see if Bootstrap can be easily replaced without harming the architecture and giving me the same benefits (see below). But that’s for another time.

Unit Tests for JavaScript

Since JavaScript was new to me, I wanted to use it in a clean manner. Not the hacky scripting way, but more in a structured OO way. And I wanted to create automated checks for them as well. I figured that if half of the lines of code of the entire tool is in JavaScript, I must have Unit-tests for that JavaScript as well. Using classes was the logical thing to do.

But I took it a bit further. I separated the data (model) from the services and the services from the views and controllers, creating a Model-View-Service structure. It allowed me to test the Services in a Unit Test manner, i.e. very well isolated, using mocha.

Note that JavaScript does not prevent you to take short-cuts. This comes down to just don’t do hacks and a lot of self-discipline. Even if you keep to this, JavaScript will give you enough challenges with Callbacks, Promises and plain magic in some libraries. Most examples on the internet (yes, I google a lot) are not applicable for the way you want to use JavaScript (e.g. different ES-level, Browser-side vs Client-side). I learned a lot, but most importantly that JavaScript is BIG and a lot of libraries and solutions exist for the same problem. Don’t try to master it at first, but rather keep it simple and don’t use things that you don’t understand. Or else learn to understand it and adding Unit Tests certainly helps with that.

Conclusion

I’m very happy with the Single Page Application setup in combination with JavaScript Classes and MVS structure. Since I do switch a lot between Java and JavaScript, I had no problem switching back to JavaScript and understanding the code quickly. I don’t think I could have said the same when it was a big 1-file script.

But I’m also very pleased with the set of Unit Tests to run on the code. I’ve just seen too many examples where Unit Tests were well in place on the server, but when it comes to GUI tests, the JavaScript logic is tested with Selenium in Integration or End-to-End Tests. The structure I used here checks the JavaScript logic on the right level, i.e. Unit-level, resulting in quick feedback with low maintenance.

New Techniques: Quarkus

In the past year or so, I’ve been working on Featrz (featrz.com). Go ahead take a sneak-preview. You can see some Demo-features by selecting a Project from the top-right corner.

Interesting about this application are the used techniques. Whenever I hear about a new technique on a conference or in a blog, I make a note of it with the intention of trying it out. To see if it is really useful and will work in a real project. Not a Helloworld!-application, but with security, a real database, a CI pipeline, and of course, automated checks. One of those techniques that I noted is Quarkus.

Quarkus is “supersonic subatomic java“. And “a Kubernetes Native Java stack tailored for OpenJDK HotSpot and GraalVM, crafted from the best of breed Java libraries and standards“. In my words: it allows for java applications to run inside a container and be fast. And also very handy: you can develop while it is running, seeing immediate effect of your changes.

Featrz

The Featrzz application is about showing Feature Files (Gherkin) in a browser. It starts with cloning a repository and converting the files with the .feature extension to JSON. These JSON blobs are then stored in a NoSQL database and used to display in the GUI.

There are 4 micro-services: a frontend, a server, a converter, and a data-store service. All are build with Quarkus and, except for the data-store, all are running in native-mode, i.e. they are not compiled to java byte-code to run on a JVM, but to an executable for a specific Operating System. That’s not a step back because we run it in a container of which we know the OS and the container itself will give us the portability as well. The containers are deployed in Google Cloud and when needed they will run using Cloud Run.

To illustrate how fast Quarkus is, the conversion happens in real-time. I wanted to store the results to make it even faster, but it turns out that retrieving the data from the database is hardly any faster than converting them again. At least not for the small projects that I used so far.

Support for libraries

The drawback of Quarkus may be that not all libraries are supported when compiling in Native mode. The Quarkus project is working hard on getting more support for libraries. E.g. instead of using Gson, I had to make my own package to convert my POJO’s to JSON. But I didn’t find it that troublesome either. It forced me to think very well about the design and as long as the POJO’s are simple, which they are, they are my POJO’s, the conversion is easy as well. If there is no other way, you can always run Quarkus in JVM-mode. As I did with the data-store service.

The use of containers also allows me to run the instances in a Kubernetes cluster as well. That makes the application very flexible in where and how to deploy it. Perhaps later I may release this tool or a variant for private Kubernetes clouds as well. Plus I can test the application locally.

Conclusion

If you’re like me and want to try-out something new in order to really find out if and how this technique works in a real project, I can definitely recommend to try out Quarkus as well. But also if you’re looking for ways to create micro-services in a public or private cloud, Quarkus may be an interesting way to go.