Note: this article was created based on one of the services we implement in my Ktor Server Pro course. If you would like to learn how to expose a fully functional REST API, secure the application, and many many more, then don’t hesitate and secure your spot today😉

Before we start, I just wanted to mention that at the moment of writing KMongo is officially deprecated! Maybe you saw my previous article, maybe you saw some outdated content in some other places. Either way, we should not use that library anymore in favor of the official driver that comes in two flavors:

• MongoDB Kotlin Driver (for applications using coroutines)
• MongoDB Kotlin Sync Driver (for apps that require synchronous processing)

Video Content

As always, if you prefer a video content, then please check out my latest YouTube video:

Create & Verify MongoDB Instance

If you already have a MongoDB instance installed on your machine, feel free to skip this step.

On the other hand, if that is not the case, you can install it using the official manual. Or, if you just like me have a Docker environment, you can run the following command:

docker run --name my_awesome_mongo_name -d -p 27017:27017 mongo:8.0.4

This way, we run the Mongo docker container and expose it’s port 27017 .

And to verify it running, we can run the docker ps :

CONTAINER ID   IMAGE         COMMAND                  CREATED          STATUS          PORTS                      NAMES
9ecd8986ac34   mongo:8.0.4   "docker-entrypoint.s…"   20 seconds ago   Up 19 seconds   0.0.0.0:27017->27017/tcp   my_awesome_mongo_name

As we can see, it was created successfully and we should be able to connect to it at localhost:27017

We can assert that, as well, for example with a free and official tool- MongoDB Compass:

And if we are able to connect, it means that we can head to the next step.

Create a New Ktor Project

Nextly, let’s navigate to the Ktor Project Generator page to create a fresh project from scratch.

If you use the IntelliJ Ultimate Edition, then you can generate it in your IDE

As we can see, we will be using Ktor 3.1.0 with Netty and configuration in the YAML file.

The important thing to mention here is that if we want to work with Kotlin coroutines, we should not select the below MongoDB plugin:

Because as we can see, this adds the MongoDB Kotlin Sync Driver for synchronous processing:

So, in our case, to keep our Ktor application as vanilla as possible, we will not add any additional plugins.

With that done, let’s hit the Download button and let’s import the project to our IDE.

Add MongoDB Async Driver to Ktor

Before adding the necessary import, let’s perform a small cleanup.

Firstly, let’s remove the Routing.kt file- we don’t need it for this tutorial.

Then, let’s navigate to the Application.kt and let’s get rid of routing config, as well. Eventually, we should have something like that:

 package com.codersee

import io.ktor.server.application.*

fun main(args: Array<String>) {
    io.ktor.server.netty.EngineMain.main(args)
}

fun Application.module() {}

With that done, let’s add the MongoDB Kotlin Driver to work with coroutines.

During the configuration, we decided to use the Gradle version catalog. So now, we must navigate to the libs.versions.toml inside the gradle directory and add the mongodb-version along with mongodb-driver-kotlin:

[versions]
kotlin-version = "2.1.10"
ktor-version = "3.1.0"
logback-version = "1.4.14"
mongodb-version = "5.3.1"

[libraries]
ktor-server-core = { module = "io.ktor:ktor-server-core-jvm", version.ref = "ktor-version" }
ktor-server-netty = { module = "io.ktor:ktor-server-netty", version.ref = "ktor-version" }
logback-classic = { module = "ch.qos.logback:logback-classic", version.ref = "logback-version" }
ktor-server-config-yaml = { module = "io.ktor:ktor-server-config-yaml", version.ref = "ktor-version" }
ktor-server-test-host = { module = "io.ktor:ktor-server-test-host", version.ref = "ktor-version" }
kotlin-test-junit = { module = "org.jetbrains.kotlin:kotlin-test-junit", version.ref = "kotlin-version" }
mongodb-driver-kotlin = { module = "org.mongodb:mongodb-driver-kotlin-coroutine", version.ref = "mongodb-version" }

[plugins]
kotlin-jvm = { id = "org.jetbrains.kotlin.jvm", version.ref = "kotlin-version" }
ktor = { id = "io.ktor.plugin", version.ref = "ktor-version" }

With that done, let’s navigate to build.gradle.kts and add the following line:

implementation(libs.mongodb.driver.kotlin)

Lastly, let’s sync the gradle project so that the necessary libraries are fetched.

Introduce Model Classes

Before we can start working with coroutines, we must prepare classes that will be translated into Mongo documents and vice versa.

To do so, let’s create the Product.kt class and put the following:

import org.bson.codecs.pojo.annotations.BsonId
import org.bson.types.ObjectId

data class Product(
    @BsonId
    val id: ObjectId? = null,
    val name: String,
    val description: String,
    val price: Double,
    val category: ProductCategory,
    val tags: List<ProductTag>,
)

enum class ProductCategory {
    VIDEO_GAMES, TOOLS, HOME_AND_KITCHEN, FOOD
}

enum class ProductTag {
    EXCLUSIVE, HANDMADE, ORGANIC, BESTSELLER
}

As we can see, all fields except the id field are plain Kotlin classes. And later, they will be serialized/deserialized 1:1 when saving and retrieving from the database.

When it comes to the id field, we mark it using the @BsonId annotation. Thanks to that, it will be serialized to the _id BSON field that represents a primary key of our document. Moreover, we assign a default null value to it. This way, the value will be generated automatically.

Configure Ktor Connection to MongoDB

As the next step, let’s connect our Ktor application to the Mongo instance.

And for that purpose, let’s navigate to Application.kt and implement the following logic:

fun Application.module() {
    val settings = MongoClientSettings.builder()
        .applyConnectionString(
            ConnectionString("mongodb://localhost:27017")
        )
        .build()

    val client = MongoClient.create(settings)
    val database = client.getDatabase("application")
    val productCollection = database.getCollection<Product>("products")
}

Firstly, we instantiate the MongoClientSettings builder. A builder that allows us to configure the connection string for our database. Additionally, if you are looking for more configuration options, like reads or writes repetition, then you should start in there.

Then, we create a new client and pass our settings to it. If you would like to, then you could use another variant of the create function that takes the connection String as an argument:

public fun create(connectionString: String): MongoClient

But, in my opinion, using the builder approach is a better choice in terms of extensibility.

With that done, we get the instance of our database, by passing its name. Lastly, we obtain the MongoCollection that we will be injecting later into the product repository. Again, we pass the name of our collection, too.

To verify, let’s run our application.

As a result, we should see the following text in the logs indicating that everything is perfectly fine:

[cluster-ClusterId{value='67bd5f4689251d25d5077fb7', description='null'}-localhost:27017] INFO  org.mongodb.driver.cluster - Monitor thread successfully connected to server with description ServerDescription{address=localhost:27017, type=STANDALONE, cryptd=false, state=CONNECTED, ok=true, minWireVersion=0, maxWireVersion=25, maxDocumentSize=16777216, logicalSessionTimeoutMinutes=30, roundTripTimeNanos=26289200, minRoundTripTimeNanos=0}

MongoDB Coroutines CRUD Operations

After we did all of that preparation, we can finally create the ProductRepository class:

class ProductRepository(
    private val productCollection: MongoCollection<Product>,
) { }

And inject the collection in Application.kt :

val productRepository = ProductRepository(productCollection)

The constructor injection is a great way to make our code easier to test in the future.

Anyway, coming back to the topic, let’s learn how we can how we can perform basic CRUD operations with coroutines.

Persits Products

Initially, our products collection is empty, so let’s add the following code to start populating it:

suspend fun save(product: Product): Product? {
    val result = productCollection.insertOne(product)

    return result.insertedId
        ?.let { product.copy(id = it.asObjectId().value) }
}

First of all, we must make our function suspend. Why? Because the insertOne we use is a suspend function, so we must invoke it either from the coroutine or another suspend function.

When it comes to the persisting- the function that we use returns the InsertOneResult that allows us to either get a boolean informing if the write was acknowledged or the generated identifier of the saved product. And in my opinion, reading that and returning a Product instance with the updated field is a quite nice approach.

After that, let’s get back to the Application.kt and test this function:

val saved = runBlocking {
    productRepository.save(
        Product(
            name = "Product 1",
            description = "Description 1",
            price = 19.99,
            category = ProductCategory.TOOLS,
            tags = listOf(ProductTag.EXCLUSIVE, ProductTag.BESTSELLER)
        )
    )
}

println(saved)

I know, the good, old println 🤠

Anyway, if we run our application, we should see the following in the logs:

Product(id=67bd62f974edd96bbd59874a, name=Product 1, description=Description 1, price=19.99, category=TOOLS, tags=[EXCLUSIVE, BESTSELLER])

Additionally, when we hit the refresh button in MongoDB Compass, we should see the following:

And this proves that not only the Product was saved. But also, the application database and products collection was created by our client automatically.

Find By ID

Nextly, let’s implement the function to fetch product by identifier:

suspend fun findById(id: String): Product? {
    val objectId = ObjectId(id)

    return productCollection.find(
        eq("_id", objectId)
    ).firstOrNull()
}

This time, we use the find method. And this function returns the FindFlow which is the Flow implementation for find operations.

This function allows us to pass filters as arguments to it. And to get the particular product, we use the eq filter. One of the many filters that we can find in com.mongodb.client.model.Filters. We must remember that our identifier is of the ObjectId type, so we create a new instance from our String value.

Lastly, we invoke the firstOrNull– the terminal operator that returns the first element emitted by the flow and then cancels flow’s. We leverage the fact that only one element with such an identifier can be found in our database.

So with all of that done, let’s get back to the Application.kt and test this function:

val found = runBlocking {
    productRepository.findById("67bd62f974edd96bbd59874a")
}

val notFound = runBlocking {
    productRepository.findById("67bd62f974edd96bbd59874b")
}

// Logs: 

// Product(id=67bd62f974edd96bbd59874a, name=Product 1, description=Description 1, price=19.99, category=TOOLS, tags=[EXCLUSIVE, BESTSELLER])

// null

As we can see, our test proves that findById not only works but also it simply returns null when nothing was found. No unexpected exceptions, etc.

Updating Products

As the next step, let’s add the function responsible for updating products:

suspend fun update(id: String, product: Product): Product? {
    val objectId = ObjectId(id)

    return productCollection.findOneAndReplace(
        filter = eq("_id", objectId),
        replacement = product,
        options = FindOneAndReplaceOptions().returnDocument(ReturnDocument.AFTER)
    )
}

Again, this function is a suspended function, and again we use the same combination of the eq filter and ObjectId to find the item we are interested in.

The function that we use- findOneAndReplace– allows us to simply replace the existing document by passing a new version. Nevertheless, by default, this function returns the object before the update! And in my opinion, it makes more sense to return the updated versions in this case. And that’s why we specify the additional option.

As a note: if you would like to update just some fields, then the findOneAndUpdate may be a better choice.

With all of that done, let’s test our functionality:

val updated = runBlocking {
    productRepository.update(
        id = "67bd62f974edd96bbd59874a",
        product = Product(
            name = "Updated Product 1",
            description = "Updated Description 1",
            price = 20.11,
            category = ProductCategory.FOOD,
            tags = listOf(ProductTag.BESTSELLER)
        )
    )
}

val notUpdated = runBlocking {
    productRepository.update(
        id = "67bd62f974edd96bbd59874b",
        product = Product(
            name = "Updated Product 2",
            description = "Updated Description 3",
            price = 20.11,
            category = ProductCategory.FOOD,
            tags = listOf(ProductTag.BESTSELLER)
        )
    )
}

// Logs: 

// Product(id=67bd62f974edd96bbd59874a, name=Updated Product 1, description=Updated Description 1, price=20.11, category=FOOD, tags=[BESTSELLER])

// null

As we can see, everything works as expected. Our function returns the updated product. And moreover, it does not throw any exceptions when a product is not found!

Delete Products

Nextly, let’s take a look at how we can remove products from our database:

suspend fun deleteById(id: String): Boolean {
    val objectId = ObjectId(id)

    val deleteResult = productCollection.deleteOne(
        eq("_id", objectId)
    )

    return deleteResult.deletedCount == 1L
}

At this point of our MongoDB coroutines tutorial, I think the code is quite descriptive. We use the same pattern we did previously to find by ID and we utilize the function from DeleteResult to get the count of deleted items.

Of course, given we have only one item with a particular _id, the function returns true only if the count is equal to one.

And again, a small note from my end if you would like to return the deleted product instead, then you can use the findOneAndDelete instead.

I will skip the testing part here, you must trust me 😀

Case-insensitive Search In MongoDB

As the last step, I will show you how to utilize the function that we already know (find) to perform a case-insensitive search in MongoDB:

fun find(
    title: String,
): Flow<Product> {
    return productCollection.find(
        regex(Product::name.name, title, "i")
    )
}

As we can see, this time we make use of the regex function, that will add the… regex filter 😀 And thanks to the “i” option, the whole search will be case-insensitive.

Additionally, we make use of the name field reference. We could use a simple String value- “name”- but thanks to our approach we won’t need to remember to manually update the name in case of the update.

Lastly, I just wanted to mention here that this is one of the approaches to tackle this issue. According to the Mongo docs, we have also two more options:

1. Create a case-insensitive index with a collation strength of 1 or 2, and specify that your query uses the same collation.
2. Set the default collation strength of your collection to 1 or 2 when you create it, and do not specify a different collation in your queries and indexes.

Adding Sorting and Pagination to Search Results

Lastly, let’s make a small adjustment to add pagination and sorting to our logic.

To do so, let’s implement the Order Enum first:

enum class Order {
    ASC, DESC
}

And with that done, let’s get back to our repository:

fun find(
    title: String,
    sortBy: String,
    order: Order,
    limit: Int,
    skip: Int,
): Flow<Product> {
    val sort = when (order) {
        Order.ASC -> ascending(sortBy)
        Order.DESC -> descending(sortBy)
    }

    return productCollection.find(
        regex(Product::name.name, title, "i")
    )
        .sort(sort)
        .limit(limit)
        .skip(skip)
}

