In this article, we discuss the existing standards for databases in the Java world and the new Jakarta Data proposal, which aims to make life easier for developers.

Dealing with a database is one of the biggest challenges within a software architecture. In addition to choosing one of several options on the market, it is necessary to consider the persistence integrations. The purpose of this article is to show some of these patterns and learn about a new specification proposal, Jakarta Data, which aims to make life easier for developers with Java.

Understanding the Layers That Can Make Up Software

Whenever we talk about complexity in a corporate system, we focus on the ancient Roman military strategy: divide and conquer or divide et impera. To simplify the whole, we break it down into small units.

In the software world, one of the ways to simplify and break down complexity is through layers, whether physical or logical. These layers, mainly the logic ones, can be fragmented, becoming components and functionalities.

This breaking layer movement is one of the themes in the book “Clean Architecture” when mentioning, for example, the strategy of separating the business code from the infrastructure code.

The Three Types of Layers in an Application

According to the “Learning Domain-Driven Design” book, regardless of the architectural style that you are working with, such as monolith or microservices, there is a minimum number of three types of layers in an application. They are the:

1. Presentation layer: It is the layer of interaction with the user consuming this resource, whether an end-user or someone who works in software engineering.
2. Business logic layer: As its name suggests, this is where the business logic will be, or in the words of Eric Evans, “it is the layer that finds the heart of the business.”
3. Data access layer: This layer holds the entire persistence mechanism. In the context of Stateless architecture, we can think that it is the place with some state guarantee, noting that the storage mechanism is transparent, be it a NoSQL database, SQL, a Rest API, etc.

These three types of layers tend to be present in various software architecture styles, from simple ones, such as MVC, to more complex ones, such as CQRS, hexagonal model, onion, among others.

In addition to the three types of layers, the architectural models are very concerned with the communication between these components to ensure high cohesion and low coupling, and they follow the Dependency Inversion Principle, the DIP.

This isolation of the data access layer mainly ensures that the database paradigm “leaks” into the business model. We know a big difference — also known as impedance — especially between relational databases and object-oriented programming.

Persistence Layer

After the proper introduction about layers and their importance, we will focus on the persistence layer or database. A point of criticism and admiration within the object-oriented paradigm is a wide range of options and standards for communication.

For this article, we will talk about some patterns taking into account the single responsibility principle and the coupling with the business and database layer.

It is worth noting that there is no “silver bullet” solution, so it is essential to pay attention to which context this pattern will be used.

Pattern Types When It Comes to Database

Of course, we have several integration models and patterns between the database and OOP. This article focuses on the following:

• Pattern 1: Data-oriented programming
• Pattern 2: Active record
• Pattern 3: Mapper

Next, let’s look at these patterns in detail.

Pattern 1: Data-Oriented Programming

In his book “Data-Oriented Programming”, author Yehonathan Sharvit proposes reducing complexity by promoting and treating data as a “first-class citizen.”

This pattern summarizes three principles:

1. The code is data separated.
2. Data is immutable.
3. Data has flexible access.

This proposal eliminates the entity layer, focusing explicitly on data dictionaries through, for example, an implementation of Map.

Pattern 2: Active Record

After Martin Follower’s book “Patterns of Enterprise Application Architecture,” this pattern became quite popular.

In short, the pattern has a single object, which is responsible for both the data and the behavior. It allows simplifying business rules since the idea is that there is direct access to data.

However, in the case of more complex architectures, active record tends to become quite challenging to deal with. We add a high coupling between the database solution, not to mention the break of single responsibility. In addition to being responsible for business rules, the same class is also responsible for database operations.

The most recent and widely used solution is Quarkus’s Panache within the Java world. This way, it is possible to make an application with microservices with only two classes.

Pattern 3: Mapper

Another database communication solution that meets the previous premise is mapper. Generally speaking, it leaves entity and database operations separate. What, at most, tends to appear within classes is the metadata or annotations of the Java world.

This standard ensures greater separation between the business layer and the database, and it guarantees the single-responsibility principle. We simplify maintenance and reading in applications, as we have a class for the entity and another for database operations.

However, for simple projects, Mapper tends to be unfeasible. It is the case, for example, of straightforward applications with CRUD that, depending on the style, will need three or four classes to achieve the same objective, unlike standards such as active record, which would perform this function with half the number of objects.

The most common example, of course, is the ORM Hibernate. However, this type of solution is not exclusive to relational databases, as there are solutions for NoSQL such as Spring Data and Jakarta NoSQL.

DAO vs. Repository

From a mapper, it is possible to think of two more patterns. They are:

1. DAO (Data Access Object)
2. Repository

These patterns consider the decoupling between the model and the persistence layer, but the similarity ends there.

The differences are in the coupling as it is linked to the data access layer, and not to the model, in addition to the focus on the service layers, semantics, and nomenclature. Let’s better understand these models separately.

Data Access Object (DAO)

The data access object (DAO) standard isolates the application and business layers from persistence through an abstraction API. This API, in turn, bears a close resemblance to the database engine.

Repository

The repository pattern is a mechanism that allows you to encapsulate storage, retrieval, and search behavior by emulating a collection of objects. In this way, the design further hides the relationship of the persistence mechanism.

This pattern focuses on the closest proximity of entities and hides where the data comes from, making it possible for a Repository to use a DAO pattern itself.

Summarizing DAO x Repository

The important point is the semantics. Let’s take an example: consider that a Car entity would have Garage as a class, representing the collection of entities. The result would be the following code snippet:

In short, if we compare the two types of pattern inside mapper:

• DAO focuses on an abstraction for accessing some kind of data.
• The repository focuses on a collection, regardless of the object’s origin. For this reason, a repository can use a DAO to achieve its goal.

A New API Proposal for Data Access Is Born: Jakarta Data

