Photo credit Just before the holidays, I was working on writing some more lesson content for a Spring Data Neo4j course. To save an entity to the database, I needed to pass a JSON object containing the entity’s properties to a Spring Boot controller method. Each time I wanted to test the code, I had to manually create the JSON object and pass it to the controller method on the command line.

Photo credit I have recently been working on a self-paced learning course for Spring Data Neo4j and wanted users to be able to test the database connection. Typically, in a Spring Boot application with Spring Data, you set the database credentials as properties in the application.properties file. You can run the application with just these details, but it only fails when the database URI has improper syntax. The application does not actually test the connection to see if it is valid and successfully connects.

Photo credit I was working on a Spring Data Neo4j example application for a community user’s question, and I kept running into the error below when I defined bidirectional relationship in the domain classes. 2023-08-10T13:00:17.341-05:00 ERROR 98493 --- [nio-8080-exec-1] o.a.c.c.C.[.[.[/].[dispatcherServlet] : Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed: org.springframework.dao.TransientDataAccessResourceException: Server at 408637a4.databases.neo4j.io:7687 is no longer available; Error code 'N/A'] with root cause org.

Photo credit I recently started work on a joint project with my colleague, Jason Koo. For this project, we want to import data from second brain apps (such as Obsidian, Notion, Evernote, etc) to Neo4j. Since I use Evernote, I was tasked with getting my notes out of Evernote. In this post, I will show you how to use the Evernote API and SDK in a Spring Boot application to retrieve data from Evernote.

Photo credit As I was incorporating Kafka to my microservices project, I ran across some trouble updating an entity in Neo4j using Spring Data Neo4j. My data set contains books, authors, book reviews, and users. Based on a new review getting entered into the system, I want to create that review, and then update the related Book entity with an incremented review count and calculate a new average rating. The new review entity was being created with no issues, but I was struggling to get the update to the related Book entity working.

Photo credit I was working on a Spring Data Neo4j microservice application to add a write method for saving a new book review to the database, when I came across the error message below. org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'reactiveTransactionManager' available: No matching TransactionManager bean found for qualifier 'reactiveTransactionManager' - neither qualifier match nor bean name match! The stacktrace was long and ugly, and I had come across this error before…​but I could not remember how I had solved it.

Photo credit Gaining complexity in a microservices system certainly isn’t for the faint of heart (though neither is complexity in monoliths!). When there are many services that need to communicate with one another, we might need to coordinate multiple services communicating with multiple other services. We also might code for varying environments such as local, development server, or the cloud. How do services know where to find one another? How can we avoid problems when a service is unavailable?

Photo credit Our microservices project contains quite a few pieces now. We have two databases, three API services, a user-view service for books, and a service to host our configuration. With so many pieces to manage, it would be nice to have something that orchestrates the individual services into a system, such as Docker Compose. Back in our Level 5 rendition, we did exactly this for our smaller version of the project.

Photo credit In our last blog post, we used Spring Cloud Config to provide database credentials to a microservice application connecting to a cloud-hosted Neo4j database. This post will backport this concept to our existing MongoDB database instance and its related microservices. We will add our MongoDB credentials to the config server, so that it will be the central place for both our Neo4j and MongoDB database access. However, each service only has access to the credentials that it needs to operate, which provides some level of security through "separation of concerns" (versus universal access).

Photo credit Our decided next step for this project takes us in a new direction by adding externalized configuration for our applications. We already saw how to do something similar with MongoDB database credentials in Docker Compose to access a local database container, but what do we do when the database is hosted on public cloud or contains sensitive data? We probably don’t want to publish our credentials anywhere or even prevent accidental publishing.

Photo credit For our next adventure in Java microservices, we want to expand our system for book review data. While books and authors are well-suited for a document database such as MongoDB, once you add reviews to the mix, the importance of the relationships makes this project better suited for a graph database. This way, we can utilize relationships between the different entities to improve analysis based on the structure of the connections.

Photo credit We continue building our microservices system by adding a coordination layer to handle spinning multiple services up and down. In previous blog posts, we grew from two Spring Boot applications to three applications + a database container. As we continue to scale and broaden our system, we will need something to coordinate service and ensure consistent communication (avoid human error). We will do this through docker-compose, an orchestration tool that manages containerized applications.

Photo credit This blog post is the fourth iteration in a series of posts about building microservices in Java. The initial post started with a single string message passed between two locally-running applications, and we are gradually adding services and functionality along the way. In this level 4 installment, we will add a new service that will manage book authors. It will call a database containing a data domain of books and retrieve authors and their information.

Photo credit We are still in the beginning stages of building microservices with Java, but we have already seen how to send and receive communications between two Spring Boot applications. In the first blog post of this series, our two applications transmitted a message string of "Hello, World!". In the second blog post, we took it one step further by embedding a MongoDB database into our service1, added a data domain (books) with four pre-populated entries, and transmitted the Book information between the two applications.

Photo credit In my last blog post, we began building microservices in Java with two Spring Boot applications, passing a "Hello, World!" string from one application to the other. We focused on reduced complexity, minimum previous knowledge, and few components. Next, we can slowly add pieces that simulate microservices projects in the real world. One way to do this is by adding a data domain. Applications often model some scenario in the real world such as maintaining office building temperatures, finding connected devices on a network, or recommending a tv show.

Photo credit Microservices have been used and deployed in businesses and projects for awhile, and there is plenty of content available for architecting them into a system. For my next project, I want to dive into the world of microservices and begin building my own little virtual empire from different kinds of services to find out the complexities, best practices, power, and trouble that comes with them. I will share all my learnings along the way, as well.