This post was originally published on the Platform.sh blog and reflects information from the time of publication.
Microservices are a hot topic in software design, and for good reason. They have plenty of advantages when it comes to handling infrastructure complexity, many of which were addressed in part one of our related Java post. Now, it’s time to talk about the code and design. In this post, we’ll take a deep dive into each module.
When creating an application, clean code means thinking about design and architecture. Architecture is the software process that handles flexibility, scalability, usability, security, and other points, so you have more time to focus on business rather than on technology. Some architecture examples include:
- Serverless architecture. Application designs that incorporate third-party, Backend-as-a-Service (BaaS) services, and include custom code run in managed, ephemeral containers on a Functions-as-a-Service (FaaS) platform.
- Event-driven architecture. A software architecture pattern promoting the production, detection, consumption of, and reaction to events.
- Microservices architecture. A variant of the service-oriented architecture (SOA) style that structures an application as a collection of loosely coupled services. In a microservices architecture, services are fine grained and the protocols lightweight.
The design has a low-level duty that supervises the code, such as what each module is going to do, the class’s scope, the functions proposal, and so on.
- SOLID. The five design principles that make software designs more understandable, flexible, and maintainable.
- Design patterns. The ideal solutions to common problems in software design. Each pattern is like a blueprint you can customize to solve a particular design problem in your code.
Speaker service
The first service that we’ll cover is the Speaker service, which uses Thorntail and PostgreSQL. The Eclipse MicroProfile doesn’t have support for a relational database. However, we can use the specification from its older and more mature brother, Jakarta EE. As a first step, let’s define the Speaker entity.
Revisit our previous article that covers the JPA integration, using Transactional annotation and a CDI Interceptor to manage the transaction.
We have a resource to expose the services through an HTTP request. We’ve created a layer on DTO to avoid losing the encapsulation.
In the .platform.app.yaml file, we need to check that the speaker application has access to the PostgreSQL instance and anything else about the database that lets Platform.sh handle it.
Session service
The Session service will handle the contents of the conference, so that a user can find sessions related to topics like cloud and Java. This service uses Elasticsearch with Jakarta NoSQL and KumuluzEE.
We’re applying a distinct aspect of Elasticsearch to use it as a search engine. Jakarta NoSQL looks to the specialization that allows particular features for each NoSQL database. Therefore, we’ll have a mix of repository and ElasticsearchTemplate, a specialty of DocumentTemplate.
Conference service
The Conference service is the most connected of the services because it needs to keep information from both speaker and session services. It uses Payara Micro and MongoDB with Jakarta NoSQL.
One of the benefits of MongoDB is that we can use the subdocument instead of creating a relationship. Therefore, we can embed Speaker and Session instead of doing joins. Note, the Speaker and Session entities have brief information such as name and ID.
Client service
The client will show the RESTful application using HTML 5 with Eclipse Krazo. Yes, Eclipse Krazo has several engine extensions to use more than JSP, such as HTML 5. The extension we’ll use is Thymeleaf with Apache TomEE.
The first step in the client is to create the bridge to request information from the services. Thankfully, we have an Eclipse MicroProfile Rest Client to deal just with interfaces and nothing more.
To make sure that the services are up, we conduct an Eclipse Microprofile Health check, so we can evaluate the HTTP status and the response time in milliseconds.
We can access the status at https://server_ip/health.
Once Services and health check are ready, let’s go to the controllers. Eclipse Krazo is an API built on JAX-RS. Therefore, any Jakarta EE developer will feel at home when creating a Controller class.
The HTML5 resource and replacement are on Thymeleaf. We wrote about it in a previous post, Thymeleaf puts the Java instance information on the HTML5 template dynamically.
Finally, the code
In this post, we finally saw some code and design, which is always exciting! Eclipse MicroProfile has a bright future integrated with Jakarta EE to allow Java developers to create several applications styles—like microservices and monoliths—that use either JPA or NoSQL. Besides that, these projects offer scalability and straightforward Java applications for your business. Platform.sh delivers on the promise of a NoOps pipeline for your Java microservices.