Craig Walls

Tim: In no way am I judged anyone who likes ORM or suggesting that you shouldn't use it. There are obvious benefits and, as I even stated, I am known to use it from time to time. I just don't enjoy it much when I do.

But yeah, Spring Data is amazing for ANY kind of persistence, whether it be JPA or JDBC for relational databases, MongoDB, Neo4j, Cassandra, Redis, etc, etc, etc, etc, etc. And there's so much more you can do with it beyond just creating repositories. I'm especially a big fan of Spring Data projections which take query's response and "project" it onto an otherwise completely unrelated type that just happens to share some of the same properties. What's more, if you look closely at the queries that are executed for projections (at least when query logging is turned on for JPA), you'll notice that the queries are optimized for what's needed in the projection. E.g., if the entity has 10 properties, but it's being projected onto an object with 2 properties, the query will only fetch those 2 properties and disregard any unnecessary joins. It's really quite awesome.

Perhaps. If you've worked with Manning before for book reviews, you can probably just reach out to the review editor you dealt with before and ask. I'm sure that they'd be happy to put you on the list.

I'll be brutally honest...I'm not a huge fan of JPA (or ORM in general). When I first learned ORM (anybody remember Castor?), I thought it was amazing. I could map objects to table and properties to columns and it was like magic! Except that it wasn't magic...I still had to define the mapping. And what I learned from all of that is that I'm pretty good at writing SQL, but I'm HORRIBLE at defining mappings...especially if the database schema deviates (as it often does) from the domain model. Therefore, although I still do some JPA from time to time, I would prefer JDBC (well, Spring's abstraction of JDBC) over JPA any day.

That said, if you must do JPA, then there's no way to avoid the mapping. It's just so essential to JPA. Therefore, since I can't eliminate mapping pain, I seek ways to reduce pain in writing repositories. Before Spring Data JPA, I observed that all of my repositories, regardless of the domain, looked pretty much the same. My repositories were just thing wrappers around EntityManager and had (more or less) the exact same methods. I hated it. But if I'm going to do JPA today, then Spring Data JPA is the way to go. Let Spring handle all of the EntityManager stuff and just write a repository interface. Easy-peasy (except for the mapping stuff).

So yeah...my book covers JPA using Spring Data JPA. What's nice about that is that the programming model for Spring Data JPA is nearly identical to working with Spring Data Cassandra, Spring Data JDBC, Spring Data MongoDB, ... etc. There are subtle differences, but for the most part, once you know how to work with one kind of database with Spring Data, it's easy to apply that know-how to another kind of database. And, in fact, the book will cover Spring Data JPA, SD-JDBC, SD-MongoDB, and SD-Cassandra.

That's hard to answer given that I don't know what modules are overlooked by others. I only know which modules I tend to forget about.

Obviously, Spring MVC is perhaps the least overlooked module in Spring. Virtually every project uses it (or Spring WebFlux if they've gone reactive). So that's not going to make my list of the most overlooked.

But if I had to pick what might be the most overlooked (again, based on my own experience of tending to forget about them), I'd say:

- Spring Statemachine - The name kinda says it all...provides statemachine concepts in a Spring way.
- Spring Session - Manage and share session information across nodes in a common backend (like Redis).
- Spring REST Docs - Generate Asciidoc templates for your REST APIs based on results of running tests.

Even then, these come to mind from time to time. I've even done a little work with Spring REST Docs recently, so it's not entirely forgotten.

You are correct in saying that Spring Cloud Gateway is itself developed in a reactive fashion, based on Reactor. And if you are going to customize Gateway in any way, you'll need to get on board with that model. The reason Gateway made that decision is in order to support things like WebSocket, RSocket, and others that really benefit from a reactive streams model. But if you're using Gateway as the front for a service, that service doesn't require a reactive model. You can use good ol' imperative Spring MVC to create the service and reactive Gateway in front. No problems at all. I do it all the time.

AFAIK, no other piece of the Spring landscape requires reactive in any way (aside from the obvious, like Spring WebFlux). But the Spring folks do talk up reactive a lot because there are some obvious benefits from taking a reactive approach (in short, doing more with fewer threads) and because a lot of projects will benefit from it. But just because it's the hot topic of the day doesn't mean that we're requiring you to apply it in your projects. In fact, in my book, I don't even touch on the reactive topics until halfway through the book because (1) I don't think it's necessary for all projects (2) there are some non-reactive essentials to get out of the way first, and (3) I definitely want to communicate that it's optional.

Again, Gateway itself is reactive so that it can support a broad range of services that it fronts, but those services do not have to be developed in a reactive model themselves. And, unless I'm forgetting something, no other bit of Spring requires reactive in any way. I would encourage you to get to know Spring's reactive programming stuff...but you aren't required to use it.

Charles O'Leary wrote:Thanks for the clarity.  Previously, I had used Spring MVC with Hibernate, while my future use will likely be using MyBatis integration.  I had always wondered what, if anything, I missed and/or would miss by not using a "Spring branded" persistence such as Spring JDBC.

I'd definitely checkout Spring Data JDBC. Try it first in it's "raw" JDBC form to get a feel for how it works. Then add MyBatis to the mix to see how you like it.

Shaik Ashish wrote:I just completed learning Java as a language and I am yet to Start Spring?Would you recommend this book for beginners like me?

Depending on how comfortable you are with your newly learned Java skills, yes, I think it'd be a great book to start learning Spring. (Of course, I'm biased.)