As we can see, our function allows us to pass 4 more arguments during the invocation: sortBy, order, limit, and skip.

So from now on, we can not only perform the search but also set the limit of results, ordering, as well as the order of items.

Summary

And that’s all for this tutorial on how to work with MongoDB and Kotlin coroutines in Ktor.

I hope you enjoyed it, and if you would like to learn more Ktor concepts in a fully hands-on manner, then check out my course.

Lastly, if you would like to get the whole codebase, then you can find it in this GitHub repository.

The post MongoDB with Kotlin Coroutines in Ktor appeared first on Codersee blog- Kotlin on the backend.

In this short article, I will show you how to fix this issue based on the example project.

Trigger The CodecCacheKey in Micronaut Test

Before I show you how to fix this issue, let me quickly introduce you to how I trigger the CodecCacheKey issue when writing tests in Micronaut. (If you are interested in the whole project, check this article about Micronaut with MongoDB).

So firstly, I created a simple AppUser data class:

import io.micronaut.data.annotation.GeneratedValue
import io.micronaut.data.annotation.Id
import io.micronaut.data.annotation.MappedEntity

@MappedEntity
data class AppUser(
  @field:Id
  @field:GeneratedValue
  val id: String? = null,
  val firstName: String,
  val lastName: String,
  val email: String,
  val address: Address
)

Nothing spectacular. Just a simple class with a few annotations necessary to work with MongoDB and generate identifiers automatically.

As the next step, I added the repository, which looked, as follows:

@MongoRepository
interface AppUserRepository : CrudRepository<AppUser, String> {
 
  // few methods 
}

And all of that together with other classes that are not important in this tutorial, created a structure, like this:

So, lastly, I added a simple test with @MicronautTest, JUnit 5, and REST Assured to test whether my REST endpoint returns users from the Mongo database:

@MicronautTest
class AppUserControllerTestWithoutMocking {

  @Test
  fun `should return 200 OK on GET users`(spec: RequestSpecification) {
    spec
      .`when`()
      .get("/users")
      .then()
      .statusCode(200)
      .header("Content-Type", "application/json")
  }
}

As a result, instead of the beautiful, green icon indicating that everything is fine, I got the following:

[io-executor-thread-1] ERROR i.m.http.server.RouteExecutor - Unexpected error occurred: Can't find a codec for CodecCacheKey{clazz=class com.codersee.model.AppUser, types=null}.
org.bson.codecs.configuration.CodecConfigurationException: Can't find a codec for CodecCacheKey{clazz=class com.codersee.model.AppUser, types=null}.
	at org.bson.internal.ProvidersCodecRegistry.lambda$get$0(ProvidersCodecRegistry.java:87)
	at java.base/java.util.Optional.orElseGet(Optional.java:364)
	at org.bson.internal.ProvidersCodecRegistry.get(ProvidersCodecRegistry.java:80)
	at org.bson.internal.ProvidersCodecRegistry.get(ProvidersCodecRegistry.java:50)
	at com.mongodb.internal.operation.Operations.createFindOperation(Operations.java:188)
...

Moreover, when I ran the application manually and tested using a real MongoDB instance, everything worked fine.

How To Fix CodecCacheKey Issue?

In order to fix the issue, I created a new file- called application-test.properties in the resources directory and put the following:

mongodb.package-names=com.codersee.model

But what exactly does it do?

Well, firstly, the application-test name of the file instructs the Micronaut framework to use this property file only when running tests.

Secondly, with the mongodb.package-names, I set package names to allow for POJOs. And that’s why I put the com.codersee.model only.

And voila, that’s all 🙂

Summary

And basically, that’s all for this short tutorial on how to fix the issue with CodecCacheKey in Micronaut.

Thank you for being here, and if you would like to learn more about the framework, then check out other posts from the Micronaut category.

If you would like to see the codebase for this tutorial, please refer to my GitHub repository.

The post Fix “Can’t find a codec for CodecCacheKey” in Micronaut appeared first on Codersee blog- Kotlin on the backend.

Please keep in mind this is the 4th blog post in a series about the most popular databases, and you can find the previous articles right here:

• Discover the Power of PostgreSQL: A Comprehensive Introduction
• MySQL Essentials: A Fast-Paced Introduction
• Redis Database Explained

Please sit back, relax, and get ready to discover why MongoDB is taking the world by storm.

Explainer Animation

If you enjoy whiteboard animations, then right here you can find a video version of this article:

If you find this content useful, please leave a subscription  😉

MongoDB History

As the first thing in our MongoDB overview, let’s take a second to learn more about its genesis.

MongoDB’s history starts in October 2007 in a company called 10gen. The founders were looking for a scalable solution, capable of dealing with a high volume in their internal project. (Un)Fortunately, at that time relational databases were not well-suited to handle the kind of semi-structured data they needed. As a result, they decided to build their own NoSQL database with the scalability and large amounts of unstructured data handling in mind.

Almost two years later, in February 2009, Mongo was released as an open-source project. Since then, it quickly gained popularity among developers and businesses who were looking for more flexible solutions. Of course, compared to relational databases.

In 2013, 10gen changed its name to MongoDB, reflecting the growing popularity of the database.

Today, Mongo is widely used by organizations of all sizes, across various industries. Not to mention, we can choose not only between the Community and Enterprise editions but also a cloud-based database as a service called MongoDB Atlas.

MongoDB Overview

MongoDB is written in C++ and uses a binary form of JSON called BSON (Binary JSON) to store data. These documents can have fields that hold values of different types, such as:

• strings,
• numbers,
• arrays,
• and even nested documents.

Just like rows in relational databases are combined together in tables, Mongo documents are grouped in collections. Of course, with one, important difference: each document can have a different structure.

When it comes to scalability, MongoDB uses a sharding architecture to scale horizontally. Sharding, in simple words, allows a Mongo cluster to store more data than can fit on a single server by automatically partitioning the data across multiple machines. In such a situation, each shard contains a subset of the data and the query will be directed to the appropriate shard based on the query.

Of course, MongoDB also provides additional advanced features, like complex query language, indexing, a full-text search, and a replica set mechanism.

Mongo Advantages

So, with all of that covered, we can take a while to learn a couple of MongoDB advantages:

• Firstly, flexibility. As I already mentioned in this MongoDB overview, documents within a collection do not need to have the same structure, or fields, unlike traditional relational databases. Mongo allows for a flexible schema and can be a great choice for some projects.
• Moreover, document-oriented storage makes it relatively easy to work with MongoDB using popular programming languages that have built-in support for JSON.
• Thirdly, great performance. Mongo is designed for high performance and can handle large amounts of data.
• Additionally, scalability and high availability. MongoDB can be easily scaled and comes with built-in support for automatic failover and replication.
• And finally- it’s easy to use. Mongo provides a simple command-line interface and it is easily integrated with a lot of programming languages and tools.

Disadvantages

Of course, I must list a couple of disadvantages in this MongoDB introduction, as well:

• Firstly, Mongo uses a MongoDB Query Language (MQL). And although it has the same syntax as documents (which makes it really intuitive), it’s nothing universal and we have to learn it in order to work with the database. This is not the case, for example when working with SQL.
• Moreover, MongoDB does not support joins, which we know from relational databases. And although combining documents, or collections together is still doable, it might be a bit tricky task.
• Additionally, documents cannot exceed 16MB.
• And lastly- data redundancy. Due to the lack of joins, we oftentimes duplicate data across the documents, which may lead to harder maintenance.

Overview Of MongoDB Use Cases

With all of that said, let’s figure out when Mongo can be a good choice:

• And as the first one- content management. It can be used to store and manage large amounts of structured and unstructured content, thanks to its flexibility.
• Secondly, the Internet of Things. MongoDB is a popular choice for storing and processing large amounts of data generated by IoT devices. Mongo is not only great at dealing with large amounts of data but also can handle semi-structured and unstructured data sent by IoT devices.
• Additionally- e-commerce and recommendation systems. A flexible schema allows for easy storage of various types of product data, like prices, descriptions, etc. Moreover, MongoDB support for complex queries and aggregations can help easily create search engines and recommendation systems
• And as the last one, a bit more general- real-time applications. MongoDB’s low latency and high performance make it a great choice for any real-time application, like social media for instance.

Which Companies Use MongoDB?

And as the last thing in our MongoDB overview, let’s figure out which companies are using it in their technology stack.

eBay uses MongoDB to store information on items for sale and to power the search functionality. Additionally, Mongo is used to store data about users’ browsing and buying history, which is then used for personalization purposes.

Another great example is Vodafone, which uses it for IoT, new 5G innovations, and cloud-native apps.

Moreover, Uber makes use of Mongo to store and manage data related to its operations, such as information on drivers, riders, and rides.

Of course, the list is much longer and contains over 35,000 customers, like Forbes, MetLife, Elementor, and Fiverr.

MongoDB Overview – Summary

And that’s all for this MongoDB overview. I hope that you enjoyed this introduction and if that’s the case, then please let me know in the comments 🙂

Of course, if you’d like to expand your knowledge of MongoDB in practice, then check out my other resources:

• REST API With Micronaut, Kotlin, and MongoDB Course
• A Guide To Ktor With MongoDB
• Spring Boot MongoDB REST API CRUD with Kotlin

Thank you and see you in the next articles!

The post MongoDB Overview. Introduction To The Most Popular NoSQL DB appeared first on Codersee blog- Kotlin on the backend.

In this article, we will take a look at the 8 most popular databases and their key features, as well as common use cases.

So, no matter whether you are a database administrator, programmer, or simply would like to learn more about the different databases available, this article will provide you with all the necessary information to start with.

Doodly Animation

If you find this content useful, please leave a thumb up, or a sub. This way you can help me, so that I can help you 😉

What Does “The Most Popular Databases” Mean?

Well, before we start I wanna make sure that we are on the same page when referring to the “most popular”.

Depending on who wrote the article, this term can have various meanings. For some, it will be the frequency of Google searches. For others, it may be data provided by the https://db-engines.com page.

And for the purpose of this blog post, I decided to use the Stack Overflow Developer Survey 2022 results, which present, as follows:

In the next chapters, I will walk you through each of the 8 most popular databases shortly.

Please keep in mind that this article is a general overview and expect that more thorough continuations will be added in the upcoming weeks 🙂

MySQL Database

With that being said, let’s start with the winner- MySQL.

It’s an open-source relational database management system (aka RDBMS). It was created in 1994 by the Swedish company MySQL AB (which was later acquired by Sun Microsystems and then by Oracle Corporation). Originally, it was developed as a proprietary database system but later it was open-sourced under the GNU General Public License.

Advantages:

• It’s free and open-source, so it can be a great choice for smaller companies and organizations preferring to cut costs.
• Moreover, MySQL is widely supported by web hosting providers, which means that it can be easily integrated with web-based applications.
• Additionally, it has a low learning curve and a simple and intuitive user interface, so it is not only a great choice for beginners but also for less experienced teams.
• Finally, a large and active community of users and developers means a lot of online resources and support available.

Disadvantages:

• First of all, it is not designed for applications that require real-time data processing or high availability. And technically- this is not a drawback, but rather something you should be aware of.
• Whatsoever, MySQL is hard to scale and not intended for large amounts of data.
• Lastly, it does not have built-in support for full-text search or geospatial data and some advanced features that are available in other database systems.

As I mentioned above, I will create a separate blog post about the king of the most popular databases. But for now, I can invite you to check out my other how-to guides with MySQL:

• Deploy Kotlin Spring Boot App with MySQL on Kubernetes
• Spring Boot on Google GKE with Cloud SQL and Kotlin

PostgreSQL (aka Postgres)

Nextly, let’s take a look at the second place with a 3% difference- PostgreSQL (also known as Postgres).

It was created in 1986 by a team of researchers at the University of California and is a powerful and open-source object-relational database management system. PostgreSQL is a highly popular and widely used DBMS, known for its flexibility, reliability, and performance.

Advantages:

• Just like MySQL, PostgreSQL is open-source, free to use, and has a large, active community.
• It is highly reliable and performs well even under heavy workloads. This makes it a good choice for applications that require high availability and scalability.
• Moreover, Postgres comes with support for a lot of features and capabilities out of the box. For example triggers, stored procedures, and multi-row transactions.

Disadvantages:

• Firstly, PostgreSQL may not be as widely supported or compatible with technologies, as some other database systems.
• Secondly, it may not be as fast or scalable as other database management systems, such as NoSQL databases. And whereas it works well for large datasets, it is not the speed demon.
• Whatsoever, Postgres is a pretty complex system, so it might be a bit difficult to learn.

And just like previously, please expect new articles to come. But, again, if you would like to learn backend development with Kotlin and Postgres, then I can recommend:

• REST API With Spring WebFlux and Kotlin Course
• other tutorials on how to use it with Spring Boot, or Ktor

SQLite

As the next step, let’s take a while to the no 3 in the most popular databases summary- SQLite.

SQLite is an embedded SQL database engine. The main difference between it and most of SQL databases is that it is self-contained and does not run a separate server process. To put it simply- it’s a library, which reads and writes directly to plain disk files.

It was created in 2000 by Dwayne Richard Hipp using a C programming language and since then, it become the most deployed database engine- used, among others of top web browsers.

Advantages:

• First of all, SQLite is a really lightweight database and it can be successfully used in low-memory environments. With all features enabled, its size can be as little as 750KiB.
• Additionally, the database file format is portable and can be migrated between 32-bit ad 64-bit systems.
• Moreover, SQLite is easy to learn and requires zero configuration, which makes it a great choice for beginners (and not only!)
• Finally, it is really fast and can bring much better performance, than the filesystem.

Disadvantages:

• Firstly- it’s not suitable for client/server applications. Although it can work over the network, the filesystem latency might be an issue.
• Secondly (and lastly), SQLite is not a good choice for high-volume websites or environments demanding high concurrency. Whereas it does not have a limit for concurrent reads, only one writer can write at any instant in time.

MongoDB (aka Mongo)

And the prize for 4th place in our most popular databases ranking goes to MongoDB.

