I really like maven for the structured way it provides for defining and building a project. But sometimes I wish for a less verbose notation than the XML of the Project Object Model (POM). For example, gradles dependency notation is far shorter than mavens dependency declaration. Looking for a less verbose way to declare a maven POM, I discovered polyglot maven. It are maven extensions that allow the maven POM to eb written in another dialect than XML. Since you see YAML more and more I decided to try that dialect, and see if my maven descriptor would be clearer.
In my early days I spent most of my time fixing bugs on a huge enterprise application, so by now I learned from experience that a lot of bugs could have been easily prevented. This is why I prefer a Functional Programming style, I love how FP handles state. As a software consultant I get to switch companies and teams quite regularly and most projects I have been working on use java 7 or 8. This almost always leads to a few dicussions regarding programming style. So today I would like to talk about good FP principles, and how Java makes them hard (and why languages like Kotlin are awesome).
Infrastructure automation basically is the process of scripting environments — from installing an OS to installing and configuring servers on instances. It also includes configuring how the instances and software communicate with one another, and much more. Automation allows you to redeploy your infrastructure or rebuild it from scratch, because you have a repeatable documented process. It also allows you to scale the same configuration to a single node or to thousands of nodes. In the past years, several open source and commercial tools have emerged to support infrastructure automation. These tools include Ansible, Chef, Terraform and Puppet. They support cloud platforms, but also virtual and physical environments. On Google Cloud Platform you have the possibility to use Cloud Deployment Manager. The Cloud Deployment Manager allows you to automate the configuration and deployment of your Google Cloud with parallel, repeatable deployments and template-driven configurations.
Normally we would consume server-sent events (SSE) in a web browser, but we can also consume them in our code on the server. Micronaut has a low-level HTTP client with a
SseClient interface that we can use to get server-sent events. The interface has an
eventStream method with different arguments that return a
Publisher type of the Reactive Streams API. We can use the
RxSseClient interface to get back RxJava2
Flowable return type instead of
Publisher type. We can also use Micronaut’s declarative HTTP client, which we define using the
@Client annotation, that supports server-sent events with the correct annotation attributes.
In the first part we setup a local Keycloak instance. In this blog we will see how we can leverage Keycloak to secure our frontend. For this purpose we will create a small Spring Boot application that will serve a webpage. The next and last blog will show how authentication can be used between services.
gRPC is a high-performance RPC framework created by Google. It runs on top of HTTP2 and defaults to the protocol buffers instead of JSON on the wire. As probably most developers, I’ve also been creating microservices for the past several years. These services usually communicate over HTTP with a JSON payload. In this post I want to present gRPC as an alternative to REST when most of your API’s look like remote procedure calls. In my time using REST API’s I have encountered many discussions about status codes (which do not map very well onto your application errors), API versioning, PUT vs PATCH, how to deal with optional fields, when to include things as query parameters etc. This can lead to inconsistent API’s and requires clear documentation.
We can add Micronaut beans to the application context of a Spring application.
Micronaut has a
MicronautBeanProcessor class that we need to register as Spring bean in the Spring application context.
We can define which Micronaut bean types need to be added to the Spring application context via the constructor of the
This way we can use Micronaut from inside a Spring application.
For example we can use the declarative HTTP client of Micronaut in our Spring applications.
When our Micronaut application starts we can listen for the
ServiceStartedEvent event and write code that needs to run when the event is fired.
We can write a bean that implements the
ApplicationEventListener interface with the type
Or we can use the
@EventListener annotation on our method with code we want to run on startup.
If the execution of the code can take a while we can also add the
@Async annotation to the method, so Micronaut can execute the code on a separate thread.
Jib is an open-source Java library from Google for creating Docker images for Java applications. Jib can be used as Maven or Gradle plugin in our Spring Boot project. One of the nice feature of Jib is that it adds layers with our classes, resources and dependency libraries for the Docker image. This means that when only class files have changed, the classes layer is rebuild, but the others remain the same. Therefore the creation of a Docker image with our Spring Boot application is also very fast (after the first creation). Also the Maven and Gradle plugins have sensible defaults, like using the project name and version as image name, so we don’t have to configure anything in our build tool. Although Jib provides options to configure other values for the defaults, for example to change the JVM options passed on to the application.
When we use the Micronaut command line commands to generate controllers, beans and more, the classes will have a default package name.
We can use a fully qualified package name for the class we want to generate, but when we only define a class name, Micronaut will use a default package name automatically.
We can set the default package for an application when we first create an application with the
But we can also alter the default package name for an existing Micronaut application.
In a previous post we learned how to add build information to the
/info endpoint in our application.
We can add custom information to the
/info endpoint via our application configuration or via a bean by implementing the
Remember we need to add the
io.micronaut:management dependency to our application for this feature.