When I (along with my co-author at the time) wrote the first edition, we sincerely tried to include EVERYTHING that Spring had to offer at that time. And we came close...but still failed to capture it all. By the time the 2nd edition came along, the Spring landscape was so broad that it was impossible to cover everything. Now that I'm working on the 6th edition, it's even more important to make tough decisions on what will be included and what won't be included. I've had to decide what would be the most useful information for someone new to Spring as well as what might be the most valuable new information for the seasoned Spring developer. No matter what choice I make, somebody's gonna miss their choice piece of the Spring ecosystem.

So, no...Spring State Machine isn't included. I've also had to cut the Spring Cloud material and will refer everyone to John Carnell's excellent book that covers the topic in more depth than I could ever do in just a few chapters. I also don't dedicate entire chapters to the various ways one can wire beans together, because although that's still useful info, it's not nearly as useful in a world of autowiring and autoconfiguration; instead the specifics of wiring are handled in a much more pragmatic way as-needed throughout the book while working with other pieces of Spring.

Scope-wise, the book will cover...

- Getting started
- Spring MVC
- Spring's JdbcTemplate
- Spring Data (JDBC, JPA, MongoDB, and Cassandra)
- Configuration properties
- Spring Security (not comprehensively, because that itself has a huge scope)
- RestTemplate and WebClient for REST consumption
- Messaging (JMS, Rabbit, Kafka)
- Spring integration
- Spring WebFlux
- RSocket
- Actuator
- JMS
- Deploying, including containerized deployment to Docker and Kubernetes

I *could* cover so much more...but then the book would be enormous and would never be completed.

I'm not sure how to reply to this, because typically Spring is ahead of me when it comes to addressing needs. I don't often encounter a case of "I wish Spring did X." because if I do, then I tend to find out that it actually does already and I didn't know that.

That said, I can think of two areas that it is currently growing in that are interesting:

