DEV Community: Mark Heckler

Cosmos DB for Spring Developers, Part II: Using Cosmos DB as a MongoDB Database

Mark Heckler — Fri, 16 Dec 2022 13:52:58 +0000

In the first installment of this series, I discussed Spring Boot, Spring Data, and several of the underlying datastores supported by Spring Data. I also introduced Azure Cosmos DB and offered a glimpse of the various APIs it supports. I then showed how to create a Spring Boot application that uses Cosmos DB as a SQL database.

If you're using a SQL datastore, I trust that was a really useful introduction to how to take your existing Spring Boot relational database application and make it truly planetary scale. But what if you prefer a non-relational (NoSQL) document database? Short of rewriting your apps, are you constrained by what that particular vendor chooses to offer? Absolutely not!

In this installment, I'll show you how to use Cosmos DB as a MongoDB database.

Azure Cosmos DB for MongoDB

As mentioned in Part I, Azure Cosmos DB is a planetary-scale datastore that offers various ways and APIs to manage your critical data and provide access to it at breathtaking speed. Harnessing the power of Cosmos DB as a SQL datastore was a fairly straightforward affair, but here's a pleasant surprise: replacing a MongoDB database in your Spring Boot application is even easier.

Aside from the rather cumbersome (yet delightfully descriptive) name, Azure Cosmos DB for MongoDB is a simple, yet powerful, drop-in replacement for MongoDB in your Spring Boot apps. To illustrate this, I'll create another project very similar to the one I created in Part I, but using MongoDB as the initial choice of database.

Create a Spring Boot app

There are many ways to begin creating a Spring Boot application, but I prefer to begin with the Spring Initializr. Choose your build system (I opt for Maven most days, but your -- and my -- mileage may vary), choose a meaningful artifact name, change the group name if you so choose, then select the dependencies as shown in the following screen capture.

Create and open the project

NOTE: All code is in a Github repository linked at the bottom of this article.

I use only three dependencies for this example:

Reactive Web - includes all dependencies to create web apps using reactive streams, non-blocking and/or imperative APIs
Spring Data Reactive MongoDB - enables your app to access MongoDB using the Reactor (reactive streams) API
Lombok - boilerplate-reducing library, useful for domain classes, logging, and more

Next, click the "Generate" button to generate the project structure and download the compressed project files (.zip). Once downloaded, go to the directory where the file was saved, decompress it, and open the project in the Integrated Development Environment (IDE) or text editor of your choice. I use IntelliJ IDEA and Visual Studio Code (VSCode) for nearly all my dev work, and for this article I'll open the project in IntelliJ by navigating (using the Mac Finder) into the expanded project directory and double-clicking on the Maven build file, pom.xml.

Once the project is loaded, you can verify that the dependencies chosen from the Spring Initializr are present within the project by opening the pom.xml file. There will be additional ones brought in for testing, etc., but these represent the three we selected before generating the project structure:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-webflux</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-mongodb-reactive</artifactId>
</dependency>
<dependency>
    <groupId>org.projectlombok</groupId>
    <artifactId>lombok</artifactId>
    <optional>true</optional>
</dependency>

Code the application

This is a fairly simple (and a bit contrived) example, but I have expanded it a bit from the previous article in this series. Check back for the next installment to see where things go from here.

The domain

First, I code a domain class. In this example, I create a User class with an id, firstName, lastName, and address member variables. This class and its properties are annotated thusly:

@Document - indicates that each instance of this class can be treated as a document by the underlying datastore, allowing for CRUD (Create, Read, Update, and Delete) operations
@Data - Lombok annotation, instructs Lombok to consider this a "data class" and generate accessors (getters) and mutators (setters) for each member variable, along with equals(), hashCode(), and toString() methods
@NoArgsConstructor - Lombok annotation that instructs Lombok to generate a zero-argument constructor
@RequiredArgsConstructor - Lombok annotation that instructs Lombok to generate a constructor with a parameter for each "required" member variable, as designated by the @NonNull member variable annotation
@Id - indicates which member variable corresponds to the underlying table's primary key
@NonNull - addressed under @RequiredArgsConstructor

The repository

Spring Boot's autoconfiguration extends the power of Spring Data. By placing a database driver in your classpath (including it as a dependency in your build file results in its inclusion for deployment) and extending a Spring Data-derived interface in your application code, Spring Boot's autoconfiguration creates the beans necessary to provide a proxy to the desired underlying datastore. In our case, this is all we need to provide foundational reactive database capabilities:

interface UserRepository extends ReactiveCrudRepository<User, String> {}

In this single line of code, we are defining an interface called UserRepository that will inherit and potentially extend the capabilities of the ReactiveCrudRepository, storing objects of type User with identifiers (IDs) of type String. Spring Boot's autoconfiguration does the rest.

NOTE: We can do more, of course, defining custom query methods and more. But for this example, the provided functionality is sufficient.

The API

Next, I define the Application Programming Interface (API) that provides the means and structure for external applications to interact with this service. Since this is our second app in this series, I expanded on the previous API a bit by adding a second GET endpoint and method to get the first user document stored, along with a POST endpoint and method, allowing for the creation and storage of a new user.

@RestController
@AllArgsConstructor
class CosmosMongoController {
    private final UserRepository repo;

    @GetMapping("/")
    Flux<User> getAllUsers() {
        return repo.findAll();
    }

    @GetMapping("/oneuser")
    Mono<User> getFirstUser() {
        return repo.findAll().next();
    }

    @PostMapping("/newuser")
    Mono<User> addUser(@RequestBody User user) {
        return repo.save(user);
    }
}

To revisit some fundamentals, the @RestController annotation is provided by the Spring Framework and combines the functionality of @Controller, to respond to requests, and @ResponseBody, to make the resultant object(s) the response body itself, rather than just providing access to the object(s) via a model variable, as is the typical MVC methodology.

The @AllArgsConstructor annotation instructs Lombok to create a constructor for the CosmosMongoController class with a parameter (and thus required argument) for every member variable. Since the only member variable is a UserRepository, Lombok generates a ctor with that single parameter.

NOTE: @AllArgsConstructor has the fortunate (or perilous) capability to update your constructor automatically if you simply add/remove member variables, so remember: With great power comes great responsibility. If you don't want this behavior, use @RequiredArgsConstructor instead, annotating each member variable with @NonNull that you wish to require and thus have represented as a parameter in the constructor.

The data