After knowing all the patterns, and their respective importance and trade-offs, it is essential to take one more step: to see an API that better explores these patterns and, thus, facilitates the adoption of good practices with Java and data resources.

The proposal for a new specification called Jakarta Data is born. Jakarta Data is premised on three principles:

1. An easy and declarative API
2. A cohesion in this layer
3. A decoupling of the other layers

Still, in its first version, the focus of this new proposal is on delivering the repository pattern so that, with just one interface and a few annotations, it is possible to implement Jakarta Data, initially, in three projects:

Relational with JPA, NoSQL with Jakarta NoSQL, and REST with REST Client for MicroProfile.

In summary, from Jakarta Data, it is easier to deal with the business layer both in terms of polyglot persistence and its decoupling.

Jakarta Data: More Ease and Integration

Overall, we always take into account the degree of insulation of the other layers and their ease of use and maintenance. From this scenario, Jakarta Data was born, whose objective is to help use these patterns in a simple and integrated way to the world of Java specification. And, by default, the expectation is full support from the community and providing help and feedback.

If you enjoy working at a large scale in projects with global impact and if you like a real challenge, feel free to reach out to us at xgeeks! We are growing our team, and you might be the next one to join this group of talented people 😉

Check out our social media channels if you want to get a sneak peek of life at xgeeks! See you soon!

Learn to Access Java Database With Jakarta Data was originally published in xgeeks on Medium, where people are continuing the conversation by highlighting and responding to this story.

Learn more about dependency injection with Jakarta CDI and enhance the effectiveness and readability of your code.

Within programming, object orientation (also known as OOP) is one of the wealthiest paradigms in documentation and standards, as with dependency injection. However, the most common is that these standards are misinterpreted and implemented and what would allow a clear vision and a good design for a cooperative application, in practice, harms the quality and efficiency of your code.

In this article, I will bring the advantages of exploring object orientation, more specifically dependency injection, together with the specification of the Java world that covers this API: the Jakarta CDI.

What Is Dependency Injection?

The first step is to contextualize what dependency injection is and why it differs from inversion of controls, although the two concepts are very confused.

In the context of OOP (Object Orientation), dependency is related to any direct subordination of a class, and that can be done in several ways. For example, through constructors, accessor methods, such as setters, or creation methods, such as the Factory Method.

This example injection also can measure how much one class is linked to another, which we call coupling. It is vital because it is part of the job of good code design to be concerned with high cohesion and low coupling.

The Difference Between Dependency Injection and Inversion

Once the basic concepts of OOP are explained, the next step is to understand what differs between injection and dependency inversion.

This distinction happens because of what we call the DIP, or Dependency Inversion Principle, which works as a guide to good practices focused on decoupling a class from concrete dependencies through two recommendations:

1. High-level modules must not depend on low-level modules, but both must depend on abstractions (Example: interfaces).
2. Abstractions, in turn, should not depend on details. However, parties or concrete implementations must depend on abstractions.

While inversion assumes all these requirements, dependency injection is a DIP technique to supply a class’s dependencies, usually through a constructor, attribute, or a method such as a setter.

In short: dependency injection is part of the best practices advocated by inversion of control (IoC).

As tricky as these concepts are, at first, they are fundamental because they can be correlated to the Barbara Liskov principle. After all, both the Liskov principle and dependency injection are part of SOLID.

Where Does CDI Come in, and How Do We Get to Jakarta CDI?

As with injection and inversion, it is crucial to take a step back and contextualize what CDI is.

The CDI (Dependency and Contexts Injection) arose from the need to create a specification within the JCP, JSR 365, mainly because, in the Java world and projects like Spring and Google Guice, there are several solutions and implementations of these frameworks.

Briefly, the purpose of Jakarta CDI is to allow the management of stateful or stateless component life control via context and component injection.

It is a project in constant evolution. If you want to keep up with the latest updates, it’s worth knowing Eclipse Open-DI. It is currently being optimized to improve booting through CDI Lite.

CDI in Practice

To exemplify the features of CDI, we will create a simple Java SE application with CDI to show six essential elements within CDI, which are:

1. Perform a single injection.
2. Differentiate implementations through qualifications.
3. Teach CDI to create and distribute objects.
4. Apply Observer.
5. Apply Decorator.
6. Use the interceptor.

In this article, even to avoid making the text too big, we will highlight the codes. If you want, you can later access the code in full.

It is nice to mention that this content was created with Karina Varela and is part of the classes we took throughout 2021, mainly in American and European countries, in partnership with Microstream and Payara.

Perform a Single Injection

In our first implementation, we will create a “Vehicle” interface and an implementation using the Java SE container.

An important point: we have the context in addition to the injection of dependencies. We can define the life cycle of a class or bean, and, in this case, the implementation will have the application scope.

In this piece of code, we have the interface Vehicle and its respective implementation, Car, in which the CDI will be able to inject an instance both through the interface and through the implementation.

Since we are talking about best practices, please understand that we are using the case of a single interface for a single implementation for teaching purposes. In practice, ideally, you don’t do this so as not to break the KISS principle.

A good indicator for this is interfaces that start with “I” or implementations that end with “Impl”. In addition to being an indicator of unnecessary complexity, it is a code smell. After all, it is not a meaningful name, breaking the principle of the Clean Code.

Differentiate Implementations Through Qualifications

In the previous example, we had the case of a one-to-one relationship, that is, an interface for a single implementation. But what happens when we have multiple implementations for the same interface?

If we don’t have this set, CDI won’t know the default implementation and will throw the AmbiguousResolutionException. You can solve this problem using the Named annotation or a Qualifier. In our case, we will use the Qualifiers.

Imagine the following scenario in which we have an orchestra with several musical instruments. This orchestra will need to play all the instruments together and be able to discriminate between them. In our example, this scenario would look something like the following code:

We have the instrument interface, an enumerator to define its type, and the CDI Qualifier through a new annotation in this code example.

