Solving Problems With Spring Boot

Greg Turnquist

December 05th, 2014

I first became aware of Spring Boot early in 2013. At the time, we were rebuilding Spring's website and decided to write a collection of guides that could be consumed during a single lunch break (at spring.io/guides). Realizing how much code Spring Boot saved us from writing (and explaining to readers) thanks to its auto-configuration feature, we embraced it fully. In fact, it led me to write several patches for Spring Boot to help with several of the guides I was writing. Discovering that boiler plate Spring code was unnecessary was incredibly exciting and very effective.

Another of Spring Boot's amazing features was its support for properties. This was something I learned more about when I attended Dave Syer and Phil Webb's presentation at the 2013 SpringOne conference. The room was packed with attendees. The keynote presentation of Spring Boot from the night before had whet many appetites. I learned that not only did Spring Boot provide the means to inject critical values into auto-configured beans, it also had strong support to configure on any platform through different naming conventions. You could also override embedded property settings at any stage, even after deployment into production. At my previous company, I had built something by hand that was similar, but never as sophisticated. Given Java's frankly ineffective property APIs, it doesn't surprise me how much people like Spring Boot's solution to this.

Another golden feature is Spring Boot's library of built-in actuators. These include metrics, controls, and reports. In a production environment, this type of material is critical. Not having to build it up for the nth time as I have done in the past makes it a killer feature to me. And Spring Boot's support for adding your own metrics and management endpoints is really cool.

Every feature Spring Boot provides is incredibly appealing to quickly moving into coding features and deploying them into real apps. Things are simpler and are more aligned with what is needed when you deploy and maintain an app. You don't change gears when it comes production time. Spring Boot doesn't laden me with complex XML configuration files. Instead, I can configure things with code and simply properties. But when I need to customize something special, like a view resolver, Spring Boot gets out of the way by withdrawing its auto-configured one.

I was speaking with a colleague a couple months ago and discovered he was helping a local school to setup a computer science workshop. Thanks to Spring Boot, he gave them advice on setting up some exercises where the students would be able to immediately start writing the code that displays "Hello World" on a web page. They wouldn't have to start with installing a build system nor standing up an application server. The thought of going through all those extras sounds really boring; I can only imagine how that would dampen the spirits of kids just getting started. Being to instead move right into application development, and seeing results within minutes, sounds more exciting than ever.

So taking all this into account, I started writing my proposal earlier this year about Spring Boot. It was within two weeks of that when Packt reached out to me about writing some Spring Framework oriented book. I immediately polished up my proposal and responded with it. It didn't take Packt long (24 hours perhaps?) for them to leap at the idea. We hammered out the specifics in less than a week and got moving quickly. I have never been more excited about writing.

Given that I have been reading blog articles about Spring Boot for almost two years, I have seen so many examples of how people are solving problems, not just building toy apps. I decided to tilt my book towards solving those problems and show how Spring Boot really is the innovative answer to modern application development. I hope everyone is able to enjoy it.

About The Author

Greg Turnquist is a test-bitten script junky. He is a member of the Spring team at Pivotal. He works on Spring Data REST, Spring Boot, and other Spring projects, while also working as an editor-at-large of Spring's Getting Started guides. He launched the Nashville JUG in 2010. He also created Spring Python and wrote Spring Python 1.1 and Python Testing Cookbook for Packt. He has been a Spring fan for years.