As in Part I, I create a Spring bean using the @Component annotation to populate some sample data. The @Component annotation instructs Spring Boot, upon application initialization, to create an instance of the annotated class and place that object (bean) into the application context, i.e. its Dependency Injection (DI) container. All beans in the DI container are managed by the Spring Boot application in terms of lifecycle and, of course, injection into other code as dependencies.

Once the bean is constructed, the loadData() method is executed automatically due to the @PostConstruct annotation. In this application, the loadData() method deletes all lingering data in the underlying datastore (from previous app executions), populates it with two sample User records, returns all User records now stored in the database, and logs them to the console for verification.

NOTE: The Reactive Streams API and the implementation of it as provided by Spring WebFlux/Project Reactor is beyond the scope of this particular article. Please consult the appropriate documentation at the 'Web on Reactive Stack' Spring documentation site, any of several sessions I've delivered available via my YouTube channel, or by visiting the Reactive Streams and Project Reactor sites.

@Slf4j
@Component
@AllArgsConstructor
class DataLoader {
    private final UserRepository repo;

    @PostConstruct
    void loadData() {
        repo.deleteAll()
                .thenMany(Flux.just(new User("Alpha", "Bravo", "123 N 45th St"),
                        new User("Charlie", "Delta", "1313 Mockingbird Lane")))
                .flatMap(repo::save)
                .thenMany(repo.findAll())
                .subscribe(user -> log.info(user.toString()));
    }
}

Demo, take 1

NOTE: This demo assumes you have a MongoDB instance running locally on your machine. If you do not, please install and run MongoDB locally or better yet, use the MongoDB Docker script provided at the end of this article to spin up a MongoDB instance in a Docker container.

NOTE: If you intend to use Docker to run a local MongoDB instance in a container, you must first install Docker on your machine. Please consult the Docker installation documentation for your operating system.

Since we're running MongoDB locally, we do not need to set any properties for our Spring Boot app. Spring Data MongoDB will automatically connect to the MongoDB instance exposed via the default port of 27017 on localhost.

To verify the application is working properly and is able to access the local MongoDB instance, execute the following commands from a terminal window:

curl http://localhost:8080

Alternatively, you can access http://localhost:8080 from a browser tab or window.

NOTE: I use HTTPie instead of curl and greatly prefer it. Commands seem more logical and output more readable. HTTPie leverages default values for many properties, such as the hostname: if not provided, it is assumed to be localhost, a very reasonable assumption. In all of my examples, the http command you see is HTTPie.

The following should be displayed:

HTTP/1.1 200 OK
Content-Type: application/json
transfer-encoding: chunked

[
    {
        "address": "123 N 45th St",
        "firstName": "Alpha",
        "id": "639900044b494a1a26d1c1fd",
        "lastName": "Bravo"
    },
    {
        "address": "1313 Mockingbird Lane",
        "firstName": "Charlie",
        "id": "639900044b494a1a26d1c1fe",
        "lastName": "Delta"
    }
]

To exercise the second endpoint and return the first user in the database, execute the following command:

curl http://localhost:8080/oneuser

You should see something like this:

HTTP/1.1 200 OK
Content-Length: 98
Content-Type: application/json

{
    "address": "123 N 45th St",
    "firstName": "Alpha",
    "id": "639900044b494a1a26d1c1fd",
    "lastName": "Bravo"
}

To exercise the third endpoint and add a new user to the database, execute the following command:

http POST :8080/newuser firstName=Echo lastName=Foxtrot address="21 Chester Place"

You should see something like this:

HTTP/1.1 200 OK
Content-Length: 102
Content-Type: application/json

{
    "address": "21 Chester Place",
    "firstName": "Echo",
    "id": "6399029c4b494a1a26d1c1ff",
    "lastName": "Foxtrot"
}

To double-check that all records are present in the database, you can once again access the first, summary endpoint via http :8080 or curl http://localhost:8080.

"Migrating" our app to Azure Cosmos DB for MongoDB

It's almost embarrassing how easy it is to migrate our app to Azure Cosmos DB for MongoDB. You'll see what I mean shortly, in the following sections.

Initialization and configuration

I use two scripts (repository link at the bottom of this article) to prepare the Azure environment generally and Cosmos DB specifically for this project: one to initialize environment variables to be used, and one to create the Azure Cosmos DB for MongoDB target based upon those variables and expose two variables Spring Data MongoDB expects for connections to databases at coordinates other than the defaults, localhost and port 27017.

The script CosmongoInitEnv.sh should be sourced by executing it in this manner from a terminal window:

source ./CosmongoInitEnv.sh

This assumes that the script resides in the current (.) directory, but if not, you must specify the full path to the shell script. Sourcing the script sets the environment variables contained therein and ensures they remain part of the environment after the script finishes, rather than spawning a different environment to run the script and having all changes made in that process disappear upon completion.

To verify environment variables are set as expected, I like to check the environment using a command similar to the following:

env | sort

env | grep COSMOSDB_MON

To create the Azure resources we will need for this project, and to expose the requisite variables for our app to locate our new cloud-based database, we then source the CosmongoConfig.sh script as follows:

source ./CosmongoConfig.sh

Two things of note. First, this again assumes you are executing this script from the current (.) directory. Second, since we once again set environment variable values that we plan to use after the script finishes execution, we must source this script as well. Failure to do isn't catastrophic, but it will result in empty variables and will require manually executing the final three lines (the exports) from CosmongoConfig.sh in the terminal in order to proceed.

You can verify the required environment variables are now set using this or similar command:

env | grep SPRING_DATA

These env vars are essential to the app we're about to create:

SPRING_DATA_MONGODB_URI
SPRING_DATA_MONGODB_DATABASE

If both variables' values are present, we can proceed to the next step and execute our application to begin using Azure Cosmos DB for MongoDB.

Changing the application

Just kidding! The app is already ready to go.

Yes, you read that correctly. Spring Data will automatically seek and incorporate the provided environment variables to connect to a database at coordinates other than the defaults. That's all that's required to migrate our app to Azure Cosmos DB for MongoDB!

Demo, take 2

From the project directory, execute the following command to build and run the project:

mvn spring-boot:run

Exercising the endpoints produces results nearly identical to the ones before, except that the data is now stored in Azure Cosmos DB for MongoDB (and of course, the database-assigned IDs are different).

Retrieve all current users:

» http :8080
HTTP/1.1 200 OK
Content-Type: application/json
transfer-encoding: chunked