After the implementations and qualifiers, it will be pretty simple for the orchestra to play all the instruments together and special tools considering their different types, for example, string, percussion, or wood.

The CDI container injects an Orchestra instance and demonstrates the use of each instrument.

Teach CDI to Create and Distribute Objects

In addition to defining its scope, it is often impossible to perform activities such as determining or creating a class within the CDI container. This type of resource is essential for cases such as, for example, when we want to inject a connection to some service.

It is possible to teach the container to create instances and destroy them within CDI through the Produces and Disposes annotations, respectively. For this example, we will create a connection that will be created and closed.

Right now, we have a connection from which we teach how the CDI should create and close the connection.

Apply Observer

We cannot forget the Observer among the patterns very present in corporate architectures and present in the GoF.

One of the assessments I make of this pattern is that, given its importance, we can see it similarly in architectural practices, such as Event-Driven, and even in a paradigm with reactive programming.

In CDI, we can handle events synchronously and asynchronously. Imagine, for example, that we have a journalist, and he will need to notify all the necessary media. If we do the coupling of these media directly in the “Journalist” class, every time a media is added or removed, it will be necessary to modify it. It breaks the open-closed principle to solve; we will use Observer.

So we created a Journalist class that notifies the media, a novelty thanks to the Observer pattern with the CDI. The event is triggered by the Event instance, and to listen for it; it is necessary to use the @Observers annotation with the specific parameter to be listened to.

Apply Decorator

The Decorator pattern allows us to add behavior inside the object, obeying the principle of composition over inheritance. We see this within the Java world with wrappers of primitive types like Integer, Double, Long, etc.

We created a worker abstraction, the Programmer, and the Manager responsible for delegating the worker. In this way, we could add a behavior, such as sending an email, without modifying the programmer.

The Interceptor

The CDI can also perform and control some operations in the code in a transversal way, similar to what we do with aspect-oriented programming and cutpoints with Spring.

The CDI interceptor tends to be quite helpful when we want, for example, a logging mechanism, transaction control, or a timer for a method that will be executed, among others. In this case, the sample used will be a timer with an interceptor.

The interceptor implementation will allow the creation of the annotation that will be used to indicate the intercept, and the class, in turn, will define how this intercept will be implemented, which, in our case, will be a counter.

The following and last example is to create two methods that we will count, with two implementations, one of which will have a delay of two seconds.

Dependency Injection With Jakarta CDI: More Options for Your Development

Given these practical examples, we can see the various possibilities and challenges possible when working with Object Orientation and better understand some of its principles around dependency injection and CDI.

It’s important to remember that, as Uncle Ben once said, “with great power comes great responsibility.” As such, common sense remains the best compass for exploring these and other CDI features, resulting in a high-quality design and clarity.

References

• Dependency Injection or Inversion?
• Difference between dependency injection and dependency inversion
• Dependency Injection Is NOT The Same As The Dependency Inversion Principle

If you enjoy working on large-scale projects with global impact and if you like a real challenge, feel free to reach out to us at xgeeks! We are growing our team and you might be the next one to join this group of talented people 😉

Check out our social media channels if you want to get a sneak peek of life at xgeeks! See you soon!

Making Readable Code With Dependency Injection and Jakarta CDI was originally published in xgeeks on Medium, where people are continuing the conversation by highlighting and responding to this story.

Understand the impacts of a security issue on your application and how to avoid being responsible for your company’s next security issue.

In recent times, we have witnessed several information security breaches worldwide: vulnerabilities, ransomware, Man-in-the-middle, among other problems that become headaches not only for the engineering team but for the whole company and even for customers of your product.

What if we say that most security problems could be avoided? This article will cover the importance of information security and how to include it throughout the development process: the so-called DevSecOps.

The 3 Myths Around Security Information

There are three taboos in the area of software development that we need to talk about to start addressing information security more consistently:

1. Security breaches are often seen as an issue only for large companies.

The first of them is the simplest to say: most security flaws and their respective impacts and damages are commonly related to large companies, such as Facebook, LinkedIn, among others.

However, this is not a problem unique to large companies, so much so that a study by codegrip reports that three out of four applications currently in use have some vulnerability.

2. Vulnerability does not harm businesses.

According to IBM’s latest vulnerability research report, this idea is far from true. To give you an idea, about 38% of business was lost by companies that had a security breach. In addition, there are some average loss estimates:

• Average of 180 USD for each record of personal information.
• 4.62 million dollars was the average ransomware breach.
• $3.61 million for every breach of hybrid cloud environments.

In practice, vulnerability also impacts brand trust and credibility. A recent example was Target, which had to shell out nearly $200 million to repair its credibility.

3. Security problems come from big mistakes.

Of all the myths, this is the biggest fallacy of all! In general, the “minor problems” are precisely those that result in the most extensive security disasters, and we can say that failures usually present two gaps:

1. We encountered flaws such as insecure code design, injection, and configuration issues through a code vulnerability intentionally or unintentionally: within the TOP 10 demonstrated by OWASP.
2. Through the vulnerability of operations: among the most common problems, we can mention the choice for “weak passwords”, default or even the lack of password. A second common failure is the mismanagement of people’s permission to a document or system. These types of problems, unfortunately, are pretty standard. Not by chance, 75% of Redis servers have issues of this type.

In an analogy, we can say that security flaws are like the case of the Titanic. Considered one of the biggest wrecks, most people are unaware that the ship had a “small problem”: the lack of a simple key that could have opened the compartment with binoculars and other devices to help the crew visualize the iceberg in time and prevent a collision.

Knowing the security triad

We understand the importance of information security and the tremendous impact of its absence. With that, the question remains: how to define if an application is safe?

In short, there is an acronym for a secure application based on ISO 27002, which is CIA, focused on three properties:

