This hands-on course provides an in-depth introduction to Spring Boot.
Several years ago, 2012 to be precise, I wrote an article on an approach to unit testing Spring Batch Jobs. My editors tell me that I still get new readers of the post every day, so it is time to revisit and update the approach to a more modern standard.
The approach used in the original post was purely testing the individual pieces containing any business logic. Back then, we didn’t have some of the mocking capabilities that we have today, so I went with an approach that made sense at the time.
However, there have been a few improvements in the past several years. One of those improvements has been the ability to Mock beans within a Spring Context. That’s where the @MockBean annotation comes to the rescue.
The big three cloud providers (AWS, Azure, and Google Cloud, in that order) have their various strengths and areas of expertise. Most large organizations though typically pick one cloud provider for their cloud computing needs. This works well if you’re a Java shop that’s on AWS, or a Microsoft shop on Azure. But what if you’re on a large Java project in an organization that wants to use Azure? You’re in luck.
Microsoft Azure has come a long way, and is very supportive of non-Microsoft technologies. The proof though is in the pudding. Which is where this blog post comes in. I take Josh Long’s Bootiful Microservice Services, a great starting point to get a cloud native Spring microservice application up and running, and show how it can be run on Azure.
This first blog post will be all about setting up our basic microservices by walking through the various parts of Josh’s example application, with some best practices and patterns that I’ve found to be effective. Rather than a simplistic ToDo application, we’ll be basing our application off of my favorite bagel shop in New York, Original Bagel Boss in Hicksville, to manage its orders, inventory, etc. If we can run a bagel shop on a Spring application running on Azure, and keep customers happy and full of carbohydrates, then it proves out for applications of a similar size and complexity.
We’ll be staying mostly inside the familiar Java confines, then slowly start working our way out to getting our application deployed to Azure. Then we’ll start introducing additional complexity like Spring Batch jobs, a React front end, etc. A setup this complex will show that Azure is ready for prime time when it comes to running applications in production, even if they are built on non-Microsoft technologies…
I am assisting a client that is migrating from a monolithic legacy application to a modern Microservice stack with Spring REST. We are helping to implement Swagger UI to provide both a front-end API UI, as well as to provide a level of documentation at the same time. This implementation has simultaneously met our project requirements, as well as garnering some positive feedback from our client!
Swagger UI is one of the most popular tools to visually render beautiful, interactive API documentation. In this blog, I’ll use a REST API application to demonstrate some usage of Swagger UI. The source project is available at https://github.com/bingliu2016/spring-boot-rest-swagger2.
One issue that we face day to day as developers is speed of development. One of the coolest things to me in the ever-changing landscape of technology is how this issue us continually being addressed in an effort to makes our lives easier.
We have gone from having to write everything needed in a verbose way to being able to configure a simple REST API in a few lines of code with Spring Boot. The most amazing part of this is not only the ability to create the web services but also the ability to allow these services to communicate in a smart way. Spring has given us many tools to allow easy configuration and putting together things that just work (mostly).
This post is not to be considered a full guide to which the extent of these technologies can be leveraged. In this post, we give examples of how Spring Boot can be used (along with Zuul and Eureka) to create a simple discovery service.
There are other components that can be added for things like a configuration server to pull all application.properties files from a common location that is updatable in real time, or circuit breakers to allow the graceful failing of different pieces of your API.
What this post will focus on is the service discovery between Spring Boot applications. We will also touch on how, using SteeltoeOSS, .NET applications can also take advantage of being a part of the service discovery and be routed through our Spring Boot-based Zuul Gateway. We will also look at how we can integrate Spring Security into our gateway to secure the entire API no matter the language…