[
    {
        "address": "123 N 45th St",
        "firstName": "Alpha",
        "id": "639bbb1db945f0487e9a778a",
        "lastName": "Bravo"
    },
    {
        "address": "1313 Mockingbird Lane",
        "firstName": "Charlie",
        "id": "639bbb1db945f0487e9a778b",
        "lastName": "Delta"
    }
]

Retrieve the first user in the database:

» http :8080/oneuser                                                                
HTTP/1.1 200 OK
Content-Length: 98
Content-Type: application/json

{
    "address": "123 N 45th St",
    "firstName": "Alpha",
    "id": "639bbb1db945f0487e9a778a",
    "lastName": "Bravo"
}

Add a new user to the database:

» http POST :8080/newuser firstName=Echo lastName=Foxtrot address="21 Chester Place"
HTTP/1.1 200 OK
Content-Length: 102
Content-Type: application/json

{
    "address": "21 Chester Place",
    "firstName": "Echo",
    "id": "639bbb5cb945f0487e9a778c",
    "lastName": "Foxtrot"
}

Retrieve all users, verifying the new user we just added is present:

» http :8080
HTTP/1.1 200 OK
Content-Type: application/json
transfer-encoding: chunked

[
    {
        "address": "123 N 45th St",
        "firstName": "Alpha",
        "id": "639bbb1db945f0487e9a778a",
        "lastName": "Bravo"
    },
    {
        "address": "1313 Mockingbird Lane",
        "firstName": "Charlie",
        "id": "639bbb1db945f0487e9a778b",
        "lastName": "Delta"
    },
    {
        "address": "21 Chester Place",
        "firstName": "Echo",
        "id": "639bbb5cb945f0487e9a778c",
        "lastName": "Foxtrot"
    }
]

Summary

Thanks to the developer-first mindset of the Spring Boot, Spring Data, and Cosmos DB development teams, upgrading your Spring Boot app from using MongoDB to Azure Cosmos DB for MongoDB is as simple as changing a few environment variables and restarting your application. This enables you to go from concept to code to planetary-scale production in a matter of minutes...or seconds, if you don't stop for coffee along the way!

But don't worry, I won't tell your boss. Go ahead and grab that cup of java. You've earned it.

Resources

Cosmos DB for Spring Developers, Part I: Using Cosmos DB as a SQL Database

Mark Heckler — Fri, 19 Aug 2022 00:31:04 +0000

One of the key benefits of working with any Spring project, from Spring Framework to Spring Boot, Spring Data to Spring Cloud, is the developer-first focus each of those projects takes to delivering capabilities. This manifests in several ways, but the ways on which I want to focus with this series of articles are flexibility and scalability, especially with regard to database connectivity.

Delivering Value

The vast majority of systems and the applications that constitute them provide most of their value via data, whether it be via storage/retrieval, manipulation/analysis, transport/exchange, or some combination of these or other operations. As developers, data permeates aspects of everything we do, and yet we often don't give data considerations the same level of attention that we do our apps and the logic contained therein.

This may be due to the wealth of options we have - or assume, or even hope we have - at our disposal. But many times, it's largely due to the immediacy of the "demands of now": getting functionality developed, tested, and deployed, so we can move on to the next bit of needed functionality. There is no shortage of requirements after all; our customers and community are racing to provide their customers and community the functionality they need as well.

Spring Boot and Spring Data

Spring Boot and Spring Data enable us as developers to "get it done" effectively. Both are force multipliers, levers and fulcrums that take the heavy lifting of boilerplate and ceremony, replacing repetitious patterns to which we developers have grown numb with software-driven opinions. If you have to do the same handful of steps as setup and teardown (for example) with little or no variation every time you perform a set of basic operations, chances are those surrounding steps can be incorporated into an opinion, implemented as a convention one follows within Spring Boot (instead of a manual configuration), and streamlined away from the top level of developer concern. There must be ways to tweak, configure, and disable these steps for edge cases of course, but this is what Spring Boot does as a matter of course.

Spring Data adds convention over configuration and when used in a Spring Boot application, Boot's autoconfiguration makes accessing data via Spring Data straightforward via a variety of mechanisms: the Java Persistence API (JPA), Java Database Connectivity (JDBC), and various NoSQL database drivers for document, wide table, caching, in-memory, and graph databases to mention a few.

Let's talk about that Data

What Spring Data doesn't do is make determinations of scalability and suitability of various database implementations for a specific purpose or targeted use case. As technologists, that is for us to determine.

Sometimes we accurately anticipate functional and non-functional requirements. Sometimes scope and scalability requirements remain reasonably close to expectations. And sometimes, when amazing things happen and our systems gain far greater traction and a much wider user base than we could have anticipated, we must scale everything quickly and effectively, both our systems and the data on which they depend and use to provide such meaningful value. That's where Cosmos DB comes in.

Cosmos DB

Azure Cosmos DB is a planetary-scale data store that offers various ways and APIs to manage your critical data and provide access to it from anywhere at breathtaking speed. Spring Developers can leverage the power of Cosmos DB via Spring Boot starters, among other means, and those starters are built and maintained by Microsoft developers as natural complements to the opinions built into Spring Boot and Spring Data. Developing applications using Cosmos DB is easy and requires no adjustments to a developer's existing mental processes.

One powerful facet of Cosmos DB is its chameleon-like quality of fulfilling developers' needs for various APIs and storage mechanisms. Cosmos DB can operate and be interacted with as a SQL database, a MongoDB(tm) document database, a Cassandra(tm) wide table database, and more: each one at planetary scale and speed, each one with little or no adjustment to your applications needed.

For this article, I focus on the SQL engine and API for Cosmos DB, as leveraged from a Spring Boot application. Let's get started!

Initialization and configuration

The script CosmosInitEnv.sh should be sourced by executing it in this manner from a terminal window:

source ./CosmosInitEnv.sh

To verify environment variables are set as expected, I like to check the environment using a command similar to the following:

env | sort

env | grep COSMOSDB

To create the Azure resources we will need for this project, we then source the CosmosConfig.sh script as follows:

source ./CosmosConfig.sh

Two things of note. First, this again assumes you are executing this script from the current (.) directory. Second, since we once again set environment variable values that we plan to use after the script finishes execution, we must source this script as well. Failure to do isn't catastrophic, but it will result in empty variables and will require manually executing the final two lines from CosmosConfig.sh in the terminal in order to proceed.

You can verify all environment variables are now set using this or similar command:

env | grep COSMOSDB_SQL