• Confidentiality: The guarantee that a message will be delivered to the person who needs to receive that information.
• Integrity: Ensuring that information is delivered unchanged along the way.
• Availability: The guarantee that data must always be available to the legitimate user.

To illustrate, an analogy. If the Titanic was a “failed application”, what happened was a problem in property A (Availability), since the key that guaranteed access to the binoculars was not available to the team ahead of the vessel.

Understanding information security as a methodology: DevSecOps

Once we understand the security principles, we need to understand the “how” to incorporate them into the routine of our applications. After all, how are we going to ensure that each delivery/deployment has no vulnerability issues?

One of the solutions is to increase the integration between teams, avoiding feedback delays and, mainly, making information security happen in a proactive and non-reactive way, as it usually happens.

The answer to this is DevSecOps, which focuses on adding a layer of security to the development operation. Thinking about this methodology is another step in the history of integration between teams.

• Agile: The cone that comes from the agile manifesto of 2001, this methodology focuses on integrating the development team and the product team.
• DevOps: in the next integration step, the operations team is added within the already integrated development and user team.
• DevSecOps: finally, the security team is added to the groups that already exist in DevOps.

As another methodology terminology, it is natural that there are several definitions for the same term. Some of them:

• DevSecOps: A leader’s guide to producing secure software: DevSecOps is DevOps made securely.
• Hands-On Security in DevOps: DevOps offers speed and quality benefits with ongoing development and deployment methods, but it does not guarantee the security of an entire organization.
• DevSecOps by RedHat: Whether you call it “DevOps” or “DevSecOps”, it’s always been ideal for including security as an integral part of the entire application lifecycle.

But regardless of which term is preferred, the significant point is that with DevSecOps, we need to incorporate information security as part of the process. In other words: layered security, thinking from the end-user, through the engineering team, to database and operating-system configurations.

In addition to layered security, another core of the methodology is security automation. When we’re in the middle of a development treadmill, we tend to forget what we inevitably had to remember.

Information security tools can be integrated from CI/CD. That is, if there is any flaw, it can break the build. Within the categories of security tools, we can list some:

• SAST (Static application security testing) is a tool that scans the code statically and analyzes the code before compilation.
• DAST (Dynamic Application Security Testing): a tool that performs code validations at runtime.
• IAST (Interactive Application Security Testing): Runs application tests from a running application. The most significant difference between IAST and DAST is that the tests are performed within the application.

How Horusec can help you adopt the DevSecOps methodology in your project

In general, these tools help detect vulnerabilities, monitor bugs, and, above all, prevent security problems.

And among the tools that exist on the market, we have Horusec, one of the Open Source projects maintained by Zup and which focuses on making your application safer and preventing code vulnerabilities.

One of its differentials is its orchestration security feature tools. That is, it allows the integration of more tools. The main philosophy of the product is As much possible security: better!

Horusec also has a dashboard, which helps teams understand security issues within their application.

It is possible to integrate with Horusec in several ways, for example, with a CI like Github Action, and its might exports to the dashboard.

Prevention is the key, which means that if a PR has a vulnerability, the build “breaks”, preventing a future headache or vulnerability disaster from being merged into the production environment.

Currently, Horusec has three components:

• CLI, or the classic terminal, allows the analysis and visualization of vulnerabilities directly through the terminal.
• The Dashboard, or Horus-Manager, is an optional feature that allows you to view these vulnerabilities more intuitively than the terminal.
• An extension to IDE is also optional, making it easier to analyze vulnerabilities from the IDE itself. Today, we have the extension to use Horusec in Visual Studio Code.

An excellent first experience installing both the CLI and the dashboard, but don’t worry; you can find all the information in the official project documentation. Then you can analyze this repository which contains several vulnerabilities and in several programming languages.

It’s good to rely on tools like Horusec because they allow us, as development professionals, to have greater confidence in creating more secure code without vulnerabilities, thus preventing us from being the next responsible for the security of our project/product.

If you enjoy working on large-scale projects with global impact and if you like a real challenge, feel free to reach out to us at xgeeks! We are growing our team and you might be the next one to join this group of talented people 😉

Check out our social media channels if you want to get a sneak peek of life at xgeeks! See you soon!

Starting with information security: how to avoid headaches with vulnerabilities in your code was originally published in xgeeks on Medium, where people are continuing the conversation by highlighting and responding to this story.

Apache Kafka is a community-distributed streaming platform that has three key capabilities: publish and subscribe to streams of records, store streams of records in a fault-tolerant durable way, and then process streams as they occur. Apache Kafka has several successful cases in the Java world. This post will cover how to benefit from this powerful tool in the Spring universe.

Apache Kafka Core Concepts

Kafka is run as a cluster on one or more servers that can span multiple data centers; Kafka cluster stores a stream of records in categories called topics, and each record consists of a key, a value, and a timestamp.

From the documentation, Kafka has four core APIs:

• The Producer API allows an application to publish a stream of records to one or more Kafka topics.
• The Consumer API allows an application to subscribe to one or more topics and process the stream of records produced to them.
• The Streams API allows an application to act as a stream processor, consuming an input stream from one or more topics and producing an output stream to one or more output topics, effectively transforming the input streams to output streams.
• The Connector API allows building and running reusable producers or consumers that connect Kafka topics to existing applications or data systems.

Using Docker

There is also the possibility of using Docker. As it requires two images, one to Zookeeper and one to Apache Kafka, this tutorial will use docker-compose. Follow these instructions:

• Install Docker
• Install Docker-compose
• Create a docker-compose.yml and set it with the configuration below:

Then, run the command:

To connect as localhost, also define Kafka as the localhost within Linux, append the value below at the /etc/hosts:

Application With Spring

To explore Kafka, we’ll use the Spring-kafka project. In the project, we’ll simple a name counter, which is based on a request it will fire an event to a simple counter in memory.