MongoDB is an open-source document-oriented database. It was created in 2009 by MongoDB Inc., which makes it not only the first NoSQL representative in the ranking but also the youngest one (so far). In contrast to previous examples, MongoDB is an example of a NoSQL database, so instead of tables and rows, Mongo stores JSON-like documents, which are organized in collections.

Advantages:

• First of all, Mongo was built with environments demanding high performance and scalability in mind.
• Secondly, it’s flexible. MongoDB does not require you to define a schema for your collections (SQL tables counterparts), which can help you reduce the time spent on schema changes. Moreover, it can be a great choice everywhere, where a schema is hard to define.
• Finally, just like MySQL and Postgres, MongoDB is widely supported and really easy to learn.

Disadvantages:

• No out-of-the-box support for joins. Unlike relational databases, Mongo by design does not support joins between collections, so if you have to work with highly connected data sets, then it might not be the best choice.
• Moreover, MongoDB documents cannot exceed 16MB.
• Lastly, the lack of joins oftentimes leads to data duplication, which may become troublesome to maintain in the future.

If you would like to learn Mongo in practice, then check out my practical guides about MongoDB with Spring Boot, Ktor, and Micronaut.

Microsoft SQL Server

Following, the 5th position on the most popular databases list is taken by Microsoft SQL Server.

It was developed by Microsoft and first released in 1989 and is another relational database in our ranking. Microsoft SQL Server lets us communicate using T-SQL (Transact-SQL), which is an extension of SQL bringing additional features, like functions, or local variables. Whatsoever, it comes with an entire range of products, which we can optionally configure together to make it a really powerful tool.

Advantages:

• Firstly, Microsoft SQL Server has really good support and documentation.
• Additionally, it’s relatively easy to set up and use.
• Whatsoever, SQL Server provides a range of security features to protect against unauthorized access to the data and ensure data integrity.
• Lastly, a strong point is data recovery in case anything happens.

Disadvantages:

• First of all, pricing. And although there is a free option available, Enterprise or Standard editions are pretty expensive.
• Secondly, compatibility. Prior to the SQL Server 2017, it could be run on Windows-based servers, but this is the first version, which can be deployed on Linux.
• Lastly, it may require additional Microsoft software purchases to fully make use of it in your case.

Redis

And the 6th most popular database of 2022 is Redis.

It was created by Salvatore Sanfilippo, also known as antirez, in 2009, which makes it a relatively young database in our summary.

Redis is an open-source, in-memory data structure store that is commonly used as a database, cache, and message broker. It is known for its high performance, flexibility, and scalability, making it a popular choice for a wide range of applications. Whatsoever, it is oftentimes used in conjunction with Microservices and containers, to support the needs of modern, distributed applications.

Advantages:

• As the first one- Redis is an in-memory data store, which results in much higher data processing, than disk-based databases.
• Additionally, it’s highly scalable and can be easily expanded to support the growing needs of our application.
• Lastly, Redis is an open-source project with a large community and a huge amount of online resources to use and learn from. Moreover, it is compatible and pretty easy to use with most of the popular frameworks.

Disadvantages:

• So the first advantage is the disadvantage, as well. The in-memory data store is actually faster, but we have to keep in mind that it is more expensive.
• Moreover, it is a key-value store (like a dictionary), which means that the application(s) connecting to Redis have to be aware of the structure, which requires additional config.
• Lastly, Redis is doing fine when dealing with key-based operations, but is not that efficient, when it comes to searching through the data set.

If you would like to learn more about it in detail, then check out my more detailed article: Redis Database Explained

MariaDB

As the one before last in the most popular databases list, let’s see what exactly MariaDB is.

First of all, MariaDB is a fork of the MySQL DBMS, created by the original developers of MySQL in response to the acquisition of MySQL by Oracle Corporation. The acquisition raised concerns among many users and developers about the future direction of the MySQL project, which resulted in MariaDB being released in 2009.

It’s known for its performance, reliability, and ease of use, and is used by many organizations around the world. Moreover, it is designed to be backward-compatible with MySQL and can be used as a drop-in replacement for it in most cases.

Advantages:

• Firstly, MariaDB is known for its performance and reliability.
• Additionally, it is an open-source project with a large and active community of users and developers. And I know that this argument repeats often in this article. But trust me- a wealth of resources, such as documentation and tutorials, available online comes with plenty of other perks.
• Thirdly, as mentioned above it can be used as a MySQL drop-in replacement in most cases. This allows companies to replace the database without changing the other tools. However, please remember that this is not always the case and sometimes may require additional work.
• And lastly, it is widely supported by various programming languages and frameworks.

Disadvantages:

• As the first one, some of the MySQL Enterprise Edition features are not available out of the box. And although this can be done through plugins, this is an additional, independent tool we have to incorporate.
• Whatsoever, migrating from MySQL may result in additional adjustments and config.
• And as the last thing- the support may be pretty expensive.

Elasticsearch

And finally, we come to the last position in the top 8 most popular databases of 2022- Elasticsearch.

Elasticsearch is an open-source, full-text search and analytics engine created by Shay Banon in 2010.

It is designed to be scalable and flexible, making it a popular choice for building search and data analysis applications. Moreover, it’s based on the Lucene search engine library and provides a RESTful API for interacting with the data. Elasticsearch is known for its powerful search and analytics capabilities, and can be used to search, analyze, and visualize data from a variety of sources, including structured, unstructured, and time-series data.

Advantages:

• Elasticsearch is an open-source project, supported by a large and active community of users.
• Similarly, it’s compatible with plenty of programming languages and frameworks, which helps in its implementation.
• Lastly, it is a highly scalable search and analytics engine, which is intended for fast full-text searches. Thus, it can be a great solution for website searches.

Disadvantages:

• Elasticsearch may not be as fast or efficient as some other search and analytics platforms in certain scenarios- for example, a large amount of data.
• Moreover, it is more difficult to learn compared to similar tools. But this comes with being more powerful, as well.
• Lastly, Elasticsearch should not be used as primary storage.

The Most Popular Databases Summary

And that’s all for this article about the 8 most popular databases. As I already mentioned, this is the initial, bird’s-eye view post and you can expect more detailed articles to come.

Let me know your thoughts in the comments section below!

The post A Quick Intro To The 8 Most Popular Databases appeared first on Codersee blog- Kotlin on the backend.

If you would like to learn:

• what exactly the Micronaut Framework is and what problems can you solve with it?
• how to create REST API using Micronaut and Kotlin programming language?
• how to set up a MongoDB instance with Docker and view the data with MongoDB Compass?
• and furthermore, how to set up all of the above step-by-step?

Then the Micronaut with Kotlin and MongoDB video tutorial will help you with all of the above. 12 free videos with around 56 minutes of the condensed knowledge are a great way to start your journey with the Micronaut framework.

As always, you can find it entirely for free on this blog, by simply clicking the Video Tutorials tab in the header, or by navigating to it with this, direct link.

Alternatively, you can find it on the YouTube platform as a playlist right here, but right there I cannot guarantee that you won’t see the ads, or that everything will be displayed in the correct order.

One more thing…

Finally, I just wanted to thank you for being a part of the Codersee community and ask you about one thing: I would be forever thankful if you share your feedback with me. Of course, regardless of whether you enjoy the course or you think it’s just a piece of s**t. I would love to hear your thoughts and how could I improve my content to better suit your needs. You can do it wherever you want: by using the contact form, using a comments section below, or even on YouTube.

Thank you for your time and have a great week!

The post Micronaut With Kotlin and MongoDB Video Tutorial appeared first on Codersee blog- Kotlin on the backend.

Hello 😀 In this article, I will show you how to implement a Reactive REST API with Micronaut and MongoDB (+ Project Reactor).

Nevertheless, if you are not interested in a reactive approach, and you would like to create a simple REST API, then check out my previous article related to Micronaut and Mongo.

Finally, just wanted to let you know that after this tutorial, you will know precisely:

• how to spin up a MongoDB instance with Docker,
• create a new Micronaut project with all dependencies using the Launch page,
• how to expose REST endpoints,
• and how to validate user input.

2. MongoDB Instance Setup

But before we create our Micronaut project, we need a MongoDB instance up and running on our local machine.

If you don’t have one, you can either install it with the official documentation or simply run the following Docker commands:

docker pull mongo

Then, start a new container named mongodb in a detached mode:

docker run -d -p 27017:27017 --name mongodb mongo

And finally, to validate use the docker ps command:

CONTAINER ID IMAGE COMMAND                CREATED       STATUS       PORTS                    NAMES
ce86244c3fe1 mongo "docker-entrypoint.s…" 5 seconds ago Up 4 seconds 0.0.0.0:27017->27017/tcp mongodb

3. Generate Reactive Micronaut with MongoDB Project

As the next step, let’s navigate to the Micronaut Launch. It is a web application, which allows us to generate new projects from scratch with ease. Of course, we have other possibilities, like Micronaut CLI, or cURL, but for simplicity, let’s go with the web approach:

As we can see, we will be using Micronaut 3.7.1 with Kotlin and JUnit.

Additionally, to set up reactive Micronaut with MongoDB, we will need the following features:

• reactor – adding reactive support using Project Reactor,
• mongo-reactive – bringing support for the MongoDB Reactive Streams Driver,
• data-mongodb-reactive – adding reactive data repositories for MongoDB.

With all of that being selected, let’s click the Generate Project button, download the ZIP file, and import it to our IDE.

4. application.yaml

As the next step after import, let’s make sure that our application.yaml is configured properly:

micronaut:
  application:
    name: mongodbasync
netty:
  default:
    allocator:
      max-order: 3
mongodb.uri: mongodb://${MONGO_HOST:localhost}:${MONGO_PORT:27017}/someDb

Please keep in mind to set the mongodb.uri to match your case.

With the above configuration, Micronaut will try to connect to the instance using localhost:27017 and use the someDb database. It’s worth mentioning here, that we don’t have to create the database manually- it will be created automatically if it does not exist.

5. Create Models and DTOs

Following, let’s add classes responsible for persisting and fetching data from MongoDB.

And as an introduction- in this project, we will expose functionality to manage articles and their authors.

5.1. Add Article Class

Firstly, let’s implement the Article:

@MappedEntity
data class Article(
  @field:Id
  @field:GeneratedValue
  val id: String? = null,
  val title: String,
  val category: ArticleCategory,
  val author: Author
)

As we can clearly see, we must annotate this class with:

• @MappedEntity– a generic annotation used to identify a persistent type. Without it, we would end up with an error: Internal Server Error: Can't find a codec for class com.codersee.model.Article, when adding a repository later.
• @Id – responsible for marking the identifier field. Without this one, on the other hand, the code won’t compile with the following message: Unable to implement Repository method: ArticleRepository.delete(Object entity). Delete all not supported for entities with no ID
• @GeneratedValue – annotating our property as a generated value.

Additionally, we make use of the @field to specify how exactly annotation should be generated in the Java bytecode.

5.2. Implement ArticleCategory

Nextly, let’s add a simple enum called ArticleCategory:

enum class ArticleCategory {
  JAVA, KOTLIN, JAVASCRIPT
}

It’s a simple enum, which will identify categories of our articles.

5.3. Create Author

Following, let’s implement the Author data class:

@Serializable
@Deserializable
data class Author(
  val firstName: String,
  val lastName: String,
  val email: String
)

This time, we have to mark the class with @Serializable and @Deserializable.

And although we don’t have to mark this class as an entity (it’s an inner JSON in the MongoDB document, not a separate one), we have to utilize these two annotations.

Without them, everything will fail with either:

Caused by: io.micronaut.core.beans.exceptions.IntrospectionException: No serializable introspection present for type Author author. Consider adding Serdeable. Serializable annotate to type Author author. Alternatively if you are not in control of the project’s source code, you can use @serdeimport(Author.class) to enable serialization of this type.

or

Caused by: io.micronaut.core.beans.exceptions.IntrospectionException: No deserializable introspection present for type: Author. Consider adding Serdeable.Deserializable annotate to type Author. Alternatively if you are not in control of the project’s source code, you can use @serdeimport(Author.class) to enable deserialization of this type.

5.4. Implement Requests

Finally, let’s implement two DTOs responsible for deserializing JSON payloads sent by the user: ArticleRequest and SearchRequest:

data class ArticleRequest(
  val title: String,
  val category: ArticleCategory,
  val author: Author
)

data class SearchRequest(
  val title: String
)

As we can see, these are just two, plain data classes with no annotations. And as mentioned above, their only responsibility will be to transfer the data deserialized from request bodies.

6. Make Use Of Data Repositories

With that being done, we can add the ArticleRepository to our reactive Micronaut with MongoDB project:

@MongoRepository
interface ArticleRepository : ReactorCrudRepository<Article, String> {

  @MongoFindQuery("{ title: { \$regex: :title, '\$options' : 'i'}}")
  fun findByTitleLikeCaseInsensitive(title: String): Flux<Article>

}

This time, we have to implement the desired repository and annotate the interface with @MongoRepository to make use of the data repositories in Micronaut.

Additionally, we’ve added a custom find query with @MongoFindQuery annotation. This function will be responsible for fetching articles by a given title.

Note: when we check the GenericRepository interface, we will see that we have plenty of possibilities to pick from:

In our case, we will go with the ReactorCrudRepository, which exposes basic CRUD operations with Fluxes and Monos.

7. Add Service Layer

Nextly, let’s implement the ArticleService:

@Singleton
class ArticleService(
  private val articleRepository: ArticleRepository
) {

  fun create(article: Article): Mono<Article> =
    articleRepository.save(article)

  fun findAll(): Flux<Article> =
    articleRepository.findAll()

  fun findById(id: String): Mono<Article> =
    articleRepository.findById(id)
      .switchIfEmpty(
        Mono.error(
          HttpStatusException(HttpStatus.NOT_FOUND, "Article with id: $id does not exists.")
        )
      )

  fun update(id: String, updated: Article): Mono<Article> =
    findById(id)
      .map { foundArticle -> updated.copy(id = foundArticle.id) }
      .flatMap(articleRepository::update)

  fun deleteById(id: String): Mono<Void> =
    findById(id)
      .flatMap(articleRepository::delete)
      .flatMap { deletedCount ->
        if (deletedCount > 0L)
          Mono.empty()
        else
          Mono.error(
            HttpStatusException(HttpStatus.NOT_FOUND, "Article with id: $id was not deleted.")
          )
      }

  fun findByTitleLike(name: String): Flux<Article> =
    articleRepository.findByTitleLikeCaseInsensitive(name)
}

