Hacking with Spring Boot 2.3

A book review
July 3, 2020 by Michael

A couple of weeks ago, I received a paper copy of “Hacking with Spring Boot 2.3 – Reactive Edition” by Greg L. Turnquist. Greg sent this copy to me free of charge for a review. Thanks for that!

I’m happy about the opportunity to read a new Spring Boot book after I published one myself nearly two years ago (See Spring Boot Buch) about Spring Boot 2.0.

I also have only high regards of Greg. While I work at Neo4j, Inc. and Greg at VMWare we happen to have very similar tasks: We both work at various Spring Data modules and meet regularly at the shared standup.

About the print

Greg chose to self-publish his new book and I can totally relate. My copy came as “print on demand” version from Amazon. The quality is really nice and in no way worse than Greg’s previous book.

I may prefer a more black typesetting, but it’s still readable well enough. Apart from that, you clearly see it’s AsciiDoc based sources 🙂

Lexicon or hands on?

Hacking with Spring Boot 2.3 is definitely a hands on book. After a quick introduction to Spring Boot itself, Greg jumps right away from it 🙂 The focus lies on introduction reactive programming concepts and a very simple kitchen domain.

All the time, it really feels like you are sitting with Greg together on the keyboard, pair programming.

What I like about not doing Spring and Spring Boot related stuff at the very beginning is the mere fact that this is what Spring should be about: Providing the plumbing for your domain around it, not inside it. Having the start designed this way is excellent.

Of course, Greg needs to introduce core Spring Boot concepts at the beginning and we get a good overview about Spring Boot starters, auto configuration, metadata and more.

On data access

The book is about hacking with Spring Boot, not with Spring Data. But I agree 100% with Greg that an application without data is somewhat meaningless. As the book targets reactive programming especially, Greg has to pick a database that supports real reactive drivers, not something wrapped in a thread pool. At the time of writing, MongoDB was the predominant one. I would have of course loved to see SDN/RX and Neo4j, but I guess I cannot have everything.

In the meantime, you can go for Neo4j or with R2DBC and several SQL-Databases (amongst them, PostgresQL).

Anyway, I do think that Greg manages to cover standard idioms and best practices to work with Spring Data based data access code a like. It’s an exhausting topic, but the overview is just right.

On developer tools

Solid content on the “standard” Spring Boot developer tools, like restarting mechanisms and caching. Complete and nothing much to say about. The new logging groups are mentioned.

The information about Project Reactors debug mode, the logging mechanism for reactive assemblies and also the reference to the BlockHound a very valuable, even for a seasoned library developer like myself.

On testing

Testing with Spring Boot is a solid introduction to the testing support. It recaps the differences between unit, integration and end-to-end-tests. It clarifies that Spring Boot (and Spring) always strived for testability, in contrast to other believes.

While I would have probably chose different examples for testing services – for example not firing up the Spring Context at all as long as possible, especially with everything constructor injected as one should do – I super like the stance on reactive testing support. Starting about Project Reactors step verifiers and some more gems:

I learned about to things: Mono#hide respectively the corresponding fact that Project reactor may optimizes empty monos away and about Blockhounds JUnit 5 integration (Remember: Blockhound detects blocking calls in reactive code):


The above dependency brings in a test execution listener that instruments all running tests. Sweet and short.

Operations with Spring Boot

So must of the Docker and container related stuff in that chapter is brand new Spring Boot 2.3. Spring Boot Actuator has been there forever, but it’s helpful of course for people being new to Boot. Also: Thanks for the reminder to epxose actuator endpoints consciously.

Anyway, I myself found the explanation of how to use Spring Boot 2.3s new layered Jar with layered Docker images and WITHOUT the also possible Buildpack approach very usable.

Rest? Not for the RESTFul!

I wouldn’t be happy having a book by Greg without a good chapter on REST. But of course, I get one: Greg evolves a standard REST controller (Just returning plain JSON) to support HATEOAS to support affordances, all in a reactive way and all accompanied by Spring REST docs test.

A reader must do some deeper dive in some of the junction points afterwards, but they clearly have an idea what is possible.

Subliminal Messages

The most valuable piece of information for me here is the very nice explanation of Project Reactors publishOn and subscribeOn operators as well as the different schedulers revisited.

RSocket 🚀

This chapter makes me want use this link to start.spring.io, add our SDN/RX to it and jump into developing an RSocket proxy to reactive Neo4j repositories.

Especially on the topic of RSocket of which I don’t know yet much, Greg’s approach showing what is possible works very well for me. It gives you an idea and let’s you build from there on.

I personally will do some more reading afterwards on the backgrounds, though and this would of course also be my recommendation (the very same recommendation I have for people after many conference talks: Check the techs background and ideas, before you take conference driven development home and just go with the flow).

“Spring security is a beast”

Well, chapters about security: They are a can of worms. Writing them exposes the same problems that Spring Boot 1.x has had by making educated guesses of how Spring Security should be configured (they changed that later on, nowadays Spring Boot uses Spring Security’s defaults and backs of entirely when one configures a single aspect of it).

Anyway: There’s only so much depth an author can go, and so Greg shows only the basic concepts of Spring Security (for reactive applications).

I guess that in the real world, that chapter will leave the most open questions, for example how to integrate with Keycloak, Kerberos, LDAP or whatever.

As Greg writes about Spring Security’s OAuth2 support, my approach would be applying what you learn there and delegate everything to some IDAM, for example bespoke Keycloak (in contrast of running your own OAuth server based on a Spring Boot Spring Security application).

The main takeaway of that chapter for me is actually some good ideas what I can do once I have an authenticated user in the context.


As I said already on twitter:

Greg’s book gives a rock solid overview, both about core Spring and Spring Boot ideas as well as reactive programming paradigms. The later was super valuable for me.

If you want to go more into technical details – why auto configuration or Spring data repositories work – you need to look for a different resource, most possible the great documentations and talks from the Spring team (this one from Madhura) or my own talks or book (given you can read German).

While I work for Neo4j and I find the lack of Neo4j examples in Greg’s book disturbing, I’m gonna recommend it anyway to my colleagues in the field teams. After reading, they will have good ideas what’s in the box and where to dig further.

No comments yet

Post a Comment

Your email is never published. We need your name and email address only for verifying a legitimate comment. For more information, a copy of your saved data or a request to delete any data under this address, please send a short notice to michael@simons.ac from the address you used to comment on this entry.
By entering and submitting a comment, wether with or without name or email address, you'll agree that all data you have entered including your IP address will be checked and stored for a limited time by Automattic Inc., 60 29th Street #343, San Francisco, CA 94110-4929, USA. only for the purpose of avoiding spam. You can deny further storage of your data by sending an email to support@wordpress.com, with subject “Deletion of Data stored by Akismet”.
Required fields are marked *