The Spring for Apache Kafka (spring-kafka) project applies core Spring concepts to the development of Kafka-based messaging solutions. It provides a “template” as a high-level abstraction for sending messages. It also provides support for Message-driven POJOs with @KafkaListener annotations and a “listener container”. These libraries promote the use of dependency injection and declarative. In all these cases, you will see similarities to the JMS support.

The first step in a Spring project maven based, where we’ll add Spring-Kafka, spring-boot-starter-web.

Spring-kafka by default uses the String to both serializer and deserializer. We’ll overwrite this configuration to use JSON where we’ll send Java objects through JSON.

The first class is a configuration to either create a topic if it does not exist. Spring has a TopicBuilder to define the name, partition, and replica.

KafkaTemplate is a template for executing high-level operations in Apache Kafka. We’ll use this class in the name service to fire two events, one to increment and another one to decrement, in the Kafka.

Once we talked about the producer the KafkaTemplatethe next step is to define a consumer class. A Consumer class will listen to a Kafka event to execute an operation. In this sample, the NameConsumer will listen to events easily with the KafkaListener annotation.

To conclude, we see the potential of Apache Kafka and why this project became so accessible to Big-Data players. This is a simple example of how secure it is to integrate with Spring.

If you enjoy working on large-scale projects with global impact and if you like a real challenge, feel free to reach out to us at xgeeks! We are growing our team and you might be the next one to join this group of talented people 😉

Check out our social media channels if you want to get a sneak peek of life at xgeeks! See you soon!

References:

• https://docs.spring.io/spring-boot/docs/current/reference/html/spring-boot-features.html#boot-features-kafka
• https://spring.io/projects/spring-kafka
• https://docs.spring.io/spring-kafka/reference/html/
• Source

Introduction to Apache Kafka With Spring was originally published in xgeeks on Medium, where people are continuing the conversation by highlighting and responding to this story.

We know that, in a software project, nothing replaces good documentation. However, it is also necessary to pay attention to how intuitive the written code is. After all, the simpler and more natural the code is, the better its experience for users.

In the simple “programming rule”, in which we will forget everything we have to remember, an API that “forces” you to remember is crucial proof of failure.

That’s why, in this article, we’ll introduce the topic and show you how to create a fluid API from the Fluent-API concept.

What is a Fluent-API?

When we speak in the context of software engineering, a fluent-API is an object-oriented API whose design is largely based on method chaining.

This concept, created in 2005 by Eric Evans and Martin Fowler, aims to increase code readability by creating a domain-specific language (DSL).

In practice, creating a fluent API means developing an API in which it is unnecessary to memorize the next steps or methods, allowing for a natural and continuous sequence as if it were a menu of options.

This natural cadence works in a similar way to a restaurant or even a fast-food chain in that as you are putting together a dish, the options vary according to the choices you make. If, for example, you choose a chicken sandwich, the sides will be suggested considering the chosen dish and so on.

Fluent API in Java context

In the Java world, we can think of two famous examples of this type of implementation.

The first one is the JOOQ framework, a project led by Lukas Eder, which facilitates communication between Java and relational databases. JOOQ’s most significant difference is that it is data-oriented, which helps avoid and/or reduce the impedance problem, or loss, associated with relational and object-oriented.

Another example is in non-relational databases, i.e., NoSQL, within the specifications of the enterprise Java world. Among them is Jakarta EE, which is the first specification of its kind and which became Jakarta NoSQL under the umbrella of the Eclipse Foundation.

The purpose of this specification is to ensure smooth communication between Java and NoSQL databases.

Generally speaking, a fluent API is divided into three parts:

1. The final object or result: Overall, the fluent-API resembles the builder pattern, but the most powerful dynamic is coupled with DSL. In both, the result tends to be an instance representing the result of a process or a new entity.
2. The options: in this case, are the collections of interfaces or classes that will serve as “our interactive menu”. From an action, the idea is that show only the options available for the next step, following an intuitive sequence.
3. The result: after all this process, the answer may or may not result in an instance either for an entity, strategy, etc. The critical point is that the result must be valid.

Fluid API in practice

To demonstrate some of this concept, we’ll create a sandwich order with the expected result of an order with the corresponding purchase price. The flow will be as shown below.

Of course, there are several ways to implement this fluent API functionality, but we opted for a short version.

As we already mentioned the three parts of an API — object, options, and result -, we will start with the order that the “Order” interface will represent. A highlight is that this interface has some interfaces, which will be responsible for demonstrating our options.

The result of this API will be our order class. It will contain the sandwich, the drink, and their respective quantities.

A quick add-on before we go back to the tutorial

One point that we won’t focus on in this article, but that is worth mentioning, is related to the representation of money.

When it comes to numerical operations, it is ideal to use BigDecimal. That’s because, following references like the Java Effective book and the blog When Make a Type, we understand that complex types need a unique type. This reasoning, coupled with the pragmatism of “don’t repeat yourself” (DRY, or don’t repeat yourself), the result is the use of the Java specification for money: The Money API.

The last step in the journey is API implementation. It will be responsible for the “ugly” part of the code, making the API look beautiful.

The price list will be placed directly in the code since we don’t use a database or another data reference, and we intend to make the example as simple as possible. But it is worth stressing that, in a natural environment, this information would be in a database or a service.

The result is an API that will return the request to us straightforwardly and intuitively.

How is Fluent API different from others patterns?

It is widespread to have a comparison between two API standards, which are Builder and Fluent-API. The reason is that they both use methods in sequence for the process of creating an instance.

However, Fluent-API is “tied with a DSL”, and it forces an easy path to do so. But to make these differences even more evident, we’ve separated highlights for each of these patterns:

The Builder pattern:

• It tends to be much easier to implement;
• It is not clear which construction methods are needed;
• The vast majority of problems will happen at runtime;
• Some tools and frameworks create it automatically;
• It needs more robust validation in the build method to check which mandatory methods were not invoked.