As we can see, a lot is happening here, so let’s take a minute to understand this code snippet.

As the first thing, we mark the service with @Singleton, which means that the injector will instantiate this class only once. Then, we inject a previously created repository to make use of it.

7.1. create(), findAll() and findByTitleLike()

When it comes to these three functions there’s not too much to say about:

fun create(article: Article): Mono<Article> =
  articleRepository.save(article)

fun findAll(): Flux<Article> =
  articleRepository.findAll()

fun findByTitleLike(name: String): Flux<Article> =
  articleRepository.findByTitleLikeCaseInsensitive(name)

As we can clearly see, they are responsible for invoking appropriate functions from our repository and returning either Flux (multiple) or Mono (single) Article(s).

7.2. findById()

Nextly, let’s see the function responsible for fetching articles with their identifiers:

fun findById(id: String): Mono<Article> =
  articleRepository.findById(id)
    .switchIfEmpty(
      Mono.error(
        HttpStatusException(HttpStatus.NOT_FOUND, "Article with id: $id does not exists.")
      )
    )

Right here, we first invoke the findById(id) function from our repository. Then, it the article was found, we simply return the Mono<Article>.

Nevertheless, if the article does not exist in our MongoDB instance, the repository returns an empty Mono. And to handle this case, we use the switchIfEmpty() and translate it to the error Mono.

Finally, to return a meaningful status code and message to the user later, we use the HttpStatusException, which is a dedicated exception for that.

7.3. update()

Following, let’s take a look at the update() implementation:

fun update(id: String, updated: Article): Mono<Article> =
  findById(id)
    .map { foundArticle -> updated.copy(id = foundArticle.id) }
    .flatMap(articleRepository::update)

Right here, we first try to fetch the article by id. If it was found, then we simply copy its identifier to the instance with updated fields called updated.

As the last step, we invoke the update method from our repository using the function reference.

Note:  Function reference is a great syntatic sugar here and is an equivalent of: .flatMap{ articleRepository.update(it) } , or .flatMap{ updated -> articleRepository.update(updated) }.

7.4. deleteById()

Lastly, let’s check the delete functionality:

fun deleteById(id: String): Mono<Void> =
  findById(id)
    .flatMap(articleRepository::delete)
    .flatMap { deletedCount ->
      if (deletedCount > 0L)
        Mono.empty()
      else
        Mono.error(
          HttpStatusException(HttpStatus.NOT_FOUND, "Article with id: $id was not deleted.")
        )
    }

Similarly, we first try to find the article by id, and on success, we invoke the delete function from our repository.

As a result, we get a Long value indicating the number of affected (here- deleted) documents. So if this value is greater than 0, we simply return an empty Mono. Otherwise, we return an error Mono with HttpStatusException.

8. Controller For Reactive Micronaut with MongoDB

With all of that being done, let’s add the ArticleController class:

@Controller("/articles")
@ExecuteOn(TaskExecutors.IO)
class ArticleController(
  private val articleService: ArticleService
) {

  @Get
  fun findAll(): Flux<Article> =
    articleService.findAll()

  @Get("/{id}")
  fun findById(@PathVariable id: String): Mono<Article> =
    articleService.findById(id)

  @Post
  @Status(CREATED)
  fun create(@Body request: ArticleRequest): Mono<Article> =
    articleService.create(
      article = request.toArticle()
    )

  @Post("/search")
  fun search(@Body searchRequest: SearchRequest): Flux<Article> =
    articleService.findByTitleLike(
      name = searchRequest.title
    )

  @Put("/{id}")
  fun updateById(
    @PathVariable id: String,
    @Body request: ArticleRequest
  ): Mono<Article> =
    articleService.update(id, request.toArticle())

  @Delete("/{id}")
  @Status(NO_CONTENT)
  fun deleteById(@PathVariable id: String) =
    articleService.deleteById(id)

  private fun ArticleRequest.toArticle(): Article =
    Article(
      id = null,
      title = this.title,
      category = this.category,
      author = this.author
    )
}

As we can clearly see, we have to mark our controller class with the @Controller annotation and specify the base URI – /articles in our case.

Moreover, we make use of the @ExecuteOn(TaskExecutors.IO) to indicate which executor service a particular task should run on.

When it comes to particular functions, each one is responsible for handling different requests. Depending on which HTTP method should they respond to, we mark them with meaningful annotation: @Get, @Post, @Put, or @Delete. These annotations let us narrow down the URI route, like /search, or /{id}.

Additionally, we access path variables and request bodies with @PathVariable and @Body annotations (and DTOs implemented in paragraph 3), and set custom response codes with @Status. And of course, we have to remember that the status code can be changed with HttpStatusException in the service layer, as well.

9. Validation

At this point, our reactive Micronaut application can be run and we would be able to test the endpoints.

Nevertheless, before we do so, let’s add one more, crucial functionality: user input validation. In the following example, I will show you just a couple of possible validations, but please keep in mind that there are way more possibilities, which I encourage you to check out.

9.1. Edit Controller

As the first step, let’s make a few adjustments to the previously created controller:

// Make class open
open class ArticleController

// Add @Valid annotation and make functions open, as well
open fun create(@Valid @Body request: ArticleRequest): Mono<Article>

open fun search(@Valid @Body searchRequest: SearchRequest): Flux<Article>

open fun updateById(@PathVariable id: String, @Valid @Body request: ArticleRequest): Mono<Article>

As we can clearly see, to trigger the validation process for particular request bodies, we have to add the @Valid annotation.

Moreover, functions with validation must be marked as open. Without that, our Micronaut app won’t compile with the following error:

Method defines AOP advice but is declared final. Change the method to be non-final in order for AOP advice to be applied.

9.2. Change DTOs

Nextly, let’s make a couple of changes to the ArticleRequest, SearchRequest, and Author classes:

@Serializable
@Deserializable
data class Author(
  @field:NotBlank
  @field:Size(max = 50)
  val firstName: String,

  @field:NotBlank
  @field:Size(max = 50)
  val lastName: String,

  @field:Size(max = 50)
  @field:Email
  val email: String
)

@Introspected
data class ArticleRequest(
  @field:NotBlank val title: String,
  val category: ArticleCategory,
  @field:Valid val author: Author
)

@Introspected
data class SearchRequest(
  @field:NotBlank
  @field:Size(max = 50)
  val title: String
)

Firstly, we have to mark fields intended for validation with appropriate annotations, like @NotBlank, @Size, etc. These annotations are a part of the javax.validation.constraints package, which you might already know, for example from Spring Boot.

It’s worth mentioning two additional things we can see above: @Introspected and a @Valid annotation applied to the author.

With the first one, we state that the type should produce an io.micronaut.core.beans.BeanIntrospection at compilation time. Without it, Mirconaut won’t be able to process our annotations and all requests will fail at the runtime with the example message:

10. Testing

As the last step, we can finally run our reactive Micronaut application and check out if everything is working as expected with our MongoDB instance.

10.1. Create a New Article

Let’s start with creating a new Article:

curl --location --request POST 'http://localhost:8080/articles' \
  --header 'Content-Type: application/json' \
  --data-raw '{
    "title": "Title 1",
    "category": "JAVA",
      "author": {
        "firstName": "First Name 1",
        "lastName": "Last Name 1",
        "email": "one@gmail.com"
      }
  }'

# Result when successful: 
Status Code: 201 Created
Response Body: 
{
  "id": "634f9e825b223f0572585007",
  "title": "Title 1",
  "category": "JAVA",
  "author":
    {
      "firstName": "First Name 1",
      "lastName": "Last Name 1",
      "email": "one@gmail.com"
    }
}

# Response when validations failed: 
Status: 400 Bad Request
Response Body:
{
  "message": "Bad Request",
  "_embedded": {
  "errors": [
    {
      "message": "request.author.email: must be a well-formed email address"
    },
    {
      "message": "request.author.firstName: must not be blank"
    },
    {
      "message": "request.author.lastName: size must be between 0 and 50"
    },
    {
      "message": "request.title: must not be blank"
    }
  ]
},
  "_links": {
    "self": {
      "href": "/articles",
      "templated": false
    }
  }
}

As can be seen, everything is working correctly and validation works for both article and author payload.

10.2. List All Articles

Nextly, let’s list all articles:

curl --location --request GET 'http://localhost:8080/articles'

# Response:
Status Code: 200 OK 
Example response body: 
[
  {
    "id": "634f9fff5b223f0572585008",
    "title": "Title 1",
    "category": "JAVA",
    "author": {
      "firstName": "First Name 1",
      "lastName": "Last Name 1",
      "email": "one@gmail.com"
    }
  }
]

Everything is fine in this case.

10.3. GET Article By Id

Following, let’s get the details of the article by ID:

curl --location --request GET 'http://localhost:8080/articles/634fa0f05b223f057258500a'

# Response:
Status Code: 200 OK 
Example response body when found: 
{
  "id": "634fa0f05b223f057258500a",
  "title": "Another 2",
  "category": "JAVA",
  "author": {
    "firstName": "First Name 1",
    "lastName": "Last Name 1",
    "email": "one@gmail.com"
  }
}

# Response when article not found:
{
  "message": "Not Found",
  "_embedded": {
    "errors": [
      {
        "message": "Article with id: 634fa0f05b223f057258500b does not exists."
      }
    ]
  },
  "_links": {
    "self": {
      "href": "/articles/634fa0f05b223f057258500b",
      "templated": false
    }
  }
}

Similarly, works flawlessly for both cases.

10.4. Homework

The rest of the endpoints will be your homework and I highly encourage you to check them all.

Below, you can find the remaining cURLs, which can be used for testing:

# Update endpoint:
curl --location --request PUT 'http://localhost:8080/articles/634fa0f05b223f057258500a' \
  --header 'Content-Type: application/json' \
  --data-raw '{
    "title": "Changed Title",
    "category": "JAVASCRIPT",
    "author": {
      "firstName": "First Name 4",
      "lastName": "Last Name 4",
      "email": "two@gmail.com"
    }
  }'

# Search endpoint:
curl --location --request POST 'http://localhost:8080/articles/search' \
  --header 'Content-Type: application/json' \
  --data-raw '{
    "title": "1"
  }'

# Delete endpoint:
curl --location --request DELETE 'http://localhost:8080/articles/634cf9d458a6a33cdd19fdab'

10. Reactive Micronaut with MongoDB Summary

And that would be all for this article on how to expose REST API using Reactive Micronaut with MongoDB.

As always, you can find the whole source code in this GitHub repository.

If you find this material helpful (or not) or would like to ask me about anything, please leave a comment in the section below. I always highly appreciate your feedback and I am happy to chat with you 😀

Take care and have a great week!

The post Reactive REST API with Micronaut and MongoDB appeared first on Codersee blog- Kotlin on the backend.

Hi folks! In this step-by-step guide, I will show you how to create a REST API using Micronaut with MongoDB and Kotlin.

As you might have noticed, this article is a revisited version of another blog post, which I created a long time ago. And before we start I would like to commend for upgrade suggestions made via software development work from Software Prophets. Without Eric’s comments, involvement and feedback, this article would never have been written. Thanks! 😀

Finally, I just wanted to admit that after this blog post, you will know precisely:

• how to spin up a MongoDB instance with Docker,
• how to generate a new Micronaut project and add dependencies (like MongoDB) with ease,
• how to persist and read data with MongoClient and data repositories for MongoDB,
• how to expose REST endpoints.

2. New Micronaut with MongoDB and Kotlin Project

As the first step, let’s generate a new Micronaut project with MongoDB dependencies. We can do it in three ways:

• using Micronaut CLI,
• with cURL,
• or with the Micronaut Launch page.

And although the CLI is a preferred way to generate new projects, for simplicity, let’s have a look at how to do it with the Launch page:

As we can see, this website provides us with a clickable interface, where we can specify what exactly should our project consist of.

To be on the same page and make sure that everything works, as expected, let’s have a look at the options I’ve chosen:

• Application Type: Micronaut Application
• Micronaut Version: 3.7.1
• Java Version: 17
• Language: Kotlin
• Name: rest-mongodb (feel free to specify your own right here)
• Build Tool: Gradle Kotlin
• Base Package: com.codersee (similarly, you can pick whatever you want)
• Test Framework: JUnit
• Features: data-mongodb, mongo-sync (these two are important!)

With all of that being selected, let’s click the Generate Project button, download the Zip package, and open up the project with our favorite IDE (IntelliJ in my case).

3. Run MongoDB With Docker

Nextly, let’s set up a new MongoDB instance, which we will use to connect to it later. I’ll do it with Docker, but if you would like to install it on your local machine, you can find more information on this, official MongoDB page.
 

 
So, firstly, let’s pull the Mongo image:

docker pull mongo

As the next step, let’s start a new container named mongodb in a detached mode:

docker run -d -p 27017:27017 --name mongodb mongo

As we can see, additionally we have to expose the container’s port 27017 to some port of our local machine (and I used the exact same port to make everything simpler).

To validate, we can use the docker ps command:

CONTAINER ID IMAGE COMMAND                CREATED       STATUS       PORTS                    NAMES
ce86244c3fe1 mongo "docker-entrypoint.s…" 5 seconds ago Up 4 seconds 0.0.0.0:27017->27017/tcp mongodb

The above output indicates that our container is up and running and that the ports are mapped correctly.

4. Edit application.yaml File

After that is done, let’s get back to our project and edit the mongodb.uri property:

mongodb.uri: mongodb://localhost:27017/example