These three env vars are essential to the app we're about to create:

COSMOSDB_SQL_URL
COSMOSDB_SQL_KEY
COSMOSDB_SQL_NAME

If all three variables' values are present, we can proceed to the next step and build an application.

Create a Spring Boot app

There are many ways to begin creating a Spring Boot application, but I prefer to begin with the Spring Initializr. Choose a meaningful artifact name, change the group name if you so choose, then select the dependencies as shown in the following screen capture.

Create and open the project

NOTE: All code is in a Github repository linked at the bottom of this article.

I use only three dependencies for this example:

Reactive Web includes all dependencies to create web apps using reactive streams, non-blocking and/or imperative APIs
Azure Cosmos DB enables your app to access Cosmos DB using the SQL API
Lombok is a boilerplate-reducing library, useful for domain classes, logging, and more



<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-webflux</artifactId>
</dependency>
<dependency>
    <groupId>com.azure.spring</groupId>
    <artifactId>spring-cloud-azure-starter-data-cosmos</artifactId>
</dependency>
<dependency>
    <groupId>org.projectlombok</groupId>
    <artifactId>lombok</artifactId>
    <optional>true</optional>
</dependency>

Set required properties

Next, we must specify a few properties for our application to use in its initialization for Spring Boot's autoconfiguration to make the connection with the desired Cosmos DB instance. Open the application.properties file in the project (under src/main/resources) and add the following parameters:



spring.cloud.azure.cosmos.endpoint=${COSMOSDB_SQL_URL}
spring.cloud.azure.cosmos.key=${COSMOSDB_SQL_KEY}
spring.cloud.azure.cosmos.database=${COSMOSDB_SQL_NAME}

There are many ways for a Spring Boot app to ingest properties from its environment, but for this article, we'll simply use SpEL (Spring Expression Language) variables that map to underlying environment variables with values assigned by the scripts we sourced earlier from the command line.

Code the application

I'll start with a streamlined example for this article and plan to build out in follow-on posts.

The domain

First, I code a domain class. In this example, I create a User class with an id, firstName, lastName, and address member variables. This class and its properties are annotated thusly:

@Container(containerName = "data") represents the container name within Cosmos DB
@Data is a Lombok annotation that instructs the Lombok compile-time code generator to consider this a "data class" and generate accessors (getters) and mutators (setters) for each member variable, along with equals(), hashCode(), and toString() methods
@NoArgsConstructor is a Lombok annotation that instructs Lombok to generate a zero-argument constructor
@RequiredArgsConstructor is a Lombok annotation that instructs Lombok to generate a constructor with a parameter for each "required" member variable, as designated by the @NonNull member variable annotation
@Id indicates which member variable corresponds to the underlying table's primary key
@GeneratedValue specifies that the underlying data store will generate this value, i.e. it does not need to be provided by the application
@NonNull is addressed under @RequiredArgsConstructor
@PartitionKey corresponds to the key used by Cosmos DB to partition data stored for this domain entity for access optimization

NOTE: In this code, I use lastName as the partition key. This is a terrible choice in most cases, as it typically doesn't provide a meaningful and/or reasonably even grouping of entities for optimizing access. I use it in this simplified example for expediency and would strongly encourage the reader to research partitions with specific domains/data in mind. Choose wisely.

The repository

Spring Boot's autoconfiguration takes the power of Spring Data and amplifies it. By including a database driver in your classpath (including it as a dependency in your build file results in its inclusion for deployment) and extending a Spring Data-derived interface in your application code, Spring Boot's autoconfiguration creates the beans necessary to provide a proxy to the desired underlying datastore. In our case, this is all we need to provide foundational database capabilities:



interface UserRepository extends ReactiveCosmosRepository<User, String> {}

In this single line of code, we are defining an interface called UserRepository that will inherit and potentially extend the capabilities of the ReactiveCosmosRepository, storing objects of type User with identifiers (IDs) of type String. Autoconfig does the rest.

NOTE: We can do more, of course, defining custom query methods and more. But for this example, the provided functionality is sufficient.

The API

Next, I define the Application Programming Interface (API) that provides the means and structure for external applications to interact with this service. Once again the focus is on simplicity, and I define only a single HTTP endpoint that provides a JSON listing (by default) of all Users upon request.



@RestController
@AllArgsConstructor
class CosmosSqlController {
    private final UserRepository repo;

    @GetMapping
    Flux<User> getAllUsers() {
        return repo.findAll();
    }
}

The @RestController annotation is provided by the Spring Framework and combines the functionality of @Controller, to respond to requests, and @ResponseBody, to make the resultant object(s) the response body itself rather than just providing access to the object(s) via a model variable, as is the typical MVC methodology.

The @AllArgsConstructor annotation instructs Lombok to create a constructor for the CosmosSqlController class with a parameter (and thus required argument) for every member variable. Since the only member variable is a UserRepository, Lombok generates a ctor with that single parameter.

The data

To create a bit of sample data, I create a Spring bean using the @Component annotation. This annotation instructs Spring Boot, upon application initialization, to create an instance of the annotated class and place that object (bean) into the application context, i.e. its Dependency Injection (DI) container. All beans in the DI container are managed by the Spring Boot application in terms of lifecycle and, of course, injection into other code as dependencies.

Once the bean is constructed, the loadData() method is executed automatically due to the @PostConstruct annotation. In this application, the loadData() method deletes all data in the underlying datastore, populates it with two sample User records, returns all User records now stored in the database, and logs them to the console for verification.

NOTE: The Reactive Streams API and the implementation of it as provided by Spring WebFlux/Project Reactor is beyond the scope of this particular article. Please consult the appropriate documentation at the 'Web on Reactive Stack' Spring documentation site, any of several sessions I've delivered available on my YouTube channel, or by visiting the Reactive Streams and Project Reactor sites.



@Slf4j

@Component

@AllArgsConstructor

class DataLoader {

    private final UserRepository repo;

@PostConstruct
void loadData() {
    repo.deleteAll()
            .thenMany(Flux.just(new User("Alpha", "Bravo", "123 N 4567th St"),
                    new User("Charlie", "Delta", "1313 Mockingbird Lane")))
            .flatMap(repo::save)
            .thenMany(repo.findAll())
            .subscribe(user -&gt; log.info(user.toString()));
}



}

Demo

To access the environment variables set earlier as a result of sourcing the config script, we will need to build and run the Spring Boot application from the command line. From the project directory, execute the following command to build and run the project:

