Posts

Showing posts with the label Spring Boot

Spring Cloud Contract

Image
Spring Cloud Contract  is a project that, simply put, helps us write Consumer-Driven Contracts (CDC). This ensures the contract between a Producer and a Consumer, in a distributed system – for both HTTP-based and message-based interactions. Producer – Server Side For our producer side, we'll need the spring-cloud-starter-contract-verifier dependency. Producer Side Setup Test stubs are in /src/test/resources/contracts/ package. When the build is run, the plugin automatically generates a test class named ContractVerifierTest that extends our BaseTestClass and puts it in /target/generated-test-sources/contracts/. The names of the test methods are derived from the prefix “validate_” concatenated with the names of our Groovy test stubs. For the above Groovy file, the generated method name will be “validate_find_provider_by_id()”. Consumer – Client Side The consumer side of our CDC consume stubs generated by the producer side through HTTP interaction to maintain the contract...

Java Bean IBAN Validation - Creating custom constraint annotation

Image
  Although Bean Validation has plenty of handy built-in constraints, such as to make sure if a field is following a specific regex or even if a date is in the past or future, it is certain that soon or later you will need a specific constraint that is not covered by the standard annotations.  Definition of ConstraintValidator Definition of Constraint Custom constraints are at the heart of JSR 303 Bean Validation flexibility.

Triggering Bean Validation programmatically

Image
Validation in Spring Boot applications can be done in many different ways. Why validation? Validating incoming request data is good to reject nonsense as early as possible. Persistence layer validation should only be used as additional layer of safety. I prefere validation programmatically even if triggering Bean Validation programmatically takes a bit more effort. I think it is usually the most flexible way. Validation is done by using the Bean Validation API. The reference implementation for the Bean Validation API is Hibernate Validator. Triggering Bean Validation programmatically Validating extends SelfValidating class

Monitoring Spring Boot Application with Prometheus and Grafana

Image
 Every application that is deployed on production needs some kind of monitoring to see how the application is performing. This will give you some insights on whether the application is performing as aspected or if you would need to take some action in order to obtain the desired level of performance. In the modern world, this data is called Application Performance Metrics (APM).   Let’s try to set up a basic Springboot App monitoring with a Grafana Dashboard and Prometheus.

Custom Spring Initializer

Image
Typically, REST developers use Spring Initializr to create the initial setup.  This comes as a web based UI mainly which provides the ability to create a new Spring Boot project using dependencies available and download the project created as a zip. So we don’t have to create it from scratch. All the basic structure of the project is already there in this downloaded zip. Spring Initializer comes as IDE plugins.  Why do we need to create our own Spring Boot Server? In order for a large team to work on microservices architecture, it must constantly build Spring Boot projects / libraries. Having a custom spring initiator enables developers to generate projects / libraries where they don't have to worry about package name, project name conventions, etc. You can configure the dependency list to suit your needs by overriding or using the default dependency list. The project version, build tool type, Java version, project descriptions etc are definable, so there is no problem rememb...

Logging Request and Response Body In Spring Boot

Image
  I recently read a Gain Java Knowledge article about logging Spring Boot Request and Response. I really like the idea so I decided to test it in practice. How to logging Spring Boot Request and Response? Request and response body for each endpoint we can print using Servlet Filter. Inside our controller class we will not log any statement but our filter class will log the request and response body for each API call. So this approach will reduce the lines of code and we don’t need to worry about to add log statements in each API to print Request and response body. The Filter class will be used to log requests and responses for each API. LoggingFilter class will extends OncePerRequestFilter class because this is Filter base class that aims to guarantee a single execution per request dispatch, on any servlet container. It provides a doFilterInternal method with HttpServletRequest and HttpServletResponse arguments. Conclusion: In my opinion, this is the best solution to log request...

CRUD Goes Even Easier With JPABuddy

Image
Create, Read, Update and Delete are the four basic operations of persistence storage. We can say these operations collectively as an acronym CRUD. These operations can be implemented in JPA. JPA is a standard for ORM. It is an API layer that maps Java objects to the database tables.  ORM stands for Object Relational Mapping. It converts data between incompatible type systems in object-oriented programming languages.  JPA Buddy is an IntelliJ IDEA plugin that helps developers work efficiently. JPA Buddy is a tool that is supposed to become your faithful coding assistant for projects with JPA and everything related. It is an advanced plugin for IntelliJ IDEA intended to simplify and accelerate everything related to JPA and surrounding mainstream technology. In fact, you can develop an entire CRUD application or a simple microservice by spending nearly zero time writing boilerplate code. The video demonstrates the features of JPA Buddy by creating a simple CRUD application from ...

Creating Efficient Docker Images with Spring Boot 2.3

Image
Spring Boot 2.3 brings with it some interesting new features that can help you package up your Spring Boot application into Docker images. The first problem with common docker techniques is that the jar file is not unpacked. There’s always a certain amount of overhead when running a fat jar, and in a containerized environment this can be noticeable. It’s generally best to unpack your jar and run in an exploded form. The second issue with the file is that it isn’t very efficient if you frequently update your application. Docker images are built in layers, and in this case your application and all its dependencies are put into a single layer. Since you probably recompile your code more often than you upgrade the version of Spring Boot you use, it’s often better to separate things a bit more. If you put jar files in the layer before your application classes, Docker often only needs to change the very bottom layer and can pick others up from its cache. Two new features are introduced in Sp...