As we can see, apart from pointing to the desired host and location, we specify the database name we would like to use- example in our case.

5. Create Model Classes

As the next step, let’s implement two classes we will use in our Micronaut app to exchange data with MongoDB:

• AppUser– which will be responsible for transferring the data, like first and last name, email, and address of the application user,
• Address– which will be the inner class responsible for keeping user address information.

Let’s start with the second one, the Address class:

@Serializable
@Deserializable
data class Address(
  val street: String,
  val city: String,
  val code: Int
)

As we can see, in order to work with MongoDB, we have to mark our data class with @Serializable and @Deserializable annotations. No other annotation is necessary here as this class will not be mapped to any collection.

Additionally, the Micronaut creators deserve recognition here, because even if we forget to do so, we will see an exception with a meaningful message, like:

No serializable introspection present for type Address address. Consider adding Serdeable. Serializable annotate to type Address address. Alternatively if you are not in control of the project’s source code, you can use @SerdeImport(Address.class) to enable serialization of this type.

Or:

No deserializable introspection present for type: Address. Consider adding Serdeable.Deserializable annotate to type Address. Alternatively if you are not in control of the project’s source code, you can use @SerdeImport(Address.class) to enable deserialization of this type.

After that, let’s add the AppUser data class:

@MappedEntity
data class AppUser(
  @field:Id
  @field:GeneratedValue
  val id: String? = null,
  val firstName: String,
  val lastName: String,
  val email: String,
  val address: Address
)

This class, apart from the standard fields, has 4 features that are worth paying attention to:

• @MappedEntity – an annotation used to mark a class as being persisted.
• @field:Id – simply the @Id annotation applied to the backing field of Kotlin property. With this one, we designate that this field is the ID of an entity.
• @field:GeneratedValue– similarly, the @GeneratedValue annotation indicates that the property will have a generated value.
• val id: String? = null–  a nullable id property, with a null set by default. Thanks to that, the ID will be generated automatically.

6. Create DTOs

As the next step, let’s add DTOs to our Micronaut project.

Firstly, let’s implement the AppUserRequest:

data class AppUserRequest(
  val firstName: String,
  val lastName: String,
  val email: String,
  val street: String,
  val city: String,
  val code: Int
)

This class will be used to create and update users later.

Moreover, let’s add the SearchRequest:

data class SearchRequest(val name: String)

This one will be used later in search requests.

7. Micronaut With MongoDB and Data Repositories

As I mentioned in the introduction, in this Micronaut with MongoDB and Kotlin tutorial I would like to show you two different approaches on how to persist and fetch the data.

And in this paragraph, we’ll take a look at the synchronous data repositories for MongoDB.

7.1. Implement AppUserRepository

As the first step, let’s add the AppUserRepository interface:

@MongoRepository
interface AppUserRepository : CrudRepository<AppUser, String> 

As we can see, to make it a valid repository in terms of Micronaut, we have to mark our interface with the @MongoRepository annotation.

Additionally, we extend the generic CrudRepository providing the AppUser as the entity type and String as the ID type. As the name suggests, this repository let’s us perform CRUD operations, like save, update all, find, etc…

7.2. Make Use Of Finder Methods

Nextly, let’s make use of the finder methods feature. To put it simply, a finder method name will be translated to a valid query based on its name.

Let’s add the example definition to our interface:

fun findByFirstNameEquals(firstName: String): List<AppUser>

As the name suggests, when using this function all users with a first name equal to the passed argument will be returned. If you would like to learn a bit more about this functionality, then please check out this link to the documentation.

7.3. Custom Query With @MongoFindQuery

As the next step, let’s create a custom query with @MongoFindQuery annotation:

@MongoFindQuery("{ firstName: { \$regex: :name}}")
fun findByFirstNameLike(name: String): List<AppUser>

This time, the users will be returned if their first name contains a given String value. It’s worth mentioning that this annotation lets us specify additional sorting, filtering, or custom fields projections, as well.

Of course, find is not the only supported operation and we can make use of other annotations to specify update, delete, or aggregate queries:

• @MongoUpdateQuery
• @MongoDeleteQuery
• @MongoAggregateQuery

7.4. Create AppUserService

With all of the above being done, we have everything to implement the AppUserService:

@Singleton
class AppUserService(
  private val appUserRepository: AppUserRepository
) {

  fun create(userRequest: AppUserRequest): AppUser =
    appUserRepository.save(
      userRequest.toAppUserEntity()
    )

  fun findAll(): List<AppUser> =
    appUserRepository
      .findAll()
      .toList()

  fun findById(id: String): AppUser =
    appUserRepository.findById(id)
      .orElseThrow { HttpStatusException(HttpStatus.NOT_FOUND, "User with id: $id was not found.") }

  fun update(id: String, updateRequest: AppUserRequest): AppUser {
    val foundUser = findById(id)

    val updatedEntity =
      updateRequest
        .toAppUserEntity()
        .copy(id = foundUser.id)

    return appUserRepository.update(updatedEntity)
  }

  fun deleteById(id: String) {
    val foundUser = findById(id)

    appUserRepository.delete(foundUser)
  }

  fun findByNameLike(name: String): List<AppUser> =
    appUserRepository
      .findByFirstNameLike(name)

  private fun AppUserRequest.toAppUserEntity(): AppUser {
    val address = Address(
      street = this.street,
      city = this.city,
      code = this.code
    )

    return AppUser(
      id = null,
      firstName = this.firstName,
      lastName = this.lastName,
      email = this.email,
      address = address
    )
  }
}

As can be seen, we mark our service with a @Singleton annotation to indicate that it should be instantiated only once.

Let’s have a few words about each function:

• create(userRequest: AppUserRequest)– this one takes the AppUserRequest instance as an argument and invokes the toAppUserEntity() extension function returning a new AppUser instance. With this instance, we invoke the save() method returning the newly created object.
• findAll()– this function invokes the findAll() method from CrudRepository and converts returned Iterable to list.
• findById(id: String)– this one is a bit more interesting. Firstly, we invoke the findById() method returning an Optional of the AppUser. If it’s empty, we throw the HttpStatusException. In Micronaut, this class can be used to throw exceptions returning the desired status code and message. And that’s what we do here- as a result, the 400 Bad Request informing that the user with the given id was not found is returned.
• update(id: String, updateRequest: AppUserRequest)– as we can see, this one takes the desired id and an update request as the arguments. Firstly, we make use of already implemented findById() to fetch the desired user thus making sure he exists. Then, we simply convert our request to a new entity, but compared to the create(), have to set the id. Finally, we invoke the update() returning an updated user instance
• deleteById(id: String)– with this one we first make sure that the user exists and then, we invoke the delete() method of our repository.
• findByNameLike(name: String)– finally, this one is responsible for passing the name argument to our custom function: findByFirstNameLike(name).

8. Add Controller

As the last thing before we will be able to test our Micronaut with MongoDB and Kotlin application, let’s implement the AppUserController:

@Controller("/users")
@ExecuteOn(TaskExecutors.IO)
class AppUserController(
    private val appUserService: AppUserService
) {

    @Get
    fun findAllUsers(): List<AppUser> =
        appUserService.findAll()

    @Get("/{id}")
    fun findById(@PathVariable id: String): AppUser =
        appUserService.findById(id)

    @Post
    @Status(CREATED)
    fun createUser(@Body request: AppUserRequest): AppUser =
        appUserService.create(request)

    @Post("/search")
    fun searchUsers(@Body searchRequest: SearchRequest): List<AppUser> =
        appUserService.findByNameLike(
            name = searchRequest.name
        )

    @Put("/{id}")
    fun updateById(
        @PathVariable id: String,
        @Body request: AppUserRequest
    ): AppUser =
        appUserService.update(id, request)

    @Delete("/{id}")
    @Status(NO_CONTENT)
    fun deleteById(@PathVariable id: String) =
        appUserService.deleteById(id)
}

This time, everything starts with the @Controller annotation, where we put the base URI for this controller- “/users” in our case. As the name suggests, this annotation simply indicates that this class is a controller in our application.

Then, we specify the @ExecuteOn used to indicate which executor service use to run a particular task. In our case, we make use of the IO scheduler used to schedule I/O tasks (Thank you Captain Obvious 🙂 ) .

When it comes to the functions, we use the @Get, @Post, @Put, and @Delete annotations to specify what HTTP Methods they should handle and additional routes, like “/users/search”.  To bind a parameter from a path variable, we make use of the @PathVariable and @Body to do the same with a request body.

Finally, the @Status annotation is really useful to set the desired response code.

9. Testing

Let’s start by creating a new user with a POST request (and I highly recommend creating a few different users to better see if everything works, as expected):

curl --location --request POST 'localhost:8080/users' \
--header 'Content-Type: application/json' \
--data-raw '{
    "firstName": "Piotr",
    "lastName": "Wolak",
    "email": "contact@codersee.com",
    "street": "Some Street",
    "city": "Some city",
    "code": 1
}'

# Response: 
{
    "id": "633c6fb788e9024f42951f18",
    "firstName": "Piotr",
    "lastName": "Wolak",
    "email": "contact@codersee.com",
    "address": {
        "street": "Some Street",
        "city": "Some city",
        "code": 1
    }
}

Secondly, let’s perform a GET request to see the list of all users:

curl --location --request GET 'localhost:8080/users/'

# Example Response: 
[
    {
        "id": "633c6fb788e9024f42951f18",
        "firstName": "Piotr",
        "lastName": "Wolak",
        "email": "contact@codersee.com",
        "address": {
            "street": "Some Street",
            "city": "Some city",
            "code": 1
        }
    }
]

Thirdly, let’s check if querying by ID works as expected in both cases:

curl --location --request GET 'localhost:8080/users/633c6fb788e9024f42951f18'

# User found:
{
    "id": "633c6fb788e9024f42951f18",
    "firstName": "Piotr",
    "lastName": "Wolak",
    "email": "contact@codersee.com",
    "address": {
        "street": "Some Street",
        "city": "Some city",
        "code": 1
    }
}

# User not found:
# Status: 404 Not Found
# Response body:
{
    "message": "Not Found",
    "_embedded": {
        "errors": [
            {
                "message": "User with id: 633c6fb788e9024f42951f19 was not found."
            }
        ]
    },
    "_links": {
        "self": {
            "href": "/users/633c6fb788e9024f42951f19",
            "templated": false
        }
    }
}

Following, let’s perform an update:

curl --location --request PUT 'localhost:8080/users/633c6fb788e9024f42951f18' \
--header 'Content-Type: application/json' \
--data-raw '{
    "firstName": "John",
    "lastName": "Doe",
    "email": "contact@codersee.com",
    "street": "Another Street",
    "city": "Another City",
    "code": 2
}'

# Response:
{
    "id": "633c6fb788e9024f42951f18",
    "firstName": "John",
    "lastName": "Doe",
    "email": "contact@codersee.com",
    "address": {
        "street": "Another Street",
        "city": "Another City",
        "code": 2
    }
}

# To verify, we can perform a GET request once again.

Before we check the DELETE endpoint, let’s make an example search query:

curl --location --request POST 'localhost:8080/users/search' \
--header 'Content-Type: application/json' \
--data-raw '{
"name": "Joh"
}
'

# Result: 
[
    {
        "id": "633c6fb788e9024f42951f18",
        "firstName": "John",
        "lastName": "Doe",
        "email": "contact@codersee.com",
        "address": {
            "street": "Another Street",
            "city": "Another City",
            "code": 2
        }
    }
]

Finally, let’s delete the user:

curl --location --request DELETE 'localhost:8080/users/633c6fb788e9024f42951f18'

# Response:
# Status 204 No Content
# Response Body: empty

# If we repeat the request we should get: 
{
    "message": "Not Found",
    "_embedded": {
        "errors": [
            {
                "message": "User with id: 633c6fb788e9024f42951f18 was not found."
            }
        ]
    },
    "_links": {
        "self": {
            "href": "/users/633c6fb788e9024f42951f18",
            "templated": false
        }
    }
}

As we can clearly see, everything is working, as expected.

10. Micronaut With MongoDB and MongoClient

Ok, so for now we’ve learned how to use Micronaut with MongoDB and Kotlin and data repositories for MongoDB.

Before we end this article, I would like to show you one more way to interact with a Mongo database- the MongoClient. According to the documentation, MongoClient is:

A client-side representation of a MongoDB cluster. Instances can represent either a standalone MongoDB instance, a replica set, or a sharded cluster. Instance of this class are responsible for maintaining an up-to-date state of the cluster, and possibly cache resources related to this, including background threads for monitoring, and connection pools.

Simply put- this class lets us operate on a MongoDB cluster. In our case, we will use it to perform operations on the example database and app_user collection.

11. Add AppUserWithMongoClientService

Although you probably don’t want to name classes in your project this way, I’d like to distinguish somehow between these two approaches 😀

With that being said, let’s implement the AppUserWithMongoClientService:

@Singleton
class AppUserWithMongoClientService(
    private val mongoClient: MongoClient
) {

    fun create(userRequest: AppUserRequest): BsonValue {
        val createResult = getCollection()
            .insertOne(userRequest.toAppUserEntity())

        return createResult.insertedId
            ?: throw HttpStatusException(HttpStatus.BAD_REQUEST, "User was not created.")
    }

    fun findAll(): List<AppUser> =
        getCollection()
            .find()
            .toList()

    fun findById(id: String): AppUser =
        getCollection()
            .find(
                Filters.eq("_id", ObjectId(id))
            )
            .toList()
            .firstOrNull()
            ?: throw HttpStatusException(HttpStatus.NOT_FOUND, "User with id: $id was not found.")

    fun update(id: String, updateRequest: AppUserRequest): AppUser {
        val updateResult = getCollection()
            .replaceOne(
                Filters.eq("_id", ObjectId(id)),
                updateRequest.toAppUserEntity()
            )

        if (updateResult.modifiedCount == 0L)
            throw HttpStatusException(HttpStatus.BAD_REQUEST, "User with id: $id was not updated.")

        return findById(id)
    }

    fun deleteById(id: String) {
        val deleteResult = getCollection()
            .deleteOne(
                Filters.eq("_id", ObjectId(id))
            )

        if (deleteResult.deletedCount == 0L)
            throw HttpStatusException(HttpStatus.BAD_REQUEST, "User with id: $id was not deleted.")
    }

    fun findByNameLike(name: String): List<AppUser> =
        getCollection()
            .find(
                Filters.regex("firstName", name)
            )
            .toList()


    private fun getCollection(): MongoCollection =
        mongoClient
            .getDatabase("example")
            .getCollection("app_user", AppUser::class.java)

    private fun AppUserRequest.toAppUserEntity(): AppUser {
        val address = Address(
            street = this.street,
            city = this.city,
            code = this.code
        )

        return AppUser(
            id = null,
            firstName = this.firstName,
            lastName = this.lastName,
            email = this.email,
            address = address
        )
    }

}