mvn spring-boot:run

To verify the application is able to access the Cosmos DB instance and return the correct data, execute the following command from another terminal window:

curl http://localhost:8080

Alternatively, you can access http://localhost:8080 from a browser tab or window.

The following should be displayed:



» http :8080 

HTTP/1.1 200 OK

Content-Type: application/json

transfer-encoding: chunked

[

    {

        "address": "123 N 4567th St",

        "firstName": "Alpha",

        "id": "dcaca409-da66-4d53-9268-e6313b48bdd7",

        "lastName": "Bravo"

    },

    {

        "address": "1313 Mockingbird Lane",

        "firstName": "Charlie",

        "id": "14cf1b9b-f8c2-401b-affe-770fcaaacea3",

        "lastName": "Delta"

    }

]

Summary

One of the key benefits of using Spring Boot to develop Java (and Kotlin) applications is its developer-first focus. Spring Boot's flexibility and scalability, especially with regard to database connectivity, makes tapping into the power of a planetary-scale database such as Cosmos DB amazingly straightforward for developers. This lets devs concentrate on functionality that meets their stakeholders' needs and helps drive their organization forward, knowing that their data is safe, scalable, and accessible from anywhere Azure is reachable, e.g. planet Earth.

Resources

A Concise Guide to Using Multiple Azure Storage Accounts from a Single Spring Boot Application

Mark Heckler — Mon, 18 Jul 2022 20:36:16 +0000

Spring projects in general are opinionated: 80-90% of use cases are handled "by default", and code is often much more concise than would be required otherwise due to Spring's preference of convention over configuration. These and other "opinions" can result in dramatically less code to write and maintain and as a result, more focused impact.

In the vast majority of cases where Azure Storage is used from an application, there is no compelling advantage to using more than a single Azure storage account. But there are edge cases, and having the ability to use multiple Azure Storage accounts from a single app - even if we might only need that capability around 10% of the time - could provide an incredibly useful extension of our storage superpowers.

This article is the result of a collaboration with Shi li Chen.

It's all about resources

The Spring Framework defines the Resource interface and provides several implementations built upon Resource to facilitate developer access to low-level resources. In order to handle a particular kind of resource, two things are required:

A Resource implementation
A ResourcePatternResolver implementation

A Spring application evaluates resources in question using one or more registered resolvers. When the type of resource is identified, the appropriate Resource implementation is used to access and/or manipulate the underlying resource.

If the implementations built into Spring Framework don't fulfill your use case, it's fairly straightforward to add support for additional types of resources by defining your own implementations of AbstractResource and ResourcePatternResolver interfaces.

This article will introduce the Spring Resource, review Spring Cloud Azure's implementation of Spring's Resource (especially with regard to Azure Storage Account considerations and limitations), and consider how to expand said implementation to address those edge cases in which it would be useful to access multiple Azure Storage Accounts from a single Spring Boot application.

Getting resourceful

We've already mentioned that the Spring Framework defines several useful Resource implementations. As of this writing, the default types are:

UrlResource
ClassPathResource
FileSystemResource
PathResource
ServletContextResource
InputStreamResource
ByteArrayResource

As mentioned earlier, each resource will have a corresponding resource resolver.

Enabling your Spring Boot application to use a custom Resource requires the following actions:

Implement the Resource interface by extending AbstractResource
Implement the ResourcePatternResolver interface to resolve the custom resource type
Register the implementation of ResourcePatternResolver as a bean

NOTE: Your resolver must be added to the default resource loader's resolver set using the org.springframework.core.io.DefaultResourceLoader#addProtocolResolver method, but this code is present in AbstractAzureStorageProtocolResolver; extending that class to create your implementation accomplishes this on your behalf unless you choose to override its setResourceLoader method.

A ResourceLoader attempts to resolve each Resource by comparing its defined location/format with all registered protocol pattern resolvers until a non-null resource is returned. If no match is found, the Resource will be evaluated against Spring's built-in pattern resolvers.

Spring resources in Spring Cloud Azure

Spring Cloud Azure provides two Spring resource and resource pattern resolver implementations. In this article, we only discuss the implementation of the Azure Storage Blob resource. You can examine the source code for Spring Cloud Azure Resources at Spring Cloud Azure and related documentation at Resource Handling.

NOTE: We use Spring Cloud Azure Starter Storage Blob version 4.2.0 for analysis and experiments.

Implementation of `AbstractResource`

The abstract implementation AzureStorageResource for Spring Cloud Azure primarily defines the format of the Azure storage resource protocol and accommodates the unique attributes of the Azure Storage Account service, e.g. the container name and file name. It is important to note that AzureStorageResource is decoupled from the Azure Storage SDK.

The Spring Framework interface WritableResource represents the underlying API we build upon to read from and write to the Azure Storage resource.

abstract class AzureStorageResource extends AbstractResource implements WritableResource {

    private boolean isAzureStorageResource(@NonNull String location) {
        ......
    }

    String getContainerName(String location) {
        ......
    }

    String getContentType(String location) {
        ......
    }

    String getFilename(String location) {
        ......
    }

    abstract StorageType getStorageType();
}

The StorageBlobResource is Spring Cloud Azure Storage Blob's implementation of the abstract class AbstractResource.
We can see StorageBlobResource uses the BlobServiceClient from the Azure Storage Blob SDK to implement all abstract methods, relying on the service client to interact with the Azure Storage Blob service.

public final class StorageBlobResource extends AzureStorageResource {
    private final BlobServiceClient blobServiceClient;
    private final BlobContainerClient blobContainerClient;
    private final BlockBlobClient blockBlobClient;

    public StorageBlobResource(BlobServiceClient blobServiceClient, String location, Boolean autoCreateFiles,
                               String snapshot, String versionId, String contentType) {
        ......
        this.blobContainerClient = blobServiceClient.getBlobContainerClient(getContainerName(location));
        BlobClient blobClient = blobContainerClient.getBlobClient(getFilename(location));
        this.blockBlobClient = blobClient.getBlockBlobClient();
    }

    @Override
    public OutputStream getOutputStream() throws IOException {
        try {
            ......
            return this.blockBlobClient.getBlobOutputStream(options);
        } catch (BlobStorageException e) {
            throw new IOException(MSG_FAIL_OPEN_OUTPUT, e);
        }
    }

    ......

    @Override
    StorageType getStorageType() {
        return StorageType.BLOB;
    }
}

Implementation of `ResourcePatternResolver`

