I have never been more excited to be a part of the Spring team as I am now. It feels like we are blazing new trails left and right. Seeing the massive turnout this week for Stephane and Brian’s “Spring Boot University”, a 3-hour session at DevoxxFR, left me awestruck. Wish I could have been there.
Everywhere I turn, people are gobbling up Spring Boot. They tell me, this is what they have been looking for. How did this happen? It’s a really neat history.
A little bit of history
The Spring Framework started lean and mean. It was a fantastic way to integrate critically needed tools through its profound power of dependency injection. Some people criticized this as hype, but the community’s massive adoption proved the vitality of this approach. Coding was fun! Demo apps are one thing, but people were using Spring Framework to build large, complex systems. Complex systems need lots of components. Existing APIs like JMS, JDBC, and other things came with the need for lots of plumbing. These APIs were way too low level. And thus was born JmsTemplate, HibernateTemplate, and my personal favorite: JdbcTemplate.
But that was not all. Building web apps with Spring MVC was hot. It made testing app controllers nice and easy. You weren’t obligate to run web-based acceptance tests through complex controls. Instead, you could isolate things. Nonetheless, as the needs of the community grew, so did Spring. To help different parts of Spring grow and evolve and now slow down the core framework. other projects were formed. Spring Security, Spring Data, Spring Integration, Spring Batch, and more. At one point, people expressed their dislike for “spring.jar” containing everything. The Spring team chopped things up into finer grained JARs so you could grab what you needed. Then we had too many JARs. What?!?
As the power and might of Spring grew, so did its learning curve. People were asking which project to use. How to integrate them together. What version of Spring Integration with the version of Spring Framework I’m using? How do I even start using Spring MVC? What steps do I need to carry out?
Spring Boot is born
Thus was born Spring Boot. Spring Boot brought forth a series of critical concepts.
- Pre-pick the versions of Spring and other libraries so you don’t have to
- Auto-configure boilerplate stuff like Spring MVC, Security, Integration, etc.
- Remove key beans if you define your own
- Accelerate Spring’s power of externalization of properties to Warp Factor 9!
- Add on DevOps-ready metrics
A big hurdle was mixing together different libraries. If I have Spring Framework 4.0.1, what version of Spring Integration should I pick? Simple: pick one version of Spring Boot, and both of those dependencies are pre-picked for you. Boot doesn’t stop there. It extends into lots of key 3rd party libraries. This decision was so popular, that Spring IO was created to reach out and harmonize the versioning of 380+ libraries.
A big issue (especially for me, a non-web guy at the time), was standing up Spring MVC. First, you had to put certain bits into web.xml. Then you needed to stand up view resolvers, message converters, controllers, and a whole cadre of other components. You really needed to understand Spring MVC to do it and to do it right. Spring Boot stepped up to the plate and said, “don’t worry, we’ve got you covered”. Add “spring-webmvc” to your project, and Boot will create all that stuff for you. You just create a controller that returns view names, and you’re up and running.
No form of automation can ever cover every circumstance. Sooner or later, developers need to break out of the framework’s default position. And this is where LOTS of tools fail on a massive scale. There are two common outcomes: 1) Don’t permit such customization and hamstring future developers or 2) Add so many extension points that the simple use case vanishes. Spring Boot introduces option 3) Drop bits of auto-configured stuff when you create your own. This is known as backing off, and has moved the bar forward on app and framework development really far. New applications and new frameworks will surely adopt this approach to expansion because it just makes sense. If you build a framework and don’t shoot for this, someone starting after you might catch up and pass you because they will.
Something I’ve needed for years before I wrote Java for my day job was externalization of application properties. I dealt with development, test, and production environments. Rebuilding apps for each target was wasteful. So I hand wrote code for that. Spring Framework has always had powerful support for properties files, but Spring Boot took that feature and accelerated the options. Having APP_ENV and -Dapp.env both map to @Value(“${app.env}”) String appEnv or class ApplicationProperties { public void setAppEnv(String env)… } is sheer genius can cannot be understated. People talk about 12-factor apps and high tech wwizbang manifestos, but this concept is simple to grok and applicable just about everywhere. You could be running a close network solution (which I did at my old job) with no cloud involvement and find this technique the Right Thing To Do.
DevOps-ready controls and metrics is something area always begging for. System administrators, program managers, business analysts, and others are always asking for this extra metadata about our apps. Being able to spit out a first cut of this by simply adding one dependency to an application is phenomenal. Then being able to craft your own metrics and controls with little effort ramps your app up to production ready and Management Friendly by providing them the warm fuzzy metrics for clients without breaking the bank of technical debt.
Where are things now?
With Spring Boot spreading across the Java ecosystem over the past two years, it really is exciting to see how much fun people are having building apps. They focus on the end game, not setting up infrastructure. Hearing chatter like “Using Spring Boot is like pair programming with the Spring team” (@starbuxman) and “Spring Boot is just what we need” is cool. I get excited to go the Nashville JUG and talk about some piece of Spring, not just because it “looks good”, but because I can sincerely point out how using it is simply fun! Isn’t that what real software is supposed to be? Functional, carries business value, and at the same time, fun to build and release? It almost feels like Spring Boot introduces yet another rennaisance to application development.
I have been quite pleased that my previous book, Python Testing Cookbook has earned double the advance over the past three years (and keeps making me money!) But I jumped out of my chair when the first statement for Learning Spring Boot came in last month and showed that over 400 people had bought a copy. My excitement to write about Spring Boot was paralleled by my instinct that people would want to learn about Boot’s secrets.
There is a lot of action happening in the Spring team as we continue to blaze trails we couldn’t foresee five years ago. Many of our key decisions in the past have put us on a strong footing to continue pushing the envelope for the future in both application power as well as ease of development. The community experience of putting out new features, getting feedback, and generally building something better each and everyday that helps thousands of people solve problems is both inspiring and humbling. There’s no other place I’d rather be working.
Happy coding!
Hi Greg,
Question for you. I’m considering using your spring-security-angular library on a project and I’m having a small disagreement with my developer. For a seasoned, senior JS dev, what’s the range of hours or days would it would take to implement your solution for a basic website using an Angular UI? Also, is this solution using OAuth2.0 or some other protocol?
Thanks in advance!
Darren Kramer
CEO
User Experience Consultants, Inc.
Hi Darren,
Just so we’re clear, the Spring Security/Angular thing is a tutorial not a library (see https://spring.io/guides/tutorials/spring-security-and-angular-js/). This is Dave Syer’s development, and he has all the code and text here => https://github.com/dsyer/spring-security-angular/.
I can’t actually comment on the ease or difficulty of applying the concepts in this tutorial because I frankly haven’t found the time to read it myself. What I can offer is some underlying advice. The tutorial is based on applying several Spring portfolio projects in the arena of an Angular app including Spring Security and Spring Security OAuth2.
If you have no experience with Spring Security, I suggest you start with a simpler introduction => https://spring.io/guides/gs/securing-web/ After that, checkout Spring Security w/Ldap => https://spring.io/guides/gs/authenticating-ldap/. It’s probably not where you are heading, but the point is to give you more exposure to Spring Security fundamentals, and in this case, using a different authentication provide (LDAP instead of in-memory). This shouldn’t take but a couple lunch breaks, and would be well worth the effort to learn the basics of Spring Security.
With that, you should be better prepared to read Dave Syer’s Spring Security and Angular tutorial, which brings onboard OAuth2 support via Spring Security OAuth2. From here, hopefully you can distinguish what is unique about Spring Security in an OAuth2 setting compared to BASIC security.
At that stage, I think you will be able to pose more precise questions at https://gitter.im/dsyer/spring-security-angular, an web-based chat channel for that tutorial.
Good luck