Often times API endpoint implementations involve retrieving data from some sort of storage. Retrieving data, even when applying a search criteria might result in hundreds, thousands or millions of records. Retrieving such amount of data could lead to performance issues, not meeting a contracted SLA, ultimately affecting the user experience.
One approach to overcome this problem is to implement pagination. You could retrieve a number of records from a data storage and add pagination links in the API response along with the page metadata back to the client application.
In a previous post, I showed readers how to include HAL hypermedia in Spring Boot RESTful applications using HATEOAS. Adding related links to REST responses help the client applications deciding what they might do next.
Some of the next actions a client application could help a customer do is to navigate through a list of resources. For instance to the first page of a result list.
HATEOAS, acronym for Hypermedia as the Engine of Application State, offers what your API consumers might do next when starting from a REST API entry point.
It includes hypermedia in the response, stateful links to related REST resources depending on business value or context. For instance, an upsell hypermedia link to upgrade to a Hotel suite instead of the room you might have in a shopping cart. A cancel hypermedia link to postpone a scheduled payment to a service provider.
This allows your API endpoints to reach the Level 3 of the famous Richardson Maturity Model. A more mature level than resources and verbs since it helps to provide API discoverability and self-documentation, to some degree.
This blog post covers the configuration and implementation details to include HAL representations in your API responses using Spring Boot 2.1.x.RELEASE and Spring HATEOAS 0.25.x.RELEASE.
Code coverage is a metric indicating which percentage of lines of code are executed when running automated tests. Unit and integration tests for instance.
It’s known that having automated tests as part of your build process improves the software quality and reduces the number of bugs.
Do you know if you need more unit tests? Or if your tests cover all possible branches of an if or switch statements? Or if your code coverage is decreasing over time? Especially after you join a team to work on an on-going project.
Code coverage helps to answer these questions. This post covers reporting code coverage using Maven’s jacoco-maven-plugin, a library that adds minimal overhead with normal build.
Generally, when you write Java unit tests, you stub data or mock the target class dependencies. This allows you to verify the business logic in an environment where you don’t depend on third party services.
Integration tests also play an important role in the Continuous Integration / Delivery (CI/CD) process to release software frequent and safe. As I have mentioned before, integration testing goal is to verify that interaction between different parts of the system work well. Examples of such interactions are:
- Connecting to a RDBMS to retrieve or persist data
- Consuming a message from a broker
- Sending an email
- Processing an upstream response
In large Enterprise applications development, with hundreds of unit and integration tests, the test suites take a considerable amount of time to complete, normally hours.
Wouldn’t it make sense to split the tests by their purpose and execution speed? It would be beneficial for an organization to get a quicker feedback when tests fail.
It would then be advisable to implement a fail-fast approach and break the build process when unit tests fail. This post covers configuring Maven’s maven-surefire-plugin to split running unit and integration tests.
Now that you are able to build Docker images without needing a Docker daemon using Jib, your organization most-likely would like to keep those images from being pulled down publicly. In this case it makes sense to store them in a private Docker registry.
Amazon Elastic Container Registry (ECR) is a cheap option to store both, public and private Docker images. It even makes more sense to use AWS ECR if your organization is already invested in other AWS services such as IAM and ECS.
This tutorial covers installing the required software, setting up the AWS infrastructure and configuring settings to push a Docker image to a private Amazon ECR repository.
Ever since I published Microservices using Spring Boot, Jersey, Swagger and Docker, I had entertained the idea of making Package the service into a Docker image section its own blog post.
Back then I used Spotify’s docker-maven-plugin, which required connecting to a Docker host. Also felt it would have been almost identical to the section mentioned.
It was nice to learn Google released an open source tool named Jib aimed at easing containerizing Java applications. No need for a
Dockerfile, no need for a Docker daemon, and actually no need for container expertise.
Although you could use Jib to build to a Docker daemon, this post focuses on building a Docker image for Spring Boot applications without requiring a Docker host.
Let’s say your organization is splitting the big monolithic application in multiple, smaller and more specialized microservices. Some of them will interact with a relational database and a message broker while others will communicate with a NoSQL database for instance.
This is a great opportunity to standardize the new deliverables in your company. You might want to develop some custom Spring Boot starters responsable for providing common Java application components, logging, tracing, metrics, monitoring, resilience, RDBMS and APIs implementation support, helping with the application bootstrapping process and reducing common boilerplate code in each Spring Boot-based service.
Once you are using these Spring Boot starters in an application, how would you use them in a new service? Copy and paste and change the artifact ID? Removing unused dependencies? Clean up properties files and Java classes? Although this process works, it involves manual labor which is always tedious and error-prone.
In this guide I describe how to implement and use a custom Maven archetype, which uses a custom Spring Boot starter, integrated in a multi-module Maven setup to automate new projects generation.
1. USING AN AWS S3 BUCKET AS YOUR MAVEN REPOSITORY
An Amazon Web Services S3 bucket is an inexpensive option to store your Maven or other binary artifacts. It’s an alternative to feature-rich Maven repository managers like Nexus and Artifactory when you don’t have the resources to install and maintain a server with the required software or the budget to subscribe to a hosted plan.
One choice I wouldn’t recommend is to store the binary artifacts in the SCM.
This “how to” post covers configuring Maven and setting up an AWS S3 bucket to store deployed Java artifacts.
1. ADDING FEATURE TOGGLES TO SPRING BOOT APPLICATIONS USING TOGGLZ
Features toggles help developers to make smaller, faster and less risky changes to software. Let’s say a requirement that will take a significant amount of effort to complete is going to be implemented. Two popular approaches are:
Branch the source code and develop for the next quarter or so. Once the implementation is completed you might likely face problems merging back this long-lived branch. You might end up asking your peers to stop committing changes or the SCM might get locked for the next 2-3 weeks until all the conflicts are resolved. Possibly delaying bug fixes and new features from being released to clients.
Implement the requirement in trunk / main / master branch, hiding incomplete functionality behind a development or release toogle. This allows the development team to work in the same code base, avoids the complexity of maintaining multiple branches, reduces the release cycle while getting a timely feedback when paired with a CI / CD pipeline.
This tutorial introduces implementing feature flags in Spring Boot applications using Togglz and togglz-spring-boot-starter Spring Boot starter. How to configure and use them, some tradeoffs and a word of caution.
1. IMPLEMENTING AND CONFIGURING SERVLETS, FILTERS AND LISTENERS IN SPRING BOOT APPLICATIONS
Let’s say you find yourself modernizing a legacy Java web application, not just the UI libraries but also the middleware. And let’s say that Spring Boot was the selected framework to get the job done because of its many advantages:
- Allows teams getting started quickly reducing boilerplate code.
- Provides starter projects which extremely reduces Maven configuration, especially dependencies management.
- Production ready actuator endpoints reporting metrics, health check.
- Provides opiniated autoconfiguration out of the box flexible enough to be overriden when needed.
- Seamless integration with the Spring ecosystem.
How can a Filter, a Servlet and a Listener be added to a Spring Boot application now that it lacks the
web.xml file descriptor? This post answers this question also covering injecting dependencies to a Filter, Servlet or Listener.