Just like previously, we can see that we annotated the class as a @Singleton and reuse the toAppUserEntity() extension function.

As you might have noticed, this time we added the getCollection() function responsible for getting a MongoCollection<AppUser> instances. This class lets us utilize methods, like find(), insertOne(), or deleteOne().

Moreover, in every function except the create() we make use of the Filters class, which is basically a factor for query filters.

12. Implement AppUserWithMongoClientService

And the last thing we will have to do in our Micronaut with MongoDB and Kotlin application is to add the AppUserWithMongoClientController:

@Controller("/users-client")
@ExecuteOn(TaskExecutors.IO)
class AppUserWithMongoClientController(
  private val appUserWithMongoClientService: AppUserWithMongoClientService
) {

  @Get
  fun findAllUsers(): List<AppUser> =
    appUserWithMongoClientService.findAll()

  @Get("/{id}")
  fun findById(@PathVariable id: String): AppUser =
    appUserWithMongoClientService.findById(id)

  @Post
  @Status(CREATED)
  fun createUser(@Body request: AppUserRequest): HttpResponse<Void> {
    val createdId = appUserWithMongoClientService.create(request)

    return HttpResponse.created(
      URI.create(
        createdId.asObjectId().value.toHexString()
      )
    )
  }

  @Post("/search")
  @Status(CREATED)
  fun searchUser(@Body searchRequest: SearchRequest): List<AppUser> =
    appUserWithMongoClientService.findByNameLike(
      name = searchRequest.name
    )

  @Put("/{id}")
  fun updateById(
    @PathVariable id: String,
    @Body request: AppUserRequest
  ): AppUser =
    appUserWithMongoClientService.update(id, request)

  @Delete("/{id}")
  @Status(NO_CONTENT)
  fun deleteById(@PathVariable id: String) =
    appUserWithMongoClientService.deleteById(id)

}

As we can see, this implementation is almost identical compared to the previous controller. Worth noting are two things:

• to avoid URI conflicts, this one responds to the /users-client,
• the createUser functionality works a bit differently- instead of returning the created entity, we make use of the 201 Created status code and pass the id of the created object as the location header. That wasn’t necessary, but I wanted to show you another approach, as well 😀

13. Test Additional Endpoints

Finally, we can test our new endpoints and make sure everything runs smoothly.

Nevertheless, I will not duplicate paragraph 10 right here, so this one will be your homework. There are two differences you have to remember about when testing this new controller, but if you’ve read the article thoroughly, I am pretty sure you will know exactly what I’m talking about.

14. Micronaut with MongoDB and Kotlin Revisited Summary

And that would be all for this article about Micronaut with MongoDB and Kotlin. If you’d like to see the whole source code, then please visit this GitHub repository.

Let me know if this article was useful for you in the comment section (or through the contact form– if that suits you best). Of course, if you feel this post is a total crap and do not recommend it- please leave a comment, as well- always happy to chat and open for criticism 🙂

Have a great day!

The post Micronaut with MongoDB and Kotlin Revisited [2022] appeared first on Codersee blog- Kotlin on the backend.

In this step-by-step guide, I would like to show you how to implement a REST API using Ktor, MongoDB, and KMongo.

If you haven’t heard about KMongo yet- it is a lightweight Kotlin toolkit for Mongo. Internally, it uses the core MongoDB Java Driver and exposes its features via Kotlin extensions. With this combination, we are sure that we’re using the recommended Java Driver, and additionally, we take advantage of the Kotlin less-verbose syntax.

In the end, I would like to add one more note. In this article, I will show you how to create MongoDB as a Docker container. If you have MongoDB already installed on your local machine, then you can just skip this part. Otherwise, please make sure that you have configured Docker properly in your local environment.

2. Generate Project

With that being said, let’s head to the Ktor Project Generator page and make a few adjustments.

Alternatively, you can generate the project within the app if you use IntelliJ IDEA Ultimate Edition

2.1. Adjust Ktor Settings

As the first step, let’s make sure that we set correctly the required properties:

Basically, the Project Name, Website, and Artifact are irrelevant and you can adjust it as you want. Nevertheless, to make sure that everything will be working as intended, please make sure to select the same Ktor version on this page.

2.2. Add Ktor Plugins

Nextly, let’s click the Plugins button, and add kotlinx.serialization to our project:

As we can see, two more plugins have been automatically: ContentNegotiation and Routing:

Unfortunately, we don’t have the possibility to add any dependencies required to work with MongoDB and Ktor, so for now, let’s click Generate Project button and import it to our IDE.

[elementor-template id=”9007393″]

3. Add KMongo Dependency

After we import the project, let’s head to the gradle.properties file and specify the version of KMongo we’d like to use:

kmongo_version=4.5.0

Following, let’s open the build.gradle.kts file and put the following lines:

val kmongo_version: String by project

// Inside the dependencies
implementation("org.litote.kmongo:kmongo:$kmongo_version")

4. Setup MongoDB Container

With all of the above being done, let’s prepare a MongoDB instance with Docker. Let’s open up the terminal and specify the following command:

docker run --name my_mongodb_cotainer -d -p 27017:27017 mongo:5.0.6

Basically, this with this one-liner we perform a few actions:

• with –name [name] we assign our custom name to the container. Otherwise, a random one will be generated
• -d, which is a shortcut for –detach, runs the container in the background and prints the container ID
• with -p host_port:container_port, we simply publish the 27017 port of the local machine to the same port of Mongo. In simple words, it is necessary to connect using localhost:27017 address
• in the end, we specify the image we would like to use- 5.0.6 in our case

To validate if everything is running as expected, let’s run the docker ps command and check the output:

docker run --name my_mongodb_cotainer -d -p 27017:27017 mongo:5.0.6
CONTAINER ID  IMAGE        COMMAND                 CREATED         STATUS         PORTS                     NAMES
3b4369dd37c6  mongo:5.0.6  "docker-entrypoint.s…"  11 minutes ago  Up 11 minutes  0.0.0.0:27017->27017/tcp  my_mongodb_cotainer

5. Ktor Configuration

If we made sure that the MongoDB instance is running, we can get back to our Ktor project and take a look at the configuration.

At this point, our project should consist of three files generated automatically: Application.kt, along with Routing.kt and Serialization.kt inside the plugins package. Please make sure that they are looking, as follows:

// Application.kt file:
fun main() {
  embeddedServer(Netty, port = 8080, host = "0.0.0.0") {
    configureRouting()
    configureSerialization()
  }.start(wait = true)
}

// Routing.kt file:
fun Application.configureRouting() {
  routing {
  }
}

// Serialization.kt file:
fun Application.configureSerialization() {
  install(ContentNegotiation) {
    json()
  }
}

To put it simply, these three files are responsible for setting up our server to respond on localhost:8080 and use kotlinx.serialization. Additionally, the Routing.kt is a skeleton, which we will use later to expose our endpoints.

6. Prepare Object Mapping

As the next step, let’s create a Person class:

data class Person(
  @BsonId
  val id: Id<Person>? = null,
  val name: String,
  val age: Int
)

As you can see, this simple class except for standard fields consists of the nullable id field annotated with @BsonId. Moreover, we need to use a parametrized Id<T> interface in order to let KMongo know that the Person class is the owner of the given ID. By making this field explicitly null, the id will be generated automatically, so that we won’t have to pass it explicitly on creation.

7. Add PersonDto

Following, let’s add a PersonDto to our project:

@Serializable
data class PersonDto(
  val id: String? = null,
  val name: String,
  val age: Int
)

Although it’s not necessary, this way we will separate objects used to communicate between client and our Ktor app from the ones used to communicate with MongoDB.

Additionally, let’s create a PersonExtension.kt file with two extension functions:

fun Person.toDto(): PersonDto =
  PersonDto(
    id = this.id.toString(),
    name = this.name,
    age = this.age
  )

fun PersonDto.toPerson(): Person =
  Person(
    name = this.name,
    age = this.age
  )

These helper functions will serve us as mappers later in the code.

8. Implement Error Response

As the last step of preparation, let’s create the ErrorResponse class:

@Serializable
data class ErrorResponse(val message: String) {
  companion object {
    val NOT_FOUND_RESPONSE = ErrorResponse("Person was not found")
    val BAD_REQUEST_RESPONSE = ErrorResponse("Invalid request")
  }
}

Again, this is not necessary but will be helpful when informing clients about errors.

9. Establish MongoDB Connection

With all the above being done, let’s create a PersonService:

class PersonService {

  private val client = KMongo.createClient()
  private val database = client.getDatabase("person")
  private val personCollection = database.getCollection<Person>()

}

Let’s have a look at each of the above lines:

• line 3- creates a Mongo instance using localhost and the default port (27017). If we would like to change connection details, then we can pass it as String, or ConnectionString to its overloaded versions
• line 4- obtains a Databse instance by the given name. If it does not exist, it will be created during the first insert
• line 5- gets a Collection (a Table in Mongo terminology). We will use this object to perform all operations

10. Insert Document To MongoDB

Following, let’s get to the heart of this tutorial- Ktor and MongoDB integration.

10.1. Add Create Function To Service

Let’s start by adding the create() function inside the PersonService:

fun create(person: Person): Id<Person>? {
  personCollection.insertOne(person)
  return person.id
}

As we can see, we use an already obtained MongoCollection instance to insert a provided Person object. If it is persisted successfully, then the ID will be updated with the value from the database, so that we can return it.

10.2. Expose POST Endpoint

As the next step, let’s head to the Routing.kt and insert the following lines:

val service = PersonService()

routing {
  route("/person") {
    post {
      val request = call.receive<PersonDto>()
      val person = request.toPerson()

      service.create(person)
        ?.let { userId ->
          call.response.headers.append("My-User-Id-Header", userId.toString())
          call.respond(HttpStatusCode.Created)
        } ?: call.respond(HttpStatusCode.BadRequest, ErrorResponse.BAD_REQUEST_RESPONSE)
    }
  }
}

Basically, the above logic is pretty straightforward. In the beginning, we obtain the JSON content of the request, which is deserialized to PersonDto instance. Then, we use our extension function to convert it to the Person class. If the document is persisted successfully, we simply return its id to the client setting the My-User-Id-Header and 201 Created status code. On the other hand, if the id is null, we then return an error response along with 400 Bad Request status.

10.3. Test POST Endpoint

Nextly, let’s run our application and perform a POST request:

POST http://localhost:8080/person

Payload:
{
  "name": "Piotr",
  "age": 55
}

Response Status: 
201 Created

Response Headers:
My-User-Id-Header: 6229a38236d4dc3abf0f3174 

So far, we don’t have endpoints to fetch the data, so let’s use MongoDB Compass to check.

10.4. Validate With MongoDB Compass

Let’s open up the application and simply click Connect:

Following, select the person database and collection in the left panel:

As we can see, the document was inserted correctly, which means that our Ktor setup works, as expected.

11. Obtain Documents From MongoDB

Nextly, let’s check how can we obtain documents from MongoDB using KMongo.

11.1. Add findAll() function

Let’s get back to the PersonService and implement the findAll() function:

fun findAll(): List<Person> =
  personCollection.find()
    .toList()

It’s a really simple function and later I will show you how to enhance it with additional filters.

11.2. Expose GET Endpoint

For now, let’s expose a simple GET endpoint:

get {
  val peopleList =
      service.findAll()
        .map(Person::toDto)

  call.respond(peopleList)
}

The above code simply uses our newly created function and maps each Person object using its extension method toDto().

11.3. Test GET Handler

Finally, let’s perform a GET request to see if everything is OK:

GET http://localhost:8080/person 

Response Status: 200 OK

Response Payload: 
[
  {
    "id": "6229a38236d4dc3abf0f3174",
    "name": "Piotr",
    "age": 55
  }
]

As we can see, the previously inserted MongoDB document is returned, so we can assume this part is done.

12. Get Document By ID

As the next step, let’s add the handler responsible for fetching people by their ID.

12.1. Implement findById() function

Let’s add the findById() within our service:

fun findById(id: String): Person? {
  val bsonId: Id<Person> = ObjectId(id).toId()
  return personCollection
    .findOne(Person::id eq bsonId)
}

One of the key features of KMongo is a type-safe query framework. As we can see above, to make sure that the appropriate argument type is passed to our database, we use a Kotlin property reference. This way, the code won’t compile if the input type won’t match the required one. In the next chapter, we will take a deeper look at this topic.

Alternatively, we can use .findOneById() and pass an ObjectId instance to it. Nevertheless, for the learning purpose I’ve deided to show you this approach, as well.

12.2. Create GET By ID Handler

For now, let’s insert a new handler to our codebase:

get("/{id}") {
  val id = call.parameters["id"].toString()

  service.findById(id)
    ?.let { foundPerson -> call.respond(foundPerson.toDto()) }
    ?: call.respond(HttpStatusCode.NotFound, ErrorResponse.NOT_FOUND_RESPONSE)
}

As we can see- firstly, we obtain the identifier from the request path. If the person with the given ID exists in MongoDB, then we return PersonDto to our Ktor app client. In other cases, we simply return 404 Not Found response.

12.3. Validate GET By ID Endpoint