Spring Cloud Azure provides an abstract implementation AbstractAzureStorageProtocolResolver. This class incorporates general processing of the Azure storage resource protocol, exposes specific capabilities of the Azure Storage Account service, and adds the requisite logic to the default resource loader. Like AzureStorageResource, the AbstractAzureStorageProtocolResolver is also not coupled to the Azure Storage SDK.

public abstract class AbstractAzureStorageProtocolResolver implements ProtocolResolver, ResourcePatternResolver,
    ResourceLoaderAware, BeanFactoryPostProcessor {

    protected final AntPathMatcher matcher = new AntPathMatcher();

    protected abstract StorageType getStorageType();

    protected abstract Resource getStorageResource(String location, Boolean autoCreate);

    protected ConfigurableListableBeanFactory beanFactory;

    protected abstract Stream<StorageContainerItem> listStorageContainers(String containerPrefix);

    protected abstract StorageContainerClient getStorageContainerClient(String name);

    @Override
    public void setResourceLoader(ResourceLoader resourceLoader) {
        if (resourceLoader instanceof DefaultResourceLoader) {
            ((DefaultResourceLoader) resourceLoader).addProtocolResolver(this);
        } else {
            LOGGER.warn("Custom Protocol using azure-{}:// prefix will not be enabled.", getStorageType().getType());
        }
    }

    @Override
    public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException {
        this.beanFactory = beanFactory;
    }

    @Override
    public Resource resolve(String location, ResourceLoader resourceLoader) {
        if (AzureStorageUtils.isAzureStorageResource(location, getStorageType())) {
            return getResource(location);
        }
        return null;
    }

    @Override
    public Resource[] getResources(String pattern) throws IOException {
        Resource[] resources = null;

        if (AzureStorageUtils.isAzureStorageResource(pattern, getStorageType())) {
            if (matcher.isPattern(AzureStorageUtils.stripProtocol(pattern, getStorageType()))) {
                String containerPattern = AzureStorageUtils.getContainerName(pattern, getStorageType());
                String filePattern = AzureStorageUtils.getFilename(pattern, getStorageType());
                resources = resolveResources(containerPattern, filePattern);
            } else {
                return new Resource[] { getResource(pattern) };
            }
        }
        if (null == resources) {
            throw new IOException("Resources not found at " + pattern);
        }
        return resources;
    }

    @Override
    public Resource getResource(String location) {
        Resource resource = null;

        if (AzureStorageUtils.isAzureStorageResource(location, getStorageType())) {
            resource = getStorageResource(location, true);
        }

        if (null == resource) {
            throw new IllegalArgumentException("Resource not found at " + location);
        }
        return resource;
    }

    /**
     * Storage container item.
     */
    protected static class StorageContainerItem {
        private final String name;
        ......
    }

    protected static class StorageItem {

        private final String container;
        private final String name;
        private final StorageType storageType;
        ......
    }

    protected interface StorageContainerClient {

        ......
    }
}

The resource resolver AzureStorageBlobProtocolResolver is Spring Cloud Azure Storage Blob's implementation of ResourcePatternResolver. It encapsulates resources according to the location or storage item pattern based on BlobServiceClient and returns the associated StorageBlobResource.

public final class AzureStorageBlobProtocolResolver extends AbstractAzureStorageProtocolResolver {

    private BlobServiceClient blobServiceClient;
    @Override
    protected StorageType getStorageType() {
        return StorageType.BLOB;
    }

    @Override
    protected Resource getStorageResource(String location, Boolean autoCreate) {
        return new StorageBlobResource(getBlobServiceClient(), location, autoCreate);
    }

    private BlobServiceClient getBlobServiceClient() {
        if (blobServiceClient == null) {
            blobServiceClient = beanFactory.getBean(BlobServiceClient.class);
        }
        return blobServiceClient;
    }
}

Opinions

As mentioned at the beginning of this post, the default capabilities fulfill the requirements admirably in the vast majority of circumstances. But in accordance with the Spring ethos, Spring Cloud Azure Starter Storage Blob was designed to seamlessly address 80-90% of use cases "out of the box", while still allowing for remaining (edge) cases with some extra effort.

As written, the storage blob resource supports multiple container operations using the same storage account. The salient point is that the blob paths under different containers can be properly resolved into StorageBlobResource objects. Combining the earlier code for StorageBlobResource, the blob resource must hold a blob service client, and if blobServiceClient.getBlobContainerClient(getContainerName(location)) successfully returns a BlobServiceClient, the blob resource can be resolved and retrieved.

The BlobServiceClient bean represents an Azure Storage Account in the Azure Storage Blob SDK, meaning that the current implementation does not support simultaneous availability using multiple Azure Storage Accounts.

Developing an extended version of Spring Cloud Azure Starter Storage Blob

For those rare cases in which it might be useful to simultaneously access multiple Azure Storage accounts from the same application, there is a way to make that happen. To demonstrate this capability, let's create a new library called spring-cloud-azure-starter-storage-blob-extend. The only external dependency for this new library is the existing spring-cloud-azure-starter-storage-blob.

Extend the Storage Blob properties

While the primary goal is to support multiple storage accounts, a secondary design goal is to use a similar structure to AzureStorageBlobProperties in order to minimize the learning curve and to retain Spring Cloud Azure 4.0's out of the box authentication features.

public class ExtendAzureStorageBlobsProperties {

    public static final String PREFIX = "spring.cloud.azure.storage.blobs";

    private boolean enabled = true;

    private final List<AzureStorageBlobProperties> configurations = new ArrayList<>();

    public boolean isEnabled() {
        return enabled;
    }

    public void setEnabled(boolean enabled) {
        this.enabled = enabled;
    }

    public List<AzureStorageBlobProperties> getConfigurations() {
        return configurations;
    }
}

Dynamically register Storage Blob beans

Since there will be multiple Storage Account configurations, we must name the beans corresponding to each storage account. The cleanest approach is to simply use the account name as the bean name.

Now, let's dynamically register these beans with the Spring context.

@Configuration(proxyBeanMethods = false)
@ConditionalOnProperty(value = { "spring.cloud.azure.storage.blobs.enabled"}, havingValue = "true")
public class ExtendStorageBlobsAutoConfiguration implements BeanDefinitionRegistryPostProcessor, EnvironmentAware {

    private Environment environment;

    public static final String EXTEND_STORAGE_BLOB_PROPERTIES_BEAN_NAME = "extendAzureStorageBlobsProperties";