- Containerization: As of Spring Boot 2.3, Spring Boot has some awesome suppose for building your Spring application into Docker images, which can then be deployed in (among other places) a Kubernetes cluster. This is really good stuff and it's relatively easy to do (see the "music video" I made about it at https://youtu.be/xUBPh1qAJms). That said, I think there's still opportunity here for improvement and definitely some opportunity for tighter integration with Kubernetes for things like consuming ConfigMap properties, service discovery, etc. The Spring Cloud Kubernetes project is already addressing some of this, but there's still room to grow.
- Native images: In the interest of squeezing every bit of performance from startup, to memory footprint, to distributable size, there has been some really good work done recently to enable native images of Spring applications. There's still work to be done, but what's taken place thus far has been rather impressive. I don't want to give away spoilers, but there's at least one talk I know about at SpringOne (https://springone.io/2020/sessions/the-path-towards-spring-boot-native-applications) next week to show off some of the latest stuff in this space.

Esteban Suarez wrote:Ok thanks for your answer, I'll check the link you've referenced. Sorry if questions were repetitive, at the time I made this post, I had not checked other similar posts.

No worries. Happy to answer the question. Just didn't want to type the same thing a 2nd, 3rd,...Xth time.

I honestly had not heard of CUBA until just now. So I went to check it out watched a video or two...and I still can't say that I know enough about it to authoritatively compare it with Spring/Spring-Boot. But if you're willing to accept an answer based on virtually no knowledge of CUBA, I'll answer anyway.

From what I can see, CUBA offers a modular/component-oriented development model that's heavy on forms (web-based or IDE-based) to produce code. As I watched the getting started video, I couldn't help but think about the "Evil Wizards" described in Dave Thomas and Andy Hunt's "Pragmatic Programmer". But again, having no hands-on experience with CUBA, I'll stop short of saying that what they have is a bad thing. It's just not my cup of tea (or Java, if you will).

Moreover, some of the component-oriented model reminds me a bit of what web frameworks like JSF and Tapestry offer, but with CUBA, it's for the entire stack, not just the web layer. Again, nothing wrong with that. But even though I saw some code along the way, the bulk of the development time was spent in forms and wizards tying things together. I'm a coder and--this is just my opinion--that kind of programming model is painful to me. And, in my experience (including one I'm living through right now) when that kind of model is in play there's not as much room for customization. If you want to do exactly what the components offer, that's great. But it gets increasingly difficult to move beyond the baked in functionality.

But again, I have only watched a video and have read a bit about CUBA. Maybe they've solved that problem and made form-based and component-based development super-flexible. If so, then my concerns would be less.

Spring, on the other hand, doesn't define many pre-baked components...at least not at the same level. Instead, Spring leaves it to you to define the components that your application needs and it wires them together. Yes, there's more coding...but again, that's my jam, so I don't have a problem with that. And Spring Boot makes it even easier by auto-configuring the framework-level bits so that you can focus on the functionality your app needs.

In short, I don't know much about CUBA. It looks interesting, but doesn't appeal to me much on the surface. I won't say it's bad and maybe it's a perfect fit for some projects. But for me, I prefer a framework like Spring (and Boot). And yes, I'm biased. Did you expect otherwise?

Charles O'Leary wrote:What resources would you recommend to have in depth knowledge about how Spring Caching works?

For in-depth knowledge, there's no better or more definitive resource than the source code: https://github.com/spring-projects/spring-framework/tree/master/spring-context-support/src/main/java/org/springframework/cache

For understanding in how to apply it in your application, however...well...I aim to include that in the 6th edition (although, be aware, that bit hasn't been written yet).

Charles O'Leary wrote:Could you please write to the advantages and disadvantages of using Spring with MyBatis as opposed to using built-in Spring Persistence?

I'm unclear what you mean by "built-in Spring Persistence". Spring doesn't have it's own persistence, but instead builds abstractions on top of other persistence models, including MyBatis.

To be honest, it's been awhile since I've done much with MyBatis, but (unless I'm mistaken), Spring Data JDBC has MyBatis integration. So ultimately, the advantages/disadvantages of that choice versus others are largely dependent on project goals and developer tastes. I can't possibly tell you which you should use.

Skumar Patel wrote:Hi
How this book will help developer to be in action to develop spring application?

I'm not sure I understand this question, but...I'll try answering it anyway: While it would be impossible (trust me, I've tried) to write a book that comprehensively covers every nook and cranny of Spring application development, Spring in Action covers the bits that are most commonly used and valuable in many projects. And it does so with a spirit of "laziness" (which, according to Larry Wall is a good trait of a software developer). Laziness aims to reduce the amount of work that you do as a developer, focusing on what's most important, and avoiding where possible writing code that satisfies the framework. In other words, as much as possible, focus on achieving your project's goals and less focus on writing Spring configuration code (which is why, starting with the 5th edition, the book is very Spring Boot-centric).

Skumar Patel wrote:
Is there anything mentioned about spring and ajax framework in this book?

There is a slight amount of integration with Angular, but only enough to demonstrate Spring concepts. It is not intended as a "How to write Angular/React/VueJS apps with Spring" book in any way. I only introduced Angular to the mix so that I could talk about some of the Spring concepts around REST APIs.

I'm not sure if I'm allowed to name names, so I won't. But...I assure you that virtually every large enterprise project I encounter, from companies whose names you know and have probably done business with, are all using Spring Boot.

I'll be honest and say that I don't understand why some think that Spring Boot is only good for small projects when, in fact, it really starts to shine on large-scale projects. I can write a "Hello world" app without Spring Boot and, although not as easy as with Spring Boot, isn't that painful. I can write a small-to-medium sized app without Spring Boot, but the pain increases as I have to explicitly configure and maintain configuration for all of my application's components. Extrapolating to large-scale enterprise applications which may even be spread across multiple services, I can't bear the thought of the pain I'd go through without the benefits of Spring Boot auto-configuration, starter dependencies, and...OF COURSE...the Actuator which really shines for large-scale projects.