Again, let’s make sure that the above theory meets practice:

GET (existing ID) http://localhost:8080/person/6229a38236d4dc3abf0f3174

Response Status: 200 OK

Response Payload: 
{
  "id": "6229a38236d4dc3abf0f3174",
  "name": "Piotr",
  "age": 55
}

GET (non-existing ID) http://localhost:8080/person/6229a38236d4dc3abf0f3175

Response Status: 404 Not Found

Response Payload: 
{
  "message": "Person was not found"
}

And again- that is the result we were expecting.

13. Search With Additional Filters

As the next step, let’s have a look at the KMongo filtering capabilities.

13.1. Create Type-Safe findByName() method

To do so, let’s add a findByName() function first:

fun findByName(name: String): List<Person> {
  val caseSensitiveTypeSafeFilter = Person::name regex name
  return personCollection.find(caseSensitiveTypeSafeFilter)
    .toList()
}

To find any document containing a given string in Mongo, we can use leverage $regex. Of course, there are other possibilities, like a $text operator, but it does not have its type-safe version in KMongo.

Also, it’s worth mentioning that the above filter is case-sensitive.

13.2. Add Case-Insensitive Regex Filter

However, if we would like to search for the documents containing the given text regardless of the case, then we can use the overloaded regex function:

val caseInsensitiveTypeSafeFilter = personCollection.find(
  (Person::name).regex(name, "i")
)

As we can see, the above regex extension function allows us to specify additional options. The “i” flag simply instructs MongoDB to match both upper and lower cases.

And again- this approach allows us to make sure that the appropriate argument type is passed each time.

13.3. Pass Filter As A String

Although it is more error-prone, the find() function allows us also to specify filters as String values:

val nonTypeSafeFilter = personCollection.find(
  "{name:{'\$regex' : '$name', '\$options' : 'i'}}"
)

In some cases, we don’t have any other possibility and in such a case we have to make sure to handle all the possible exceptions properly.

13.4. AND Operator

Another useful feature is filter chaining. Let’s learn how to chain filters with the AND operator:

val withAndOperator = personCollection.find(
  and(Person::name regex name, Person::age gt 40)
)

As we can see, the snippet from our Ktor app will look for all people persisted in MongoDB, which match the given name (case-sensitvie) and are older, than 40 years.

On the other hand, we can refactor the above code a bit:

val implicitAndOperator = personCollection.find(
  Person::name regex name, Person::age gt 40
)

When we pass multiple filters to the find() function, they are implicitly combined with AND operator.

13.5. OR Operator

Similarly, we can add the OR operator:

val withOrOperator = personCollection.find(
  or(Person::name regex name, Person::age gt 40)
)

13.6. Add Ktor Search Handler

To summarize the searching topic, let’s expose a new GET endpoint:

get("/search") {
  val name = call.request.queryParameters["name"].toString()

  val foundPeople = service.findByName(name).map(Person::toDto)

  call.respond(foundPeople)
}

This time, we use query parameters to obtain a name to look for. To put it simply, when searching for users with name John, the Ktor app client has to perform a GET localhost:8080/person/search?name=John request.

Given the fact I’ve presented various filters, I highly encourage you to test this endpoint on your own- by adding more data and validating each filter.

14. Update Document

As the second to last, let’s see how can we update the person by ID in our project.

14.1. Implement updateById()

Firstly, let’s add this code to our service:

fun updateById(id: String, request: Person): Boolean =
  findById(id)
    ?.let { person ->
      val updateResult = personCollection.replaceOne(person.copy(name = request.name, age = request.age))
      updateResult.modifiedCount == 1L
    } ?: false

As we can see, firstly we make use of our existing findById function. As a result, we get either found person object, or null. Following we make use of replaceOne() function and as an argument we pass the same person instance with updated name and age fields.

As this function is supposed to update document by its unique identifier, it returns true only when exactly 1 item was modified.

14.2. Create PUT Endpoint

As the next step, let’s expose a new endpoint:

put("/{id}") {
  val id = call.parameters["id"].toString()
  val personRequest = call.receive<PersonDto>()
  val person = personRequest.toPerson()

  val updatedSuccessfully = service.updateById(id, person)

  if (updatedSuccessfully) {
    call.respond(HttpStatusCode.NoContent)
  } else {
    call.respond(HttpStatusCode.BadRequest, ErrorResponse.BAD_REQUEST_RESPONSE)
  }
}

This one combines together a few concepts we’ve learned already and as a result either 204 No Content, or 400 Bad Request will be returned.

14.3. Test PUT Endpoint

And again, let’s see whether our endpoint is working correctly:

PUT (existing ID) http://localhost:8080/person/6229a38236d4dc3abf0f3174 

Request Payload: 
{ 
  "name": "Piotr- updated", 
  "age": 20
}

Response Status: 204 No Content

PUT (non-existing ID) http://localhost:8080/person/6229a38236d4dc3abf0f3173 

Request Payload: 
{ 
"name": "Piotr- updated", 
"age": 20
}

Response Status: 400 Bad Request

Response Payload:
{
  "message": "Invalid request"
}

This time, to validate if the data were persisted correctly, we can either use existing GET by ID endpoint or check with MongoDB Compass.

15. Delete Document

Finally, learn how to delete items from MongoDB in our Ktor project.

15.1. Create deleteById() Function

Let’s start by adding the deleteById() inside the service class:

fun deleteById(id: String): Boolean {
  val deleteResult = personCollection.deleteOneById(ObjectId(id))
  return deleteResult.deletedCount == 1L
}

This time, we simply create a new ObjectId and pass it to deleteOneById() function. Similarly, the operation was successful only if the deleted count equals 1.

15.2. Add DELETE Handler

Following, let’s implement the DELETE endpoint handler:

delete("/{id}") {
  val id = call.parameters["id"].toString()

  val deletedSuccessfully = service.deleteById(id)

  if (deletedSuccessfully) {
    call.respond(HttpStatusCode.NoContent)
  } else {
    call.respond(HttpStatusCode.NotFound, ErrorResponse.NOT_FOUND_RESPONSE)
  }
}

This time, we simply invoke deleteById function using the String identifier passed by API client. If the Person has been deleted successfuly, we return 204 No Content response. If that is not true, then we inform the client with 404 status.

15.3. Validate DELETE Endpoint

Finally, let’s see if everything was set up correctly:

DELETE (existing ID) http://localhost:8080/person/6229a38236d4dc3abf0f3174 

Response Status: 204 No Content

DELETE (we can use the same ID) http://localhost:8080/person/6229a38236d4dc3abf0f3174

Response Status: 404 Not Found
Response Payload:
{
  "message": "Person was not found"
}

As we can see, everything is working as expected.

16. Ktor With MongoDB and KMongo Summary

And that would be all for this step-by-step guide on creating a CRUD REST API with Ktor, MongoDB, and KMongo.

I really hope that my materials will help you to learn new things and will be happy if you would like to share some feedback with me using the contact form.

If you would like to get the full source code for this project, please refer to this GitHub repository.

The post A Guide To Ktor With MongoDB appeared first on Codersee blog- Kotlin on the backend.

Hello dear readers. In this article, I would like to teach you how to create a Micronaut project with MongoDB and Kotlin.

Micronaut is a modern, JVM-based framework for building modular, easily testable microservice and serverless applications. If you have any prior experience with reflection-based frameworks, like Spring or Spring Boot, you probably noticed that the startup time and memory consumption are bound to the size of the codebase. With Micronaut, these problems have been solved using Java’s annotation processors, making it a really great choice for low memory-footprint environments, like microservices.

Moreover, the creators took a lot of inspiration from Spring and Grails, so if you’ve ever worked with any of them, you’ll see plenty of similarities.

In this guide, we will create a simple CRUD REST API, which will allow the user to operate on the data from MongoDB (for a similar project in Spring Boot, please see this article).

Note: I’ve released a newer, refreshed version of this article, which you can find right here.

2. Run MongoDB Server

Just like in previous articles, we need to make sure, that our MongoDB server is up and running. For simplicity, we will deploy it as a docker container. Nevertheless, if you would like to install a MongoDB on your local machine, please refer to this official manual.

2.1. Deploy MongoDB as a Container

Firstly, let’s pull the mongo image from the Docker Hub registry:

docker pull mongo

After that, let’s deploy it in a detached mode ( -d flag):

docker run -d -p 27017-27019:27017-27019 --name mongodb mongo

Besides deploying in a detached mode, the above command publishes the container’s ports to the host- in simple terms, we will be able to connect to the MongoDB using localhost.

Finally, let’s check if everything is OK with the following command:

docker ps

#command output
CONTAINER ID        IMAGE               COMMAND                  CREALTED             STATUS              PORTS                                  NAMES
26bd5c8dcc79        mongo               "docker-entrypoint.s…"   6 seconds ago       Up 5 seconds        0.0.0.0:27017-27019->27017-27019/tcp   mongodb

3. Set Up The Project

3.1. Generate The Project

As the first step, let’s generate the project. We can do that either by installing the Micronaut CLI or with the online launcher (similar to the Spring Initializr). In my case, I’ve generated it using the web launcher, setting the following values:

• Application Type: Micronaut Application
• Java Version: 11
• Base Package: com.codersee
• Name: example
• Micronaut Version: 2.2.1
• Language: Kotlin
• Build: Gradle Kotlin
• Test Framework: Junit
• Included Features: mongo-sync

Please notice, that we’ve included the mongo-sync feature, which will provide the support for the Mongo Synchronous Driver in our application.

3.2. Add The No-arg Compiler Plugin

Additionally, let’s add the no-arg compiler plugin inside the build.gradle.kts file:

plugins {
    id("org.jetbrains.kotlin.plugin.noarg") version "1.4.10"
}

The no-arg compiler plugin generates an additional zero-argument constructor for classes with a specific annotation. I’ll show you, how to create such annotation and why should we use it in the next chapters.

3.3. Configure application.yml

As the next step, let’s the MongoDB connection config inside the application.yml file:

micronaut:
  application:
    name: example
mongodb:
  uri: 'mongodb://localhost:27017/example'

This configuration instructs the MongoDB driver, that it should connect to the example database of the MongoDB instance running on port 27017.

4. Create @NoArg annotation

As the next step, let’s utilize the no-arg plugin and create the NoArg.kt file under the annotation package:

@Target(AnnotationTarget.CLASS)
@Retention(AnnotationRetention.SOURCE)
annotation class NoArg

Additionally, we have to add the following configuration inside the build.gradle.kts file:

noArg {
    annotation("com.codersee.annotation.NoArg")
}

Please keep in mind, that the parameter passed to the function, “com.codersee.annotation.NoArg” in my case, needs to match with the package inside your project.

5. Create Models

After all of the above being done, we can start defining models, which will be used to persist and fetch objects from the database. In our example, we will define two separate classes- a Company and an Employee:

@NoArg
data class Company(
    var id: ObjectId? = null,
    var name: String,
    var address: String
)

@NoArg
data class Employee(
    var id: ObjectId? = null,
    var firstName: String,
    var lastName: String,
    var email: String,
    var company: Company?,
)

As you might have noticed, both classes have been annotated with the @NoArg. Without it, we would have to make all of the fields nullable and that’s something I wanted to avoid.

5.1. What is ObjectId?

You might be wondering, what exactly the ObjectId is? Well, by default MongoDB uses ObjectIds as the default value of the _id field of each document. An ObjectId is a 12-byte BSON type having the following structure:

• The first 4 bytes represent the seconds since the Unix epoch
• The next 3 bytes are the machine identifier
• The next 2 bytes consists of process id
• The last 3 bytes are a random counter value

These 12 bytes altogether uniquely identify a document within the MongoDB collection and serve as a primary key for that document as well.

6. Add Custom Exception With Status Code

Nextly, let’s create a custom exception class named NotFoundException and ExceptionResponse, which will be used to serialize the response:

class NotFoundException(msg: String) : RuntimeException(msg)

class ExceptionResponse(
    val message: String?
)

NotFoundException is just a simple class extending the RuntimeException. Additionally, this class contains the msg field, which will be used to set and obtain the custom message.

With that being done, let’s create the NotFoundExceptionHandler class:

@Produces
@Singleton
class NotFoundExceptionHandler :
    ExceptionHandler<NotFoundException, HttpResponse<ExceptionResponse>> {

    override fun handle(
        request: HttpRequest<*>,
        exception: NotFoundException
    ): HttpResponse<ExceptionResponse> =
        HttpResponse.notFound(
            ExceptionResponse(
                message = exception.message
            )
        )

}

As you can see, we implement the ExceptionHandler interface and specify two things:

• The Throwable, we’d like to handle- NotFoundException in our case
• The result type- in our case, the  HttpResponse<ExceptionResponse>

Moreover, we provide the declaration for the handle function, in which we set the response body with the message from the exception and the 404 NOT FOUND response code.

6.1. What is @Singleton and @Produces?

Well, the @Signleton is used to register a Singleton in Micronaut’s application context (just like a @Component in Spring Boot). The @Produces annotation, on the other hand, is used to indicate, what MediaTypes will be produced by our component (by default, it’s set to the application/json).

7. Create Repositories

As the next step, let’s create repositories for our data. In our project, we’ll use the synchronous MongoClient to perform operations on the MongoDB.

7.1. Implement CompanyRepository

Let’s start by adding the CompanyRepository first:

@Singleton
class CompanyRepository(
    private val mongoClient: MongoClient
) {

    fun create(company: Company): InsertOneResult =
        getCollection()
            .insertOne(company)

    fun findAll(): List<Company> =
        getCollection()
            .find()
            .toList()

    fun findById(id: String): Company? =
        getCollection()
            .find(
                Filters.eq("_id", ObjectId(id))
            )
            .toList()
            .firstOrNull()

    fun update(id: String, update: Company): UpdateResult =
        getCollection()
            .replaceOne(
                Filters.eq("_id", ObjectId(id)),
                update
            )

    fun deleteById(id: String): DeleteResult =
        getCollection()
            .deleteOne(
                Filters.eq("_id", ObjectId(id))
            )

    private fun getCollection() =
        mongoClient
            .getDatabase("example")
            .getCollection("company", Company::class.java)
}