    @Override
    public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException {
        AzureGlobalProperties azureGlobalProperties =
            Binder.get(environment)
                  .bind(AzureGlobalProperties.PREFIX, AzureGlobalProperties.class)
                  .orElse(new AzureGlobalProperties());
        ExtendAzureStorageBlobsProperties blobsProperties =
            Binder.get(environment)
                  .bind(ExtendAzureStorageBlobsProperties.PREFIX, ExtendAzureStorageBlobsProperties.class)
                  .orElseThrow(() -> new IllegalArgumentException("Can not bind the azure storage blobs properties."));
        // merge properties
        for (AzureStorageBlobProperties azureStorageBlobProperties : blobsProperties.getConfigurations()) {
            AzureStorageBlobProperties transProperties = new AzureStorageBlobProperties();
            AzureGlobalPropertiesUtils.loadProperties(azureGlobalProperties, transProperties);
            copyAzureCommonPropertiesIgnoreTargetNull(transProperties, azureStorageBlobProperties);
        }

        DefaultListableBeanFactory factory = (DefaultListableBeanFactory) beanFactory;
        registryBeanExtendAzureStorageBlobsProperties(factory, blobsProperties);
        blobsProperties.getConfigurations().forEach(blobProperties -> registryBlobBeans(factory, blobProperties));
    }

    private void registryBeanExtendAzureStorageBlobsProperties(DefaultListableBeanFactory beanFactory,
                                                               ExtendAzureStorageBlobsProperties blobsProperties) {
        BeanDefinitionBuilder beanDefinitionBuilder = BeanDefinitionBuilder.genericBeanDefinition(ExtendAzureStorageBlobsProperties.class,
            () -> blobsProperties);
        AbstractBeanDefinition rawBeanDefinition = beanDefinitionBuilder.getRawBeanDefinition();
        beanFactory.registerBeanDefinition(EXTEND_STORAGE_BLOB_PROPERTIES_BEAN_NAME, rawBeanDefinition);
    }

    private void registryBlobBeans(DefaultListableBeanFactory beanFactory, AzureStorageBlobProperties blobProperties) {
        String accountName = getStorageAccountName(blobProperties);
        Assert.hasText(accountName, "accountName can not be null or empty.");
        registryBeanStaticConnectionStringProvider(beanFactory, blobProperties, accountName);
        registryBeanBlobServiceClientBuilderFactory(beanFactory, blobProperties, accountName);
        registryBeanBlobServiceClientBuilder(beanFactory, accountName);
        registryBeanBlobServiceClient(beanFactory, accountName);
        registryBeanBlobContainerClient(beanFactory, blobProperties, accountName);
        registryBeanBlobClient(beanFactory, blobProperties, accountName);
    }

    private void registryBeanBlobServiceClientBuilder(DefaultListableBeanFactory beanFactory,
                                                      String accountName) {
        BeanDefinitionBuilder beanDefinitionBuilder = BeanDefinitionBuilder.genericBeanDefinition(BlobServiceClientBuilder.class,
            () -> {
                BlobServiceClientBuilderFactory builderFactory =
                    beanFactory.getBean(accountName + BlobServiceClientBuilderFactory.class.getSimpleName(),
                        BlobServiceClientBuilderFactory.class);
                return builderFactory.build();
            });
        AbstractBeanDefinition rawBeanDefinition = beanDefinitionBuilder.getRawBeanDefinition();
        beanFactory.registerBeanDefinition(
            accountName + BlobServiceClientBuilder.class.getSimpleName(), rawBeanDefinition);
    }

    ......

    @Override
    public void setEnvironment(Environment environment) {
        this.environment = environment;
    }
}

Extend the `AzureStorageBlobProtocolResolver`

The next task is to make any container resolvable by the same resource pattern resolver. Specifying a storage blob resource location such as azure-blob-accountname://containername/test.txt, the resolver will use that to locate the appropriate BlobServiceClient bean by Azure Storage Account name and return the storage resource.

public class ExtendAzureStorageBlobProtocolResolver extends ExtendAbstractAzureStorageProtocolResolver {
    private final Map<String, BlobServiceClient> blobServiceClientMap = new HashMap<>();

    @Override
    protected Resource getStorageResource(String location, Boolean autoCreate) {
        return new ExtendStorageBlobResource(getBlobServiceClient(location), location, autoCreate);
    }

    private BlobServiceClient getBlobServiceClient(String locationPrefix) {
        String storageAccount = ExtendAzureStorageUtils.getStorageAccountName(locationPrefix, getStorageType());
        Assert.notNull(storageAccount, "storageAccount can not be null.");
        String accountKey = storageAccount.toLowerCase(Locale.ROOT);
        if (blobServiceClientMap.containsKey(accountKey)) {
            return blobServiceClientMap.get(accountKey);
        }

        BlobServiceClient blobServiceClient = beanFactory.getBean(
            accountKey + BlobServiceClient.class.getSimpleName(), BlobServiceClient.class);
        Assert.notNull(blobServiceClient, "blobServiceClient can not be null.");
        blobServiceClientMap.put(accountKey, blobServiceClient);
        return blobServiceClient;
    }
}

Again, you need to add the bean ExtendAzureStorageBlobProtocolResolver to the Spring context.

Testing the Spring Cloud Azure Starter Storage Blob Extend

You can use start.spring.io to generate a Spring Boot 2.6.7 or greater project with Azure Storage support (or build on this storage blob sample if you prefer).

Add the extending starter dependency to the pom.xml file:

<dependency>
  <groupId>com.azure.spring.extend</groupId>
  <artifactId>spring-cloud-azure-starter-storage-blob-extend</artifactId>
  <version>1.0-SNAPSHOT</version>
</dependency>

Delete the src/main/resources/application.properties file or add the following configuration file application-extend.yml, which enables multiple storage account usage:

application-extend.yml

spring:
  cloud:
    azure:
      storage:
        blob:
          enabled: false
        blobs:
          enabled: true
          configurations:
            - account-name: ${FIRST_ACCOUNT}
              container-name: ${FIRST_CONTAINER}
              account-key: ${ACCOUNT_KEY_OF_FIRST_ACCOUNT}
            - account-name: ${SECOND_ACCOUNT}
              container-name: ${SECOND_CONTAINER}
              account-key: ${ACCOUNT_KEY_OF_SECOND_ACCOUNT}

NOTE: You must provide values for the environment variables above (listed in all capital letters) with active Azure Storage Account resource information.