The Fluent-API:

• It is important that, for each method, there is validation and throws the error if the parameter is invalid, remembers the fast fail premise;
• It must return a valid object at the end of the process.

And now, is it easier to understand the similarities and differences between patterns?

That is our introduction to the concept of fluent-API. As with all solutions, there is no “silver bullet”, as great complexity is often not justified for the entire process.

Our colleague Rafael Ponte often says that “the easier it is to use the API for the client, the more difficult it will be to design and implement it for the developer”.

It is an excellent tool that helps in creating a failsafe for you and other users. You can see more about it on Sou Java’s Github.

If you enjoy working on large-scale projects with global impact and if you like a real challenge, feel free to reach out to us at xgeeks! We are growing our team and you might be the next one to join this group of talented people 😉

Check out our social media channels if you want to get a sneak peek of life at xgeeks! See you soon!

Fluent-API: Creating Easier, More Intuitive Code with a Fluent API was originally published in xgeeks on Medium, where people are continuing the conversation by highlighting and responding to this story.

There is no doubt about the benefits good coding practices bring, such as clean code, easy maintenance, and a fluent API. However, do best practices help with data integrity? This discussion came up, mainly, with new storage technologies, such as the NoSQL database, that do not have native validation that the developer usually faces when working on SQL schema. A good topic that covers clean code is whose objects expose behavior and hide data, which differs from structured programming. The goal of this post is to explain the benefits of using a rich model against the anemic model to get data integrity and bulletproof code.

As mentioned above, an ethical code design also has an advantage in performance, once it saves requests to a database that has schema to check the validation. Thus, the code is agnostic of a database so that it will work in any database. However, to follow these principles, it requires both good OOP concepts and the business rules to make also a ubiquitous language. To make it smoother, this post will create a system that sorts a soccer player into a team; the rules of this system are:

• Player’s name is required
• All players must have a position (goalkeeper, forward, defender, and midfielder).
• Goals counter whose the player does on the team
• Contact’s email
• A team has players and names both as required
• A team cannot handle more than twenty players

With the information that was collected, there is the first draft code version:

As the first refactoring, once there are fixed positions, it does not fit in very well on String. To fix it, we will use enumeration instead of String.

Formerly introduced to the module fields, the next step is about security and encapsulation. Using Effective Java as a reference, the goal is to minimize the accessibility, thus just define all fields as private. Next, let’s put public getter and setter methods, right? Wrong! When a Java developer uses getters and setters unrestrained, it has the same effect on a public's field, causing loose coupling.

An accessor method must be used as the last resource that includes don’t create it as public visibility, in other words, as either default or protected, based on the encapsulation concern, it is possible to make the following conclusions:

• In the system sample, players do not change email, name, and position. Therefore, it does not need to create a setter method in these fields.
• The last year's field indicates when the player will leave the team by contract. When it is optional, it means that there is no expectation to the player leave the club. The setter method is required, but the last year must be equals to or higher than a year of start. Also, a player cannot start to play before when soccer was born in 1863.
• Just the team can handle a player; it must be a tight coupling.

In the Team class, there is a method used to add a player and a getter method returns all players from the team. The player must have a validation such as it cannot add a null player or cannot be higher than twenty players. A critical point on the getter to a collection is when directly returning an instance, the client might use the method to write directly such as clean, add, and so on. To solve the encapsulation, a good practice is to return a read-only instance such as unmodifiableList:

About the Player's class, all fields will have a getter method. The end field is an exception; once it may not exist at some point, a developer can return this attribute using an Optional to handle it instead of a null element. Still, on the end field, thesetter method is required once it either sets an end value or updates the end because the player renewed the contract and the validation is vital to guarantee the object integrity.

With the access method defined, the next step is the strategy of instance creation. Almost always, attributes are required for a new instance; the first move might create a constructor that receives all parameters. That fits on the Team class because it has a name parameter; however, in the player, there are several issues:

1. The first is on the parameters quantity; a polyadic is not a good practice for several reasons. For example, with too many arguments of the same type, it is possible to make a mistake when changing the order.
2. The second one is on the complexity of these validations.

An excellent way to solve it has two steps:

The first step is the type definition. This makes sense when an object has a colossal intricacy such as money, date. There is a nice post on When to Make a Type, which explains more on how to enhance code with this resource. A programmatic developer knows that reinventing the wheel is also a code smell. Therefore, the code will use the Date and Time API from Java 8 and JSR 354: Money-API. I just left the email type, as show the code below:

With the email type created, we have a new version of the Player's class:

The next step is a Builder design pattern, which follows the single responsibility to hold the duty to create a player instance. Furthermore, it avoids a mistake that changes the parameter order. Usually, mapper frameworks require a default constructor because it goes through reflection. Put the Deprecated annotation on this constructor to show that it is not a recommended method. An inner class fits in a builder because it can create a private constructor that only accesses the player builder.

Using a builder pattern on this principle, a Java developer knows when the instance exists and has valid information.

As mentioned before Team's class does not need once it is a smooth one.

When Java developers talk about validation, it is essential to speak of the Java specification that does it, the Bean Validation, BV, that makes it more accessible to a Java developer to create validation using annotation. It is critical to point out that BV does not invalidate POO concepts. In other words, avoid loose coupling, the SOLID principle is still valid instead of putting those concepts away. Therefore, BV can either double-check validation or execute the validation on the Builder to return an instance, only if it passes on the validation.

The next step is to do it safely and fluently. Yeap, we’ll cover a fluent API. The main point of a fluent API is to save time to check the documentation and make the communication with the API natural and smooth.

As an initial step, we’ll create an interface that will work as menu options, where the user can follow as a Windows Wizard:

The PlayerDSL class implements all the “menu options” as you can see in the class below:

As you can see, I don’t need to memorize the following API; the API will do it to me.

