What's New With Jakarta NoSQL? (Part 1): Intro to Document With MongoDB
This post will talk about the newest milestone version of this new specification and more.
Join the DZone community and get the full member experience.Join For Free
Jakarta EE picks up where Java EE 8 left off, but the roadmap going forward will be focused on modern innovations like microservices, modularity, and NoSQL databases. This post will talk about the newest milestone version of this new specification and the subsequent actions to make the Jakarta EE community even greater in the cloud.
Why Jakarta NoSQL?
Vendor lock-in is one of the things any Java developer needs to consider when choosing NoSQL databases. If there’s a need for a switch, other considerations include time spent on the change, the learning curve of a new API to use with this database, the code that will be lost, the persistence layer that needs to be replaced. Jakarta NoSQL avoids most of these issues through Communication APIs. Jakarta NoSQL also has template classes that apply the design pattern ‘template method’ to database operations. And the
Repository interface allows Java developers to create and extend interfaces, with implementation automatically provided by Jakarta NoSQL — support method queries built by developers will automatically be implemented for them.
You might also like: Jakarta EE: Generation IV — A New Hope
To make it clear, let’s create some sample code. The picture below shows four different databases:
What do Those Databases Have in Common?
Yup, they’re all document NoSQL databases, and they’re trying to create a document, a tuple with a name, and the information itself. They’re all doing the exact same thing with the same behavior goal, however, with a different class, method name, and so on. So, if you want to move your code from one database to another, you need to learn a new API and update the whole database code to the database API code target.
Through the communication specification, we can easily change between databases just by using the driver databases that look like JDBC drivers. So, you can be more comfortable learning a new NoSQL database from the software architecture perspective; we can easily and quickly jump to another NoSQL.
Show me the
To demonstrate how the Jakarta NoSQL works, let’s create a small REST API; that API will run in cloud with Platform.sh. The API will handle the heroes, and all the information will be stored into MongoDB. As a first step, we need to set the dependencies Jakarta NoSQL needs:
- Jakarta Context Dependency Injection 2.0. Jakarta Contexts Dependency Injection specifies a means for obtaining objects that maximize reusability, testability, and maintainability—compared to traditional approaches such as constructors, factories, and service locators. Think of it as a glue for the entire Jakarta EE world.
- Jakarta JSON Binding. Defines a binding framework for converting Java objects to and from JSON documents.
- Jakarta Bean Validation 2.0 (optional). Jakarta Bean Validation defines a metadata model and API for JavaBean and method validation.
- Eclipse MicroProfile Configuration (optional). Eclipse MicroProfile Config is a solution to externalize configuration from Java applications.
One amazing aspect of using Platform.sh is that we don’t need to worry about the infrastructure installation that includes the MongoDB server itself; it will create several containers that include the application and the database. We’ll talk more about Platform.sh and its relationship with cloud-native soon.
The first step is to create the Hero entity, in the annotations package now as
The next step is to create a connection to the NoSQL database, so we’ll create a
DocumentCollectionManager instance. Think of
EntityManager as a Document database. We know that hard-coded information isn’t safe nor is it a t good practice. That’s why the twelve-factor mentions it in the third section. Further, the application doesn’t need to know where this information comes from. To follow the good practices of the twelve-factor and to support the cloud-native principle, Jakarta NoSQL has support for the Eclipse MicroProfile Configuration.
Once this is done, we create a connection class that makes a
DocumentCollectionManager instance available to CDI, thanks to the method annotated with
The database configuration is ready to run locally. For this application beyond the CRUD, let’s create three more queries:
- Find all Heroes
- Find Heroes older than a certain age
- Find heroes younger than a certain age
- Find Heroes by the name, the id
- Find Heroes by the power
We have several ways to create this query into Jakarta NoSQL. Let’s introduce the first way with
DocumentTemplate. The template classes execute operations into NoSQL database in the
Mapper layer, so there’s a template class for each NoSQL type that Jakarta NoSQL supports:
DocumentTemplate for document,
KeyValueTemplate for key-value database, and so on.
Document Template, we have two paths to consult information into NoSQL databases. The first one is programmatically. The API has a fluent way to create a
To talk about the ‘find all heroes’ query, we’ll create a specific class because when we talk about returning all information in a database, we need to avoid an impact on performance. Given a database might have more than one million information points, it doesn’t make sense to bring all this information at the same time (in most cases).
Also, the API has the pagination feature that easily accommodates pagination and functions with large sets of data.
A fluent API is amazing and safe to write and reads queries for a NoSQL database, but how about query by text? While a fluent API is safer, it’s sometimes verbose. You know what, though? Jakarta NoSQL has support to query by text that includes
PrepareStatement where, as a Java Developer, you can set the parameter dynamically.
What do you think? Too complex? Don’t worry, we can simplify it for you with a Repository. A repository abstraction is here to significantly reduce the amount of boilerplate code required to implement data access layers for various persistence stores.
This concludes the first part of our post, introducing the concept behind Jakarta and NoSQL, and the document API with MongoDB. In part two, we’ll talk about cloud-native, and how to easily move this application to the cloud using Platform.sh. If you’re curious and don’t mind a spoiler, you can take a look at the sample code on your repository.
Published at DZone with permission of Otavio Santana, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.