Add class com.azure.spring.extend.sample.storage.resource.extend.SampleDataInitializer with the following body:

@Profile("extend")
@Component
public class SampleDataInitializer implements CommandLineRunner {
    final static Logger logger = LoggerFactory.getLogger(SampleDataInitializer.class);

    private final ConfigurableEnvironment env;

    private final ExtendAzureStorageBlobProtocolResolver resolver;
    private final ExtendAzureStorageBlobsProperties properties;

    public SampleDataInitializer(ConfigurableEnvironment env, ExtendAzureStorageBlobProtocolResolver resolver,
                                 ExtendAzureStorageBlobsProperties properties) {
        this.env = env;
        this.resolver = resolver;
        this.properties = properties;
    }

    /**
     * This is used to initialize some data for each Azure Storage Account Blob container.
     */
    @Override
    public void run(String... args) {
        properties.getConfigurations().forEach(this::writeDataByStorageAccount);
    }

    private void writeDataByStorageAccount(AzureStorageBlobProperties blobProperties) {
        String containerName = blobProperties.getContainerName();
        if (!StringUtils.hasText(containerName) || blobProperties.getAccountName() == null) {
            return;
        }

        String accountName = getStorageAccountName(blobProperties);
        logger.info("Begin to initialize the {} container of the {} account", containerName, accountName);
        long currentTimeMillis = System.currentTimeMillis();
        String fileName = "fileName-" + currentTimeMillis;
        String data = "data" + currentTimeMillis;
        Resource storageBlobResource = resolver.getResource("azure-blob-" + accountName + "://" + containerName +"/" + fileName + ".txt");
        try (OutputStream os = ((WritableResource) storageBlobResource).getOutputStream()) {
            os.write(data.getBytes());
            logger.info("Write data to container={}, fileName={}.txt", containerName, fileName);
        } catch (IOException e) {
            logger.error("Write data exception", e);
        }
        logger.info("End to initialize the {} container of the {} account", containerName, accountName);
    }
}

Run the sample with following Maven command:

mvn clean spring-boot:run -Dspring-boot.run.profiles=extend

Finally, verify the expected outcome. Your console should display the following output:

c.a.s.e.s.s.r.e.SampleDataInitializer    : Begin to initialize the container first of the account firstaccount.
c.a.s.e.s.s.r.e.SampleDataInitializer    : Write data to container=first, fileName=fileName-1656641340271.txt
c.a.s.e.s.s.r.e.SampleDataInitializer    : End to initialize the container first of the account firstaccount.
c.a.s.e.s.s.r.e.SampleDataInitializer    : Begin to initialize the container second of the account secondaccount.
c.a.s.e.s.s.r.e.SampleDataInitializer    : Write data to container=second, fileName=fileName-1656641343572.txt
c.a.s.e.s.s.r.e.SampleDataInitializer    : End to initialize the container second of the account secondaccount.

All sample project code is published at the repository spring-cloud-azure-starter-storage-blob-extend-sample.

Within this extended application, it's still possible to revert to the original, single storage account usage of Spring Cloud Azure Starter Storage Blob by adding the following configuration file application-current.yml:

spring:
  cloud:
    azure:
      storage:
        blob:
          account-name: ${FIRST_ACCOUNT}
          container-name: ${FIRST_CONTAINER}
          account-key: ${ACCOUNT_KEY_OF_FIRST_ACCOUNT}
current:
  second-container: ${SECOND_CONTAINER}

NOTE: You must set or replace the listed environment variable assigned values with active Azure Storage Account resource information.

Run the sample with following Maven command:

mvn clean spring-boot:run -Dspring-boot.run.profiles=current

To verify correct operation using a single storage account, compare terminal output with that listed here:

c.a.s.e.s.s.r.c.SampleDataInitializer    : StorageApplication data initialization of 'first-container' begin ...
c.a.s.e.s.s.r.c.SampleDataInitializer    : Write data to container=first-container, fileName=fileName1656641162614.txt
c.a.s.e.s.s.r.c.SampleDataInitializer    : StorageApplication data initialization of 'first-container' end ...
c.a.s.e.s.s.r.c.SampleDataInitializer    : StorageApplication data initialization of 'second-container' begin ...
c.a.s.e.s.s.r.c.SampleDataInitializer    : Write data to container=second-container, fileName=fileName1656641165411.txt
c.a.s.e.s.s.r.c.SampleDataInitializer    : StorageApplication data initialization of 'second-container' end ...

Conclusion

Implementing a specific resource type and corresponding pattern resolver is relatively simple, largely thanks to clear documentation, the many built-in implementations, common usage within the Spring technology stack.

One point that warrants attention is the protocol definition for the resource, e.g. the Azure Storage Blob Resource. We must note whether we are using azure-blob:// or azure-blob-[account-name]:// and plan app capabilities accordingly. Additionally, since the identifier of a network resource must be uniquely identifiable, the latter location format may result in a much longer name and also exposes the name of the storage account. These tradeoffs need to be evaluated in light of requirements and risk profile.

DEV Community: Mark Heckler

Cosmos DB for Spring Developers, Part II: Using Cosmos DB as a MongoDB Database

Azure Cosmos DB for MongoDB

Create a Spring Boot app

Create and open the project

Code the application

The domain

The repository

The API

The data

Demo, take 1

"Migrating" our app to Azure Cosmos DB for MongoDB

Initialization and configuration

Changing the application

Demo, take 2

Summary

Resources

Cosmos DB for Spring Developers, Part I: Using Cosmos DB as a SQL Database

Delivering Value

Spring Boot and Spring Data

Let's talk about that Data

Cosmos DB

Initialization and configuration

Create a Spring Boot app

Create and open the project

Set required properties

Code the application

The domain

The repository

The API

The data

Demo

Summary

Resources

A Concise Guide to Using Multiple Azure Storage Accounts from a Single Spring Boot Application

It's all about resources

Getting resourceful

Spring resources in Spring Cloud Azure

Implementation of AbstractResource

Implementation of ResourcePatternResolver

Opinions

Developing an extended version of Spring Cloud Azure Starter Storage Blob

Extend the Storage Blob properties

Dynamically register Storage Blob beans

Extend the AzureStorageBlobProtocolResolver

Testing the Spring Cloud Azure Starter Storage Blob Extend

Conclusion

References & Useful Resources

Implementation of `AbstractResource`

Implementation of `ResourcePatternResolver`

Extend the `AzureStorageBlobProtocolResolver`