While many of the architectural challenges we have to deal with are big hard choices, there are also many smaller simpler ones.
From "don’t call repository classes from controllers" to "don’t have cyclic dependencies". In most projects I’ve worked on these are unwritten rules. But why not write them down in a way that we can also see if the rules get broken? Can we test these rules?
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 MicronautBeanProcessor class.
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.
First we need to add dependencies on Micronaut to our Spring application. In this example we will use the Micronaut HTTP client in our Spring application and use Gradle as build tool. We must add the following dependencies:
These days companies gather and manage vast amounts of user data. Loss of this data will expose companies to financial/legal liabilities or damages to their brand. This is because over the last years, governments have introduced new regulations like the General Data Protection Regulation (GDPR). Because of this, security is a major cross-cutting concern for application architecture. This two-part blog post explains how you can leverage Keycloak to secure your Spring microservices. The first blog will focus on how to install and configure Keycloak. The second blog will show how to use Keycloak to secure your Spring Boot microservices.
Keycloak is a modern open source Identity and Access Management solution. It enables us to secure all sorts of frontend applications (apps) / services and offers the following features:
Single Sign-On
Identity Brokering and Social Login
User Federation
Client Adapters
Standard Protocols
Admin Console
User Account Management Console
A corporate version, known as Red Hat Single Sign-On (SSO), is also available from (and supported by) Redhat. The support and the ability to connect to existing identity systems make it a good fit for large organisations.
The Thoughtworks Technology Radar is well known for showing technology trends and choices. For my project I wanted to have the same thing, not use the hosted public version from Thoughtworks, but a selfhosted option. Therefore I choose to base it on the Zalando opensource tech radar, and create a way to use a CSV file as input so updating would be an easy thing to do. To accomplish that I took the following steps:
Create a folder to put the tech radar into: ${project-folder}.
Start with the HTML5 Boilerplate index.html file and put it into the ${project-folder} file.
Insert the snippets as documented at Zalando Tech Radar, with one adjustment.
I don’t fill the entries array with entries, but will do that later on, from the input in the CSV file.
Note the names of the rings and quadrants, as they will be used in the next step, the CSV.
Create a CSV file (${project-folder}/data.csv) as input for the tech radar.
It has columns for the ring and quadrant where a technology should be put, and an indicator for movement.
The names of the rings and quadrant should equal those in the configuration copied from the Zalando example.
If you changed them, use those names instead.
The movement indicator is (up, none, down) and in the next step translated in to value understood by the radar.
The CSV will be translated into entries for the radar.
Add the following D3.js library to parse CSV:
This library provides functions to parse CSV file(s) into a map structure per row in the file.
Create a function to transform a row in the CSV into an entry for the tech radar:
This is the diversion from the steps in the Zalando tech radar description.
Wrap the radar_visualization() function a custom one, that takes an array of entry, to render the transformed rows, e.g. draw_radar(entries).
Finally glue everything together to fetch the CSV, parse and transform it, and draw the entries. The code below uses the functions I defined in the previous steps
When you have followed the above steps, the result should look like this:
There are those moments you wish you could just start up a real database or system for your (integration) test. In many tests I’ve written I used H2 or HSQLDB to have a data storage for my tests. It starts up quickly and almost supports everything you need to do your repository test or any other test needing data storage. But when your project progresses you start using other ways to store your data other than standard SQL or you use dialect specifics to create your database. This is the moment you discover H2 or HSQLDB is not supporting your database vendor specific features and you can’t get your test running. For example the support for PostgreSQL in H2 or HSQLDB isn’t great, using TIMESTAMP in a SQL script already makes H2 or HSQLDB break. Yes, there are workarounds, but you rather not apply them to keep your code clean and simple. This is the moment you wish it is cheap to start up a real database instance you can test against, so you’re sure your code works in your production environment. You could install the database software locally, make some scripts to initialise the database and clean up afterwards. Or you can make scripts to do this in a Docker container. But what if there’s something which makes this even cheaper to setup?
Well, there is something to help you: the TestContainers project. With TestContainers you can startup your favourite database from a Docker container. TestContainers made a wrapper around docker to have an easy setup for your tests. And even better, is doesn’t only work with your favourite database, it works with any docker container you need in your test. Okay, I have to admit, the startup time for your test is longer in comparison with H2 or HSQLDB, but on the other hand you get a fully functional database instance.
There are a few ways to get your application version with Spring Boot.
One approach is using Maven resource filtering to add the version number as an enviroment variable in the application.yml during the build.
Another approach is to use the Implementation-Version stored in the manifest file.
First of all, you need to enable resource filtering for your application.yml
Then you need to add a maven parameter to the application.yml. @ is used here instead of the standard ${} notation to prevent conflicts
And we can then retrieve it using @Value
The upside of this approach is that you always have a version number even when you start your application from your IDE, also by putting your variable in info.app.version, if you use Spring boot actuator, your version will be automatically available under the /info endpoint.
However, this approach does require quite a bit of configuration.
After the success of agile transformations that gave organisations the ability to respond to a change in the market more quickly and frequently, the last decade saw DevOps emerge as another magic wand. While valuable by itself, DevOps should actually be treated as one of many aspects of the Shift Left paradigm applied to the full software delivery life cycle. Patrick Debois, Andrew Shafer, John Allspaw and Paul Hammond coined the word DevOps around 2008. It comes down to the insight that combining the disciplines of development and IT operations by removing the thresholds between them allows for the elimination of waste and improvement of quality and speed of software delivery. The concept of Shift Left comes from the field of testing and boils down to the idea that the earlier in the software life cycle a fault is found, the cheaper it is to fix it. The accompanying model for this concept is that the process for delivering software goes from left to right as it goes from concept to cash.
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 ServiceStartedEvent.
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.
In our example application we have a reactive repository for a Mongo database and we want to save some data in the database when our Micronaut application starts.
First we write a bean that implements the ApplicationEventListener:
As a software engineer you make architectural decisions all the time. Neal Ford calls these software engineers 'accidental architects'. I personally prefer the term implicit architects because I don’t think software engineers doing architecture is in any way an accident or even something you would not want. You’re the expert after all. Decision making is one thing though, how do you document these decisions?
In my current project my function title is Software Architect. I have mixed feelings about this. While it definitely looks good on a resume I actually don’t feel software architect is a function title. Software architect is in my opinion a role, and one that can’t be handled by someone that doesn’t have his or her’s boots on the ground where the software development happens.
This is reflected in many teams where there is an 'architect' that, every now and then, comes down from his golden throne in his lofty ivory tower to enlighten the code monkeys software engineers with his architecture. After enlightening the engineers he again ascends the thousand stairs to his throne to work on his next perfect work.
Another word for this is a seagull architecture; architects that, like seagulls, fly down cover everything with shit and then fly off again. Leaving the software engineers wondering what they did wrong in a previous life to deserve all this. And if you’re lucky you don’t have a single seagull to deal with, but a whole team of them with conflicting ideas on the direction your teams should take.
Starting your next Javascript project can be frustrating or overwhelming when you have to set up your local development environment. The most of the new Javascript techniques and frameworks are dependent on node and NPM. Especially when you want to create a tutorial, blog post or prepare a workshop. The setup for each type of operating system can take to much time and your audience can lose the focus on the message you are trying to send. For this problem, CodeSandbox can help you out! On codesandbox.io you can start your next project with just one click and demonstrate, experiment or build cool stuff.
Although Java has always been awesome, Java 8 has brought the language several features the language was in dire need of. Apart from the long-awaited improved DateTime-API and the introduction of Optionals, Java 8 finally gave behaviour the attention it deserves by incorporating (a form of) functional programming into the language using lambdas.
The opportunities that Java 8 brought the language and the platform have long since been taken and functional styles of programming are part of our day-to-day routines as Java Developers. For-loops are a thing of the past for most of us, and although it had quite the learning curve, passing streams around and chaining operations on them to create some very readable code is common sense for us now.