To conclude, this article demonstrates how to make code bulletproof using best design practices. Furthermore, we gain both object and data integrity at the same time. These techniques are agnostic from storage technology — the developer can use these principles in any enterprise software. That is important to say the tests are essential, but that is out of the article’s scope. In the next part of this topic, we will cover integration between this coding design with the database.

You can find the source code on GitHub.

If you enjoy working on large-scale projects with global impact and if you like a real challenge, feel free to reach out to us at xgeeks! We are growing our team and you might be the next one to join this group of talented people 😉

Check out our social media channels if you want to get a sneak peek of life at xgeeks! See you soon!

It is time to designing your code as Bulletproof Code! was originally published in xgeeks on Medium, where people are continuing the conversation by highlighting and responding to this story.

Spring Data JPA makes it easy to implement JPA-based repositories quickly. This module deals with enhanced support for JPA-based data access layers, and it is a proud member of the Spring family. This tutorial will be a short intro about Spring Data JPA and its functionality.

In the second part, we could cover the basic annotations on both Spring Core and the Spring Web, focusing on Rest Controller; however, we did not create an application with a database connection.

Fortunately, it is the goal of this part to make a connection easier and clean. We’ll use Spring Data because it reduces a lot of code, and it uses the JPA annotations.

To explore the JPA annotations with a repository, we’ll create simple rest to handle a person and its tickets through plan, train, and bus. The foremost goal here is to explore the heritage of both the JPA and JSON serialisation.

It is essential to highlight that there is an impedance mismatch. Thus objects are not RDBMS, and if we don’t think about it will apply to performance and a bad design.

Only to show the heritage, there is a Ticket as an abstract class with some specialisation. We used the Ticket class as an entity with a single table strategy, and in the Jackson, the values of the subtype both are using the field type.

The repository class integrates the database smoothly because the developer does not need to handle the implementation but with an interface. This repository has several features such as query by method and uses the Query annotation to execute queries without handle the undertaking.

The last layer is the controller, where we’ll do a tight integration with the repository once it is a light application. The PersonController has the pagination features beyond the CRUD operation.

In this tutorial, we could explore the Spring Data JPA API basics using the inheritance feature on both JPA and JSON. Spring has several resources that allow us to create a Rest application with a database integration with a couple of classes. It is essential to say that it is a first step in the JPA and Spring world where there are references to go deep below.

If you enjoy working at a large scale in projects with global impact and if you like a real challenge with Java, feel free to reach out to us at xgeeks! We are growing our team, especially in Java and you might be the next one to join this group of talented people 😉

Check out our social media channels if you want to get a sneak peek of life at xgeeks! See you soon!

References:

• Building a RESTful Web Service
• Serving Web Content with Spring MVC
• Building REST services with Spring
• Accessing Data with JPA
• LeaseWeb API Design Standards
• Hibernate Inheritance Mapping
• Glory of REST
• Source Code

Introduction to Spring Data JPA With Inheritance in a REST Application was originally published in xgeeks on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Spring Framework provides a comprehensive programming and configuration model for modern Java-based enterprise applications — on any deployment platform. It was born as a container of IoC. Still, nowadays, Spring is a platform that provides several tools to make the Java developer easier, such as Security, Data, etc. Those features have in common the Spring core. This tutorial will talk about the basic annotations to start to use Spring.

Spring is an annotation driver framework. Thus, it uses annotations to identify the components to inject and to use. The first step in this tutorial is a list of the most trivial annotations in Spring.

• Component: Indicates that an annotated class is a 'component.' Such classes are considered as candidates for auto-detection when using annotation-based configuration and classpath scanning.
• Repository: Indicates that an annotated class is a 'Repository,' originally defined by Domain-Driven Design (Evans, 2003) as 'a mechanism for encapsulating storage, retrieval, and search behavior which emulates a collection of objects.'
• Service: Indicates that an annotated class is a 'Service,' originally defined by Domain-Driven Design (Evans, 2003) as 'an operation offered as an interface that stands alone in the model, with no encapsulated state.'
• Qualifier: This annotation may be used on a field or parameter as a qualifier for candidate beans when autowiring. It may also be used to annotate other custom annotations that can then in turn be used as qualifiers.
• ComponentScan: Configures component scanning directives for use with @Configuration classes. Provides support parallel with Spring XML's <context:component-scan> element.
• SpringBootApplication: Indicates a configuration class that declares one or more @Bean methods and also triggers auto-configuration and component scanning.
• Configuration: Indicates that a class declares one or more @Bean methods and may be processed by the Spring container to generate bean definitions and service requests for those beans at runtime.
• Bean: Indicates that a method produces a bean to be managed by the Spring container.
• Primary: Indicates that a bean should be given preference when multiple candidates are qualified to autowire a single-valued dependency. If exactly one 'primary' bean exists among the candidates, it will be the autowired value.
• Lazy: Indicates whether a bean is to be lazily initialized.

To create a class observable in Spring, we need to use annotation. The basic ones are Component annotations and their specialization, such as Repository and Service.

Spring has support to polymorphism as well, where you can handle with several implementations, such as given a payment we have several options. There is the primary annotation to define a ‘default’ option, and there is a Qualifier where you can choose the implementation to select.

Spring has the option to us, as a developer, teach him how to create an instance. The idea is like the Produces annotation in CDI. So, you can use this class through Spring.

Usually, especially in Java, we create an application to communicate to another application through the HTTP request. Indeed, Spring supports it, and we did with the core annotations, below the basic’s annotations with Spring.