Let’s discuss, what exactly is happening in this class.

As the first step, we need to register it in the application context with @Signleton and inject the MongoClient instance through the constructor.

@Singleton
class CompanyRepository(
    private val mongoClient: MongoClient
) 

Nextly, we create the helper function, which will be responsible for getting the MongoCollection object of the company collection from the example database. Moreover, we pass the Company::class.java as the second parameter, so that all of the returned documents will be cast to this type.

private fun getCollection() =
    mongoClient
        .getDatabase("example")
        .getCollection("company", Company::class.java)

Following, let’s look at the functions responsible for getting the data from the database:

fun findAll(): List<Company> =
    getCollection()
        .find()
        .toList()

fun findById(id: String): Company? =
    getCollection()
        .find(
            Filters.eq("_id", ObjectId(id))
        )
        .toList()
        .firstOrNull()

As can be seen, in both cases the find() function has been used, returning the iterable, which we convert to the List. But, when looking for a specific company, we apply the additional filter looking for a document with the specified ID and either return the Company or null.

Lastly, let’s look at functions responsible for creating, updating, and deleting the data:

fun create(company: Company): InsertOneResult =
    getCollection()
        .insertOne(company)

fun update(id: String, update: Company): UpdateResult =
    getCollection()
        .replaceOne(
            Filters.eq("_id", ObjectId(id)),
            update
        )

fun deleteById(id: String): DeleteResult =
    getCollection()
        .deleteOne(
            Filters.eq("_id", ObjectId(id))
        )
}

As you can see, all of them return _Result instances. These classes contain a lot of useful information, like the count, or ID of affected documents (which we will use in the service layer).

7.2. Implement EmployeeRepository

Similarly, let’s implement the EmployeeRepository:

@Singleton
class EmployeeRepository(
    private val mongoClient: MongoClient
) {

    fun create(employee: Employee): InsertOneResult =
        getCollection()
            .insertOne(employee)

    fun findAll(): List =
        getCollection()
            .find()
            .toList()

    fun findAllByCompanyId(companyId: String): List<Employee> =
        getCollection()
            .find(
                Filters.eq("company._id", ObjectId(companyId))
            )
            .toList()


    fun findById(id: String): Employee? =
        getCollection()
            .find(
                Filters.eq("_id", ObjectId(id))
            )
            .toList()
            .firstOrNull()

    fun update(id: String, update: Employee): UpdateResult =
        getCollection()
            .replaceOne(
                Filters.eq("_id", ObjectId(id)),
                update
            )

    fun deleteById(id: String): DeleteResult =
        getCollection()
            .deleteOne(
                Filters.eq("_id", ObjectId(id))
            )

    private fun getCollection() =
        mongoClient
            .getDatabase("example")
            .getCollection("employee", Employee::class.java)
}

8. Create Services

8.1. Implement CompanyService

Before we will create the service, let’s add the CompanyRequest class, which will be used to store the data passed by the user:

class CompanyRequest(
    val name: String,
    val address: String
)

Nextly, let’s create the CompanyService class:

@Singleton
class CompanyService(
    private val companyRepository: CompanyRepository,
    private val employeeRepository: EmployeeRepository
) {

    fun createCompany(request: CompanyRequest): BsonValue? {
        val insertedCompany = companyRepository.create(
            Company(
                name = request.name,
                address = request.address
            )
        )
        return insertedCompany.insertedId
    }

    fun findAll():  List<Company> {
        return companyRepository.findAll()
    }

    fun findById(id: String): Company {
        return companyRepository.findById(id)
            ?: throw NotFoundException("Company with id $id was not found")
    }

    fun updateCompany(id: String, request: CompanyRequest): Company {
        val updateResult = companyRepository.update(
            id = id,
            update = Company(name = request.name, address = request.address)
        )

        if (updateResult.modifiedCount == 0L)
            throw throw RuntimeException("Company with id $id was not updated")

        val updatedCompany = findById(id)
        updateCompanyEmployees(updatedCompany)

        return updatedCompany
    }

    fun deleteById(id: String) {
        val deleteResult = companyRepository.deleteById(id)

        if (deleteResult.deletedCount == 0L)
            throw throw RuntimeException("Company with id $id was not deleted")
    }

    private fun updateCompanyEmployees(updatedCompany: Company) {
        employeeRepository
            .findAllByCompanyId(updatedCompany.id!!.toHexString())
            .map {
                employeeRepository.update(
                    it.id!!.toHexString(),
                    it.apply { it.company = updatedCompany }
                )
            }
    }
}

Basically, these are just simple functions responsible for creating, deleting, and retrieving the data through the CompanyRepository.

However, you might have noticed that each time, we would like to update the company, we need to update all employees connected with it. That’s because we keep the related company in denormalized form- inside the employee document. To visualize that, let’s check the example document from our database:

{
    "firstName": "Piotr",
    "lastName": "Wolak",
    "email": "contact@codersee.com",
    "company": {
        "_id": {
            "$oid": "5fcb90f830e3af4497f5de14"
        },
        "name": "Company Two",
        "company_address": "Address Two"
    },
    "_class": "com.codersee.mongocrud.model.Employee"
}

As you can see, the company document is stored as an inner document of each employee. This might seem pretty weird, especially when you have any previous experience working with SQL databases, but this is the optimal choice for most real-life scenarios when using MongoDB (if you would like to learn more about MongoDB relationships, please let me know and I will create another tutorial about it :).

8.2. Implement EmployeeService

In the same fashion, let’s create the EmployeeRequest responsible for data handling and the EmployeeService:

class EmployeeRequest(
    val firstName: String,
    val lastName: String,
    val email: String,
    val companyId: String?
)

@Singleton
class EmployeeService(
    private val employeeRepository: EmployeeRepository,
    private val companyService: CompanyService

) {

    fun createEmployee(request: EmployeeRequest): BsonValue? {
        val company = request.companyId?.let { companyService.findById(it) }

        val insertedEmployee = employeeRepository.create(
            Employee(
                firstName = request.firstName,
                lastName = request.lastName,
                email = request.email,
                company = company
            )
        )
        return insertedEmployee.insertedId
    }

    fun findAll(): List<Employee> =
        employeeRepository.findAll()

    fun findById(id: String): Employee =
        employeeRepository.findById(id)
            ?: throw NotFoundException("Employee with id $id not found")

    fun updateEmployee(id: String, request: EmployeeRequest): Employee {
        val foundCompany = request.companyId?.let { companyService.findById(it) }

        val updateResult = employeeRepository.update(
            id = id,
            update = Employee(
                firstName = request.firstName,
                lastName = request.lastName,
                email = request.email,
                company = foundCompany
            )
        )

        if (updateResult.modifiedCount == 0L)
            throw throw RuntimeException("Employee with id $id was not updated")

        return findById(id)
    }

    fun deleteById(id: String) {
        val deleteResult = employeeRepository.deleteById(id)

        if (deleteResult.deletedCount == 0L)
            throw throw RuntimeException("Company with id $id was not deleted")
    }
}

9. Implement REST Controllers

As the last step, we will implement the controller layer responsible for request handling. But before that, let’s prepare two classes: CompanyResponse and EmployeeResponse responsible for returning the data to the user.

Important note: although the creation of separate classes for transferring the incoming and outgoing data adds some redundancy to the code, I personally believe it is a good way to separate these concepts and make the code cleaner.

class CompanyResponse(
    val id: String,
    val name: String,
    val address: String
) {
    companion object {
        fun fromEntity(company: Company): CompanyResponse =
            CompanyResponse(
                id = company.id!!,
                name = company.name,
                address = company.address
            )
    }
}

class EmployeeResponse(
    val id: String,
    val firstName: String,
    val lastName: String,
    val email: String,
    val company: CompanyResponse?
) {
    companion object {
        fun fromEntity(employee: Employee): EmployeeResponse =
            EmployeeResponse(
                id = employee.id!!.toHexString(),
                firstName = employee.firstName,
                lastName = employee.lastName,
                email = employee.email,
                company = employee.company?.let { CompanyResponse.fromEntity(it) }
            )
    }
}

As you can see, both classes contain fromEntity functions inside companion objects. As the name suggests, they will be used to convert entity objects to response instances.

9.1. Create CompanyController

Let’s add the CompanyController class to our project first:

@Controller("/api/company")
class CompanyController(
    private val companyService: CompanyService
) {

    @Post
    fun create(@Body request: CompanyRequest): HttpResponse<Void> {
        val createdId = companyService.createCompany(request)

        return HttpResponse.created(
            URI.create(
                createdId!!.asObjectId().value.toHexString()
            )
        )
    }

    @Get
    fun findAll(): HttpResponse<List<CompanyResponse>> {
        val companies = companyService
            .findAll()
            .map { CompanyResponse.fromEntity(it) }

        return HttpResponse.ok(companies)
    }

    @Get("/{id}")
    fun findById(@PathVariable id: String): HttpResponse<CompanyResponse> {
        val company = companyService.findById(id)

        return HttpResponse.ok(
            CompanyResponse.fromEntity(company)
        )
    }

    @Put("/{id}")
    fun update(
        @PathVariable id: String,
        @Body request: CompanyRequest
    ): HttpResponse<CompanyResponse> {
        val updatedCompany = companyService.updateCompany(id, request)

        return HttpResponse.ok(
            CompanyResponse.fromEntity(updatedCompany)
        )
    }

    @Delete("/{id}")
    fun deleteById(@PathVariable id: String): HttpResponse<Void> {
        companyService.deleteById(id)

        return HttpResponse.noContent()
    }
}

As you can see,  in order to make the class a controller inside the Micronaut context, we need to annotate it with @Controller. Additionally, we can pass the base URI to it, as we’ve done in the above code snippet.

Basically, the CompanyController utilizes already prepared functions from the CompanyService. Each function needs to be marked with appropriate annotation (like @Get, @Put, etc.) in order to serve as an HTTP request handler. By default, it will use the base URI set for the class (/api/company in our case).

As the last thing, please notice the @PathVariable- used to bind the parameter of the function exclusively from the path variable- and the @Body– indicating that the method argument is bound from the HTTP body.

9.2. Create EmployeeController

Similarly, let’s implement the EmployeeController:

@Controller("/api/employee")
class EmployeeController(
    private val employeeService: EmployeeService
) {

    @Post
    fun create(@Body request: EmployeeRequest): HttpResponse {
        val createdId = employeeService.createEmployee(request)

        return HttpResponse.created(
            URI.create(
                createdId!!.asObjectId().value.toHexString()
            )
        )
    }

    @Get
    fun findAll(): HttpResponse<List> {
        val employees = employeeService
            .findAll()
            .map { EmployeeResponse.fromEntity(it) }

        return HttpResponse.ok(employees)
    }

    @Get("/{id}")
    fun findById(@PathVariable id: String): HttpResponse {
        val employee = employeeService.findById(id)

        return HttpResponse.ok(
            EmployeeResponse.fromEntity(employee)
        )
    }

    @Put("/{id}")
    fun update(
        @PathVariable id: String,
        @Body request: EmployeeRequest
    ): HttpResponse {
        val updatedEmployee = employeeService.updateEmployee(id, request)

        return HttpResponse.ok(
            EmployeeResponse.fromEntity(updatedEmployee)
        )
    }

    @Delete("/{id}")
    fun deleteById(@PathVariable id: String): HttpResponse {
        employeeService.deleteById(id)

        return HttpResponse.noContent()
    }
}

10. Test with CURL

Finally, we can run our application- for instance, with the ./gradlew run command- and test the endpoints using cURL. If you would like to explore the database, I highly recommend the MongoDB Compass, which is the dedicated GUI for MongoDB.

Let’s start by adding two companies:

# 1st company
curl --location --request POST 'localhost:8080/api/company' \
--header 'Content-Type: application/json' \
--data-raw '{
    "name": "Company 1",
    "address": "Address 1"
}'

# 2nd company
curl --location --request POST 'localhost:8080/api/company' \
--header 'Content-Type: application/json' \
--data-raw '{
    "name": "Company 2",
    "address": "Address 2"
}'

To validate, let’s list all companies:

curl --location --request GET 'localhost:8080/api/company'

# Example output
[
  {
    "id": "5fcba07a30e3af4497f5de16",
    "name": "Company 1",
    "address": "Address 1"
  },
  {
    "id": "5fcba07c30e3af4497f5de17",
    "name": "Company 2",
    "address": "Address 2"
  }
]

If we would like to find a specific company, then let’s use the following command:

curl --location --request GET 'localhost:8080/api/company/5fcba07c30e3af4497f5de17'

# Expected output
{
  "id": "5fcba07c30e3af4497f5de17",
  "name": "Company 2",
  "address": "Address 2"
}

To update the company, let’s use the PUT request:

curl --location --request PUT 'localhost:8080/api/company/5fcba07c30e3af4497f5de17' \
--header 'Content-Type: application/json' \
--data-raw '{
    "name": "Company 2 Updated",
    "address": "Address 2 Updated"
}'

If everything went well, we should see that our company data has been updated- you can always check it with another endpoint as well.

To delete the company, let’s use the DELETE handling endpoint:

curl --location --request DELETE 'localhost:8080/api/company/5fcba07c30e3af4497f5de17'

This time, we should receive an empty response body with 204 No Content status and a company should be deleted as well.

Similarly, we can test the rest of the endpoints responsible for employees management- let it be homework for you- I’ve always believed there is no other way to learn anything, than trying on our own 🙂

11. Summary

And that’s all for this article. We’ve gone step by step through the process of creating the Micronaut project with MongoDB and Kotlin

I hope, you really enjoyed it and that after reading it, you’ll get more interested in the Micronaut project. If you would like to ask about anything or add your own suggestions, please do it in the comment section below, or by using the contact form.

As usual, you can find the working project in this GitHub repository.

The post Micronaut with MongoDB and Kotlin appeared first on Codersee blog- Kotlin on the backend.