How I developed a microservice orchestrating service in Java starting from zero knowledge of Spring Boot
As part of an assessment for a company, I received a problem statement which looked like this-
Prior to this, I knew that Spring Boot could be used for rapid development of a backend service, but I had never worked on any project involving it. After some consultation and discussion with a few of my peers about Spring Boot, and reading up about how Spring Boot can be used for developing production-ready servers, I set out to conquer the world of Spring to build out my APIs.
One week and a massive amount of frantic Googling later, I had my (almost) production-ready APIs looking nice and ready to be demonstrated. The sheer abundance of resources available on Spring proved to be a boon and a bane, considering that almost every error that one can face has been answered on stackoverflow(or a blogpost), but due to ever-changing versions of the multiple dependencies involved, one is bound to be faced with a plethora of alternatives to experiment with. This post is a guide on how I developed my orchestrating microservice, along with all the links and resources that I gathered over this journey. I hope it can be of help to somebody somewhere someday.
Part 1- Learning the basics of Spring
As soon as I figured out that I had to use Spring Boot, I was on the lookout for a course via which I would understand the complete working of Spring. There are quite a few intricate concepts involved like Inversion of Control, and Dependency Injection, which seem complex if you don’t understand it, but make life so much easier once you do. I came across this course on Udemy to understand the basics of Spring-
It’s a brilliant course, which I would definitely recommend to understand Spring and get a good hands-on for the various concepts involved. Taking this course helped me understand who “autowires” objects into my classes :)
Part 2- Identifying entities and figuring out the architecture and control flow of my service
I could assume that I had certain downstream services for validating my payment method, getting product prices from the database, etc, so I did not have to implement any DAO layer as such(or so I assumed from the requirements). Hence the essential requirement boiled down to this- “Develop a microservice that makes calls to other microservices in a resilient and scalable manner for the purpose of placing orders”
I thought through what my entities need to be for my use-case, and I came up with these-
I would need my Rest Controllers to listen on certain routes, and I would have to re-route requests to the corresponding services based on the request.
Part 3- Getting my hands dirty- the coding!
These were what my APIs looked like-
To get product price- Product getProductPrice(int productID)
To place an order- Order placeOrder(Order order)
First, I created two Rest Controllers- one each for Product and Order requests. I created methods to map routes on GET and POST respectively(since my APIs were to get and post data respectively).
I then created the Services for getting product price and placing the order. The service for order placing invoked a call to a payment service as well. So essentially my Service was orchestrating between the product price service, order placing service, and the payment service. In each of these Services, I required a REST API to the actual downstream service for the respective service. I accomplished this by using the RestTemplate in Spring. More about using RestTemplate can be found at these links-
Once my end to end basic flow was finished, I decided to work on making my Orchestration service more resilient by validating input, handling failures from downstream services in a graceful way, etc.
For validating input, I used javax validation in Spring to ensure my productID was not NULL, products in my Order were not NULL, Payment details were not empty, etc. Make sure you use nested validation if an object you are using has another object that needs to be validated.
You can check more about how to validate any member variables in Spring here-
If there was any failure with my downstream services, I wanted to return a generic response to the client(INTERNAL_SERVER_ERROR), instead of describing any specifics. For this I used the Controller Advice exception handling in Spring. Any exception thrown by the Controllers is caught here, and the appropriate response can be returned. For this purpose, I also created custom error responses and custom exceptions.
More about creating and handling custom exceptions with Controller Advice can be found in the links below-
Part 4- Testing
Since I could not test the end-to-end working of my Orchestration service due to unavailability of actual downstream endpoints, I had to write Unit tests extensively to ensure I was covering all possible outcomes of a specific function. I used JUnit 5(included in spring-boot-starter-test dependency) for my testing. As someone who had never written tests, I found it to be quite a learning curve understanding how Unit tests work, and then writing them in Spring Boot. After a lot of Googling, I found these useful links which helped me get started with writing my tests-
To understand how to approach writing tests, and mocking your data in Spring Boot-
Using Mockito to mock your controllers and send requests to them-
After a lot of debugging and figuring out why my tests were failing, boy wasn’t I happy to see them all green after my tests ran. :)
Part 5- Logging
Once I had resilience in place, I wanted to make debugging easier incase of any failures. For this, I included the SLF4J logger, that comes included in the spring-boot-starter-web dependency. I included relevant trace, info, debug and error logs in all my classes.
For more information about loggers, and setting properties for loggers, you can check the below links-
Part 6- Monitoring with Actuator
Spring Boot is convenient and quick to build out your APIs for a lot of reasons, and one of them is that it gives you some endpoints to monitor your server out of the box and for free! All you need to do is include the actuator dependency, and you are good to monitor various metrics of your application like whether it is up and running, how many requests it has got, different HTTP responses returned, etc. Who else thinks this is super convenient?
For a more detailed article on how to include an actuator in your application, and how to secure the endpoints, check this link-
Bonus: Mock JSONs for testing
While doing my research, I came across some API endpoints with fake data that can be used to test your APIs. Although I couldn’t use this for my specific use-case, I am including it here hoping it might be useful to someone in the future.
For more extensive data you can use this-
Extensions-
Although I could not implement authentication, it is super important to secure your endpoints. Hence, I have included some articles which I went through for authentication and security in Spring, which I will take up as an extension to my current project:
Final Note
I had a complete blast of a learning curve building out this project, and I have tried to capture my learnings and research with the hope that this article helps somebody build REST APIs in Spring Boot from scratch. Do let me know of your feedback on my project and suggestions to improve this article in the comments!
Feel free to checkout my code for this project here-