• SpringBootApplication: Indicates a configuration class that declares one or more @Bean methods and also triggers auto-configuration and component scanning.
• ResponseStatus: Marks a method or exception class with the status code and reason that should be returned.
• RequestMapping: Annotation for mapping web requests onto methods in request-handling classes with flexible method signatures.
• GetMapping: Annotation for mapping HTTP GET requests onto specific handler methods.
• RequestParam: Annotation which indicates that a method parameter should be bound to a web request parameter.
• PathVariable: Annotation which indicates that a method parameter should be bound to a URI template variable.
• PostMapping: Annotation for mapping HTTP POST requests onto specific handler methods.
• RequestBody: Annotation indicating a method parameter should be bound to the body of the web request.
• PutMapping: Annotation for mapping HTTP PUT requests onto specific handler methods.
• DeleteMapping: Annotation for mapping HTTP DELETE requests onto specific handler methods.

That is it; in this tutorial, we could cover a brief introduction about Spring and its annotations in both core and the rest controller. The goal is to help you start your project with Spring frameworks because this project has a bright future and will make your life easier as a Java developer.

References:

• Building a RESTful Web Service
• Serving Web Content with Spring MVC
• Building REST services with Spring
• Core Spring Framework Annotations

If you enjoy working at a large scale in projects with global impact and if you like a real challenge with Java, feel free to reach out to us at xgeeks! We are growing our team, especially in Java and you might be the next one to join this group of talented people 😉

Check out our social media channels if you want to get a sneak peek of life at xgeeks! See you soon!

Introduction to Spring Core Annotations API was originally published in xgeeks on Medium, where people are continuing the conversation by highlighting and responding to this story.

One of the great news introduced in the Java world is related to the version cycle, of which we have a release every six months and a version of Long Term Support every three years. Currently, the LTS version is Java 11, from which many companies are moving towards its use. First, this movement is significant because new frameworks will not support Java 8 and will consider Java 11 as a minimum beyond the point that the next LTS will be in September 2021 with Java 11. The purpose of this article is to talk a little about the basic APIs that happens between Java 8 and Java 11.

The Functions Classes

An important point that will serve as a basis, starting with Java 8, is the new interfaces within the java.util.function package, in this overview, we'll see covert four interfaces:

Function: Represents a function that accepts one argument and produces a result:

Predicate: Represents a predicate (boolean-valued function) of one argument.

Supplier: Represents a supplier of results.

Consumer: Represents an operation that accepts a single input argument and returns no result.

On those interfaces, we’ll see several improvements, such as in the Collections implementations:

Also, there are new methods factories to make it easier to create the collections interfaces:

Stream is a sequence of elements supporting sequential and parallel aggregate operations. We can think about a waterfall or a river flow. This API is robust and clean to manipulate a collection such as:

When Java 8 was released, a new Date and Time API with new types, immutable classes, practical news methods, and finally Enums to the day of weeks and months instead of numbers.

As the current LTS, Java 11 has several features that make the developer live easier in their day job. This post was only an overview and quickly started with Java 11 and missed some Java 8. There are many references about the feature to each new version.

References:

• Intro to Stream
• Stream API
• Introduction to the Java Date/Time API
• Java 11 New Features
• New Features in Java 9
• New Features in Java 10
• Sample Source

If you enjoy working at a large scale in projects with global impact and if you like a real challenge with Java, feel free to reach out to us at xgeeks! We are growing our team, especially in Java and you might be the next one to join this group of talented people 😉

Check out our social media channels if you want to get a sneak peek of life at xgeeks! See you soon!

An Overview Between Java 8 and Java 11 was originally published in xgeeks on Medium, where people are continuing the conversation by highlighting and responding to this story.

Indeed, the use of containers has made the use and adoption of cloud computing a lot easier, and with its most significant differential, the application isolation refuse. Making an analogy with the Java world of which we have the WORA Write Once Read Anywhere with containers, we have the PORA Package Once Run Anytime. Since the container, on a general basis, focuses on being an isolated package within an application. The purpose of this article is not to talk about the inner workings of a container. However, we have this excellent article from Larry that manages to address more about the subject.

Within the microservices world, Leonard Richardson breaks down the principal elements of a REST approach into three steps. These introduce resources, HTTP verbs, and hypermedia controls. In the cloud computing environment, there is still no similar thing for the glory of the cloud. However, there is an excellent debate about some elements of migrating an application until the cloud computing environment arrives:

1. Orchestrator: Once you work with containers and isolate applications, the next step would be to create mechanisms to manage such containers.
2. CI/CD: A good code is a code in production, however, with the most outstanding possible security. The use of CI / CD tools helps in this regard.
3. Infrastructure as code: Creates a declarative API for operations; this allows for greater integration and the implementation of the DevOps culture, in addition to the significant first step towards greater automation of processes.
4. GitOps: Git becomes a source of truth for both code and operations.

The first step is to run the terminal application and then run the same application, however, with docker-compose. For the installation of the database, Docker will help straightforwardly. Thus, to start a PostgreSQL instance, it is necessary to execute with the following command:

The next step is to run the application; once we use maven, there is a command to prepare the application.

The application is running; feel free to perform tests within the application. It is missing API documentation such as Swagger and Open API, which we won’t cover.

The next step is to run this same application within the docker-compose; Spring has a maven plugin to create a Docker image integrated with Paketo.

After the build, there may be a new image with the version’s name according to the project in maven.

The next and last step is to create the docker-compose.yml file:

We present all the initial concepts to create an application locally or through the docker, through a plugin from Spring itself. With Spring JDBC, there was a significant reduction in code compared to JDBC of the core java. However, there are still tools that managed to reduce this complexity even more. In the third and last part of the series, there will be a refactoring to use the same problem using Spring Data JPA.

If you enjoy working at a large scale in projects with global impact and if you like a real challenge with Java, feel free to reach out to us at xgeeks! We are growing our team, especially in Java and you might be the next one to join this group of talented people 😉

Check out our social media channels if you want to get a sneak peek of life at xgeeks! See you soon!

Introduction to Spring Boot and JDBCTemplate: Introduction to Docker was originally published in xgeeks on Medium, where people are continuing the conversation by highlighting and responding to this story.