Oliver Drotbohm

Oliver: Hello Marco, sure. I’m a Senior Principal Software Engineer at Pivotal (the company behind Spring), Java Champion, and member of the JPA 2.1 expert group.

I have been developing enterprise applications and open source projects for over 15 years now and my work is mainly focused on software architecture, DDD, REST, and persistence technologies.

Also, I regularly speak at German and international conferences, publish a fair amount of technology articles, including on my blog, and wrote the first book on Spring Data.

Oliver: I got in touch with it during the implementation work for my Bachelor’s thesis at the University of Mannheim in the mid-2000s. I built a server component to manage software families following the generative programming paradigm and the updates of those. It was based on Spring 2.0 and Hibernate 3. I just recently stumbled over the sources and it’s pretty funny to see what kind of programming model we dealt with back in the days. That said, it actually still builds and runs just fine.

Oliver: I think it’s pretty clear that Spring Boot is the entry point into the Spring world. Depending on what kind of app you’re trying to build, you’ll find all necessary information on https://spring.io and I’d recommend following the topical guides for the different workloads (web, serverless, batch) to get something started quickly.

From that point on it’s mostly a question of what your app needs. If it’s a web application, there’s probably some persistence and HTTP API involved for which the Spring Data projects and Spring MVC / WebFlux are worth having a look at.

Oliver: During my consulting work I see teams usually struggle more with architectural aspects than Spring itself. However, the two worlds often connect trying to find the right balance between keeping your code conceptually pure, but at the same time making sure you make proper use of the framework, because: why would you use it in the first place otherwise?

I see teams that unnecessarily couple themselves to technology in general and Spring in particular, which often causes tests to become very involved and a lot of technical complexity in the codebase. On the other hand, so teams go miles to try to decouple everything and the world from anything that’s not written by themselves and – even with a totally different mindset – produce the same problem: piles of additional accidental complexity through layers and layers of abstraction.

There’s definitely skill in finding the right balance here.

Oliver: A very prominent sample project probably is the PetClinic. Bear in mind though that it’s usually intended to be a technology showcase, i.e. certain architectural aspects within it will not be modeled to their completion as that’s not what the focus is on.

A slightly more involved open-source application I’ve been involved with recently is a COVID-19 contact tracking application for health departments in Germany.

Its backend is a pretty versatile web application exposing a hypermedia based API. It’s a modular monolith following DDD pretty closely, and contains additional aspects like JSON representation creation, JWT authentication etc. The frontend is written in Angular which should make a lot of the architectural ideas transferrable to other real-world applications.

Oliver: I’d recommend the former. I think the traditional, Servlet based stack will stay the predominant one in large parts of enterprise Java. It’s ubiquitous now, it’s well understood and there’s even quite a bit of performance innovation on the horizon with Project Loom.

That said, I think it’s pretty advisable to at least understand what reactive programming fundamentally is about, under which circumstances it’s the tool of choice, which programming paradigms it enables, like data being pushed to clients, back pressure etc. and – of course – also, which kind of additional complexity it brings to the table.

Oliver: I don’t think it is. In fact, I even think a lot – if not most – web applications would be better off being written in a more traditional style. Simply for that fact that a lot of unnecessary, accidental complexity would go away.

I often see people argue: "But my app needs that level of interactivity!". The team around Basecamp, a Rails-based project management software, just released hey.com, a web-based re-imagination of the way we work with email and that’s completely based on the traditional web stack plus progressive enhancement. That shows that even more complex applications can be built web-natively and by that even perform better than ones completely written in JavaScript.

In fact, I think the Rails community has a lot of interesting concepts (like Turbolinks etc.) that solve a lot of the perceived drawbacks of traditional web applications. I guess the enterprise Java community has quite a bit of stuff to pick up from them.

Oliver: I think Spring Data repository abstraction is the programming model you want to use when implementing business logic on top of it, probably following Domain-Driven Design. If in doubt, I’d start with a technology that is pretty close to the DDD notion of an aggregate in the first place and model my persistence mapping code accordingly.

JPA and its corresponding Spring Data module do a not too bad job at this if you’re willing to follow some basic mapping guidelines. The MongoDB module sometimes even works better for this as documents are closer to an aggregate structure in the first place and Spring Data MongoDB comes with a slimmed-down feature set, so that you don’t get that lost in modeling options.

That of course only works if MongoDB is an option in the first place.

Every time you feel like you need to fight the persistence technology it could be a couple of aspects: your aggregate design might leave room for improvement or the technology in use might not be a good tool to solve the particular problem at hand.

Luckily it’s easy enough to e.g. mix JPA with any JDBC library like Querydsl or jOOQ in your Spring Boot application, so that you could go with JPA for your aggregate state transitions and manually written JDBC statements for everything analytical, batch etc.

A final important aspect is what the folks in the team are familiar with. A team very experienced with JPA might have trouble to become productive with a pure SQL based library, even if the latter was the better tool for the technical requirement. The same applies vice versa. I guess the seamless versatility of supported data stores and data access paradigms within the Spring ecosystem is one of its key success factors.

Oliver: I think the fundamental misconception is about what actually causes certain effects. We’ve seen the discussions around startup time ("Component scanning is slow!") and runtime performance ("Reflection is slow!"), when in fact it’s of course possible to bootstrap an app that doesn’t do anything meaningful in sub-seconds, or produce single-digit percentage improvements in e.g. query method invocations in cleanroom scenarios.

But as soon as you turn all of this into something closer to the real world, you see that those things are not the bottle-neck. Some other technology involved and needed at runtime needs to be bootstrapped which consumes time. The real-world application talks to a real database across the network and the avoidance of reflection is hardly noticeable anymore.

I absolutely love to see different approaches being explored and the involved parties pushing each other to new horizons. In the end, it’s always going to stay a tradeoff between resource consumption in different ways, developer, build and deployment convenience and the ubiquity of support, both in terms of integration with other technology and commercially.

Oliver: Of course there is!

The team constantly works and always has worked on improving both the performance and efficiency of the individual projects as well as the development convenience for our users. The latter meaning providing solutions to the problem space that developers face and which constantly shifts. Support for a variety of architectural styles and new technology and programming models that we see become relevant.

Oliver: My primary channel for technical exchange is Twitter, on which you can find me under @odrotbohm. A lot of my presentation decks can be found on Speakerdeck. Most of the talks have recordings available on YouTube. YOu should be able to find them simply searching for the talk titles.