Spring, Start Here

Why a book on Spring Boot

Mark Heckler: Okay, Laurentiu, one thing that I wanted to make sure we had plenty of time to discuss because there are a lot of things that we could talk about for a long, long time. And I look forward to doing more of that. But I wanna make sure we don't give too short a time to your book “Spring Start Here”. I've read the entire book. I liked the book because it covers things very well, and I'm curious about several choices you make. 

Mark Heckler: I always say that, as an author, some of the hardest things you do author are to decide what goes into a book, what does not go into a book. How do you address the things that you put into the book and the weight that you give each one? And then, of course, that's all before how you explain a particular concept or how to do something. So, a lot of times it's a matter of you recognizing that while many other books are out on the market that can address that topic or some portion of that topic, maybe they haven't covered it in the way that you would necessarily choose to do that. I have a lot of questions for you. I mean, none of them are necessarily that mind-bending, I guess. But I love the fact that you started, again, this goes back to the authors' choices, not with the perspective of Spring Boot specifically, but Spring, just Spring in general.

Let's just start it there. Why did you start with Spring in general when there are a lot of Spring Boot applications out there. Why did you start with Spring in general?

Laurentiu Spilca: Yes. Indeed, as you already said, there are plenty of books on specific subjects, like in the case of Java, you will find dozens of books on Java fundamentals. In the case of Spring, you have out there a lot of books on Spring fundamentals, and on Spring in general, and so on. But the difference between them is the way they are structured, what kind of information goes in? How is it structured by the author? What kind of examples do you have? And I think that's important because people think differently. We are different. So it's good that there are multiple books on the same topic. They don't compete with one another. In some cases, they are complementary and in some cases, someone might think this is a great book. Somebody else might think that this is not the way they would more efficiently learn, for example, Spring, and they will choose a different book.

Laurentiu Spilca: So if anyone thinks about writing a book, for example, on a specific topic and they find out that there are already books out there, I would first advise them not to be afraid to write a book that looks differently, because that makes sense. The way I chose to write this book is to introduce Spring fundamentals first of all. I started with the Spring context and I didn't necessarily start with an example because, in my perspective, the book has been designed for someone who might not even have touched a framework before, when they start with the book. So I had my students in mind. I'm also teaching the faculty, and usually, my students when they start a fundamentals course in Spring, they have no idea about what the framework is. And that's why you will find, in Chapter 1 in my case, an explanation of why you should use a framework, when you should use a framework and when you shouldn't use a framework because it's also important to know when you should find alternatives. And for this purpose, I didn't want to introduce the student, the reader, in this case, to one application with something that already has a lot of things behind the scenes such as Spring Boot. So I left Spring Boot 4 somewhere in the middle of the book, and I started very, very soft with what the context is, what beans are, how you configure beans, different ways to configure beans, dependency injection, aspect-oriented programming, so inversion of control in general.

And this is a large part of the whole book. It's six chapters, and it's only the very fundamentals of Spring. So how do you build data based on this foundation that is called Spring framework? And then in the second part of the book, when the reader already knows the very basics, understands what the framework is, what Spring is, how to configure the most basic parts of this framework, then I start with real applications. We'll have some code here, of course, but they are still examples. You can't have a whole real application in a book, but you can have examples that are very close to what a real application looks like or parts of a real application.

Mark Heckler: Yeah. And you bring up just an excellent point. I wrote a book and released it at the beginning of last year. I knew going in because I'd co-authored a couple of other ones, that no book is going to fit every person correctly. And that's what I always tell people. But I think it's sobering, isn't it? When you release a book, some people just go, "This is awesome. This is exactly what I was looking for." And someone else goes, "Eh, you know, I like this other book better. Sorry about that." And I always tell people don't worry about that because everyone is different. I may speak to you specifically in the way you need to hear, or I may completely miss it. That's fine. There are a lot of people out there.

I think one of the things that your book does well is, again, you have to choose where you come in. You have to choose the assumptions you're making, and your assumptions or your bar is pretty low. You're assuming that people are coming into frameworks fresh. And that's another thing, I think we forget because you've been in this industry a long time. I've been in this industry for a long time. And we tend to normalize, right? So we think that everybody we speak with is at the same level as we are. And many people are far above us and many people are far below us. And I don't say that as far as posturing. It's just that we're all very well versed in some things and complete noobs in others, and we will always be in technology.

So you have to remember that there are a lot of people coming into any topic completely new to that topic. It doesn't mean that they're not super sharp in other topics. Maybe they can teach us a ton of stuff in other topics, but they may be new to Spring. They have never encountered Spring Framework. They've never dealt with Spring Boot, or Spring Data or Spring Security or any of those things, and they just have been handed a project, or they're looking to work on a project, that involves Spring, and they're starting fresh. I think one of the things that you do well is that you come in with very few assumptions. It's like, "Look, we're gonna be working with Java. Let's talk about what a framework is. Let's talk about what Spring Framework is and what it does. And let's start with small bites." Which I love. I love that.

And then, just to give anybody who may be reading this, who hasn't seen the book, a little bit of background, the first section is fundamentals, the second section is implementation. So Laurentiu does a really good job. And I'll brag on you here for a minute. I hope I don't embarrass you too much. You do a really good job of setting the table and then showing how to implement these things in real-world apps. I just wanna cover the chapter headings, "Spring in the Real World," "Why Should We use Frameworks?", "The Spring Ecosystem," things like that. And then "The Spring Context: Defining Beans," right, "Wiring Beans," "Using Abstractions," "Beans, Scopes, and Life Cycles," and "Using Aspects with Spring AOP," aspect-oriented programming. And these are things that when you look at this if you're coming in fresh, I can see that that would be a lot of stuff. But you approach things in really nice bite-sized chunks. And that's just the first section. And then you get into how you apply those. And I'll get into that in a moment, but this, I have to say this, is a nice breakdown in terms of an introduction to the concepts that you would need to become familiar with to throw around the Spring Framework in ways that will put it to work for you because that's why we use frameworks, right?

Laurentiu Spilca: Exactly, so I think that looking at people who try to start learning a framework in general, they get confused at the beginning about all of the abstractions that a framework brings in. And especially now with the latest versions of Spring, you just declare a variable if you handle the project, as you said, and say it uses some other technologies, like Lombok, for example, then it has an annotation about the class or locks constructor and it has a variable declared. And then suddenly out of nowhere, that variable that field has a value. How can you understand that if you never worked in Spring and never used Lombok? Maybe you never used Lombok, you might easily understand that Lombok adds there somehow magically a constructor, okay? But then where is that variable still getting that value?

So it might happen as a starter with a framework, even as an experienced developer, because you might have years already with Java development, but you might have used either different frameworks where it was more obvious what happens, like say, Google Guice, for example, where you have a specific declaration for the injection. Or you might not have used the tool for an application framework, you might have simply used Java Standard Edition because there are still a lot of applications that don't use frameworks. They are old but they are not changed. They are just maintained with the existing technologies. And the idea is to make things as smooth as possible for someone who starts now having very little knowledge or not at all about frameworks or Spring. So that was the idea.

Getting started with Spring Boot

Mark Heckler: That just brings back so many thoughts and so many memories, because I think about when someone comes new to Spring, and I say Spring specifically because that's what we're talking about. But, again, as you mentioned, it's not alone in this regard. It's probably the most obvious example, though. My background was hugely Java Enterprise Edition, Java EE. And when you come into Spring, it's, I use the term tongue-in-cheek, jarring, right? Because you are not used to what’s there. There are so many things that are handled for you by the framework. You think you know code, and you do, and then you come into a Spring brownfield application. Someone's created it and they hand it to you and say, "Okay, we need you to come up to speed on this." You look around and go, "Where is this stuff being created? How did this happen? How do I peek into this and debug this? Because I'm just seeing this instance, this object is auto-injected into my stuff. And now, where do I find this? How did this happen?" And maybe there is just a property defined. And it's like, maybe there's no property defined. It's just a matter of what's on your classpath. And once you learn all of that, I think you start to see a huge amount of value.

I assume you had a similar path or similar trajectory where you came into Spring where you were used to doing things very methodically, very, I don't wanna say boilerplate, but there was a lot of code to do something and then all of a sudden, it just vanished?

Laurentiu Spilca: Yeah. So similar to your case, I started with Java EE a long time ago. I was pretty comfortable with the architectural style of Java EE, where you have this application server, and you were simply creating some kind of web archives, and you were simply deploying those web archives. It looked very logical in terms of you knew who is controlling and what is controlling. So you knew that your work contains your classes, which are the control classes, and you knew that you have an application server GlassFish, or whatever you had, and that was the one controlling. So the inversion of control was, in my perspective, a lot easier to see when I was using this kind of architectural approach that Java EE at that time was using. But when I moved to Spring, suddenly it was something inside my application that was still controlling my application. So I found that pretty difficult to grasp at the very beginning.

Mark Heckler: Right.

Laurentiu Spilca: Because if you have something in your application like if we were still having dependencies for the VAR files, I will say I added a dependency for my VAR file. I was expecting that my class and logic in my classes control the logic in those libraries, use somehow those objects to implement business cases. When I changed to Spring, I didn't see a container anymore whether it was still the dependency but somehow from inside the dependency it looked like it was controlling my classes. So that was one of the things that I found difficult to understand when I started with Spring. And it controls the classes in the same way as it was happening in the Java EEs, right? So you still have your own we call them aspects in Spring, they were interceptors in Java EE. We still have dependency injection, we just change some annotations and of course, the bean lifecycle is a bit different. It means the same thing but it looks a bit different. And it created some difficulties at the beginning when I started with that.

Mark Heckler: Sure. Yeah, and I don't mean to minimize any of the similar constructs or like the managed beans and things like that. And this is I think one of the other things that are nice about your book. You use bridge learning. So you take someone from where they are and you carry them to where they need to be. But I do think that it was, I don't wanna say a paradigm shift, because, again, there are some complementary concepts, but it was falling off of a learning cliff for me because it was kind of a huge shift in just the level or maybe the completeness of the landscape within Spring. I'm trying to think of better words to say it and I'm just coming up empty.

Spring Boot’s focus on deployability

Mark Heckler: But proceeding on through the book. In the second portion, the implementation, you launch into understanding Spring Boot and Spring MVC, which I'm particularly excited about obviously, implementing web apps to Spring Boot and Spring MVC, Spring web scopes, REST services, REST endpoints. And then we'll get into some of the other things here momentarily, but I just want to pause for a moment and chat about Spring Boot, because Spring Boot, I think, was a huge paradigm shift, again, with Spring Framework because it focused a lot more on deployment, deployability, and how you would deploy applications. 

Laurentiu Spilca: Yes. 

Mark Heckler: Any thoughts on that?

Laurentiu Spilca: Yeah, so Spring Boot changed a lot in my perspective. I started with Spring when there was no Spring Boot out there. And now, you don't think about Spring without thinking about Spring Boot. And the book I wrote, "Spring, Start Here," definitely doesn't cover, but a very small part of Spring Boot. So my plan wasn't covering Spring Boot in the second part, it was still Spring, and I still discuss the very fundamentals, so you will find discussions about beans, web scopes, as you already said.

Laurentiu Spilca: I obviously did refer to your book because I really enjoyed reading your book, "Spring Boot up and Running." So, as a second step, if you started with, "Spring, Start Here," then the second one to go deeper into Spring Boot would definitely be "Spring Boot up and Running," by Mark Heckler.

But now going back to the question. Spring Boot changed my perspective on natural evolution in software development because if you take a timeline you see Java EE, with application servers they were kind of this monolithic approach, at least the way they were at that time. So as an architectural style, they were linked to the monolithic approach of deploying applications. You had a very large container, and you just put your applications in there. That's the GlassFish. You have a glass and you have the fish inside.

But now we find, at least on what concerns the server-side, we are progressing to a more sort of service-oriented approach throughout time and then to micro-services and then to serverless but that's another story. The idea is the following. The more you progress in architectural styles point of view to service-oriented because we have more requests, and we need to deploy them in a different way using Kubernetes and orchestrators and technologies like this, putting them in containers, though, the more you have to recreate again and again the skeleton of a new application. So years ago when I was using Java EE, I didn't have to create so many applications again and again because I had one. It was a monolithic approach and I was just making it once and then years, everyone working over the same application.

My students and I, at that time, had trouble. And that was a real pain when in the class we have to discuss, for example, building web applications with Spring because, in class, you have to create a lot of projects, you have to create a lot of examples. So in order to create one example with one endpoint and prove how it works, a simple REST endpoint or whatever you're building, you have to spend 30 minutes just configuring the application. So nobody understood us at that point because usually, in the real world, you didn't need to build applications.

But once this started to happen in the real world, because now suddenly, you have multiple services, so today, you build a microservice, tomorrow you might need to build another one, then it's starting to become a pain as well. And this is where Spring Boot is going to save us because we also observed at the same time while recreating a new project that sometimes... Not sometimes actually, very often, in most cases, we do configure the same thing. So what we did figure out actually is that we have a convention that in most cases, we have 90% or even more of the things that we are doing, are usually the same. And this is what's called a convention.

And what Spring Boot introduces is the convention of our configuration approach, which means we from the framework or project, in this case, decide which is the convention based on the community decision. So the community says, "99% of the cases is Hibernate." Okay, Spring Boot, this is the convention. We configure an “out of the box Hibernate.” If we see the dependency in your com XML in the CLASSPATH. We configure such a dependency, as a convention. You can still change it, you can customize it. Maybe Hibernate is not your choice. Maybe you want to use Eclipse League, that's good. But since 99% of the users are with Hibernate, why not give them that out of the box without forcing them to write I don’t know how many lines of code and then to configure that dependency? And that was just an example with Hibernate. But that's the same going to be with all of the technologies out there that are part of the convention.

Advantages of Spring Boot: what is an actuator

Laurentiu Spilca: And of course, that's one of the biggest things that we see in Spring Boot. But there are a lot of other advantages out there, which are again, linked to how the software architecture evolved. Like, for example, the actuator. Why is an actuator needed? Many years ago, there was no such thing as an actuator. If something didn't go, well, it was 3am, doesn't matter, someone was on call, you called them to restart the application. That's how, well at least at that time, in many cases, it was happening. Now we evolved a lot we don't do that anymore. We have an endpoint or a different approach in which another software called an orchestrator figures out if the application is not working anymore and if the problem can be solved with a restart, so it automatically destroys and recreates a container and restarts the application.

It was important at that time to call someone at 3am to do the restart. But now, it's done automatically and they don't have to bother someone, or at least not so often as it was happening many years ago. And one of the advantages as well, and that will be the last one because I already talked too much, is, for example, having all the startups. You know, one of the problems we have is dependency compatibility. So we have a lot of libraries that we use. And if they are completely independent, one of another then they might become incompatible. And when you just increase the version of a library, because you want something new that you need to use from that library, and then figure out the other libraries don't work anymore. So if you have something that at least gives you some comfort in, you have only to increase one number and then automatically it increases behind the scenes, whatever are the numbers needed in the versions to make things work, then it's of course, more comfortable and easier than having to do that yourself. So there are so many ways in which Spring Boot changed the way we work. I think it is basically one of the best tools we have at the moment.

Mark Heckler: Yeah, and you know, it's interesting because so many things that you said kind of point me and just ring bells in the back of my head because it seems like when folks first get exposed to Spring and more specifically Spring Boot, they either just love it, I mean, just out of the gate, "This is amazing," or they really recoil and think, "Oh, this is, I don't know, I mean, this is a lot of magic." You know, we talk about opinions in the Spring community and how it's an opinionated approach and an opinionated framework. "Feels a little overwhelming." And again, I relate, I completely relate to that. To some degree, although I was pretty excited forgot about it once I saw the possibilities.

Mark Heckler: But I think especially if you've been around long enough to have gone through the other side of it, as many of us are. You know, we don't necessarily jump right into Spring Boot from university. We have a circuitous path to get there. Maybe we've maintained a Java EE, or now Jakarta EE, application, although there are still a lot of plain and simple Java EE applications out there and will be for a long time because of inertia, right, and older versions of Spring Framework applications from forever ago that are just being maintained, of course, like everything else.

But I think it's important to remember for those who might be a little nervous or kind of hesitant about the number of opinions, the number of opinions, and the number of things that it does for you, I don't know if you ever worked in a corporate or a large organization type of environment. I suspect you have because you mentioned university, so, I mean, I know you've done several things that are both really good and really terrible. You know, it's like all of us. You know, we have those high points and low. But many times in large organizations, they have some kind of a, I don't want to call it a starter or a wizard, but you have some procedure or process.

Sometimes it's very automated, sometimes it's not automated at all, that when you want to create a new Java EE, Jakarta EE, Spring Framework application, I'm thinking back years ago to a company that I worked for, that they would have, and actually multiple now that I'm thinking about it. They would have a way to create a new Java EE application, which meant that certain dependencies had to go into every application, there was a certain order of steps that you had to do to generate or that's overstating it, to create a new project that was blessed, that was approved by the company that would get you the things you needed to tie into the network, to tie into the platform that was a deployment platform, I guess, for lack of a better way to put it. And you had to follow these 72 easy steps to accomplish this. And Spring Boot took us from doing that, and I think that's where a lot of corporate developers got really excited, because instead of going through this very tedious, long process to accomplish these things and get an application that you could build and actually deploy, not painlessly, but it would fit into the portfolio of applications your company ran. Spring Boot gave you the ability to do that in just a few seconds using the Spring Initializr.

Laurentiu Spilca: Yeah.

Mark Heckler: And it does a lot of the same things, but it does them so much better, right?

Laurentiu Spilca: And then probably the most important is that when you have a thousand enterprises, they might have, as you said, their own documentation on how to do it. But they're still different. So there are still one thousand ways of doing that.

Mark Heckler: Yes.

Laurentiu Spilca: Maybe there are one thousand good ways of doing that. But if you change you as a developer, from one enterprise to another which happens, then you have to again, relearn how to do that in that second enterprise. But now, if you have something provided by the community and it's unique for all of them, then it automatically becomes a lot easier for us to work with.

Mark Heckler: Yes, and that was another thing, and I'm glad you brought that up. Because when I went from a large, private enterprise to a large public organization that I worked with for a number of years, it was that exact scenario. You had a completely different sequence of steps to get to where you can start an application. And now literally you have the Spring Initializr. And of course, the Spring Initializr is customizable. Organizations can tailor that to a specific thing. But so much of that work is done. And you mentioned this and explained this so well in the book, that you're looking at capabilities, not in, "Okay, these are the 17 libraries that I need to add to do what I need to do for this application. Well, do I need to do this or do I not? Add it just to be safe."

No, with Spring Boot you have a capability. Do you want to create a web application? Then add this capability, and that capability has these libraries, these components that it uses and they're version synchronized. So I don't have to worry about, "Well, let's see. This looks like the current version of this library. I'll add that. And this looks like the current version of that library and I'll add that. Why isn't it working?" Well, because library C is at version 8, and when it was tested in your organization, it was tested at version 6.2. So now, what do you do? Do you go back to 6.2? Well, no, there are security concerns that were raised. Now, what do I do? How do I make this work together? And it's terrible. But when you don't know any different, it's what you're used to. So I think that's why some people immediately jump on Spring Boot and some people are a little nervous about it, because, like, "Can it be covering all this ground really well, if it does it like that versus taking, you know, two weeks to create a new project?" I don't know.

Anyway, yeah. And that's why when I was reading your book, I felt like you and I were sharing a brain because I feel like there are a lot of things here that are common experiences. And I think that's not specific to us. I think so many in the community have gone through these same things, or if they haven't experienced them personally, they've seen them at close enough distance. Even if you haven't been in an auto accident, you've probably driven by one and thought, "Wow, that looks horrible." Well, you know, that's the same thing when you're dealing with certain software development constructs, you may not necessarily have suffered through them yourself, but you've seen them close enough to know that they're a problem and you don't want anything to do with them, right?

Data sources in Spring Boot

Mark Heckler: So you covered data sources, and I like that you start with the JDBC template and go from templates to repositories. I think that's just brilliant and that's something that I strongly encourage people to do for understanding. And data persistence, transactions, testing. I wanna come back to testing. I don't want to jump into that just yet. But the data side of things. Let's talk about that a little bit. How did you decide to include that? How did you decide how you wanted to approach that?

Laurentiu Spilca: So first of all about the data source, we don't have an application without having a way to persist with the data, or, in most cases, we don't have. So as a developer, you most likely can avoid having to work with a database. And the subject is very complex so it's no way you can treat it in one chapter of a book, it's even no way you can fit it in one book, it's maybe a shelf. But because you have relational databases, and then all the kinds of no SQL technologies, Cassandra, Mongo, Redis, and so on, and so forth. So what I did is, still thinking about the target audience of the book, I started with beginners, people who might not have used Spring at all, people who might even not have used an application framework at all. So then I decided to go with the very basic stuff also from the data source point of view, which is relational databases.

And now there are two things in my perspective that someone now needs to be aware of when starting with Spring, first of all, is directly using the template over the standard of JDBC which if someone might have even worked in an application that doesn't use a framework at all, they might have been unlucky enough to use those prepared statement results have stopped, in which, in order to write a very short SELECT query, you have to write 20 lines of code, and in which you have to, of course, treat sequel exception with an empty cache. And is not that it should be that of course, that is what usually happens in any kind of such applications. So JDBC template, first of all, one of the things I really liked many years ago, and I started working with it is that it minimizes the amount of code you need. So you simply need to only go with a mapper and the query. So it seems in parameters, so everything that's really needed, you need to give them otherwise everything else is behind the scenes. Secondly, it changes the checked exceptions into runtime exceptions. So it's a little bit easier to avoid the need of creating an exception unless you really want to do that because the compiler doesn't force you anymore, to do that.

So that's where I started and I thought, first of all, as a beginner, you need to understand what the data source is. And that's because, in any real-world application, you don't use driver manager to get the connection anymore and create your own connection, you need to have that kind of an object managing your connections, which again, going to data convention today in, if we use Spring Boot, it will be Hikari out of the box. Then after you understand what the data source is, just go a step further and understand it's templating over the JDBC that's provided by the JDK, but you don't want to use that because you want to have a simplistic approach and an easier to read and a more maintainable approach, which is what Spring offers.

Laurentiu Spilca: And then the next thing, the next step is to understand Spring Data. And Spring Data is this project, which is a part of the Spring core system. And we use it very often today, which abstracts a lot the persistence layer, it's an excellent way to implement the persistence layer because you have to literally only write the query when you need it. Sometimes you don't even need to write the query but that's another story. The idea and the difficulty I had here is what do I use to prove how Spring Data works? And in 90% of the cases, people would have advised them to use a Spring Data JPA. Spring Data is not only one Spring Data, you have Spring Data JPA if you really want to use the JPA implementation, it has to be Data JDBC and then you have the reactive Spring Data and then you have all the Spring data for the families of multiple technologies.

Laurentiu Spilca: And I said no, I actually didn't take advice and I went to Spring Data JDBC. And the reason why I did that is that I realized, if I introduced Spring Data JPA then I either have to at least teach the reader a minimum of what JPA is and use the JPA implementations such as Hibernate, for example, or assume that they already know that which if you think in terms of the subject of the book, we wanted to focus on Spring, not any other technology, I decided to use Spring Data JDBC, just to avoid introducing another framework that might or might have not been already known by the reader. Still, Spring Data is the same so the hierarchy of interfaces that it posts to interfaces is the same once you learn how to use one of the Spring data, either it's JDBC, JPA, Mongo or Cassandra, or another one from the NoSQL family, you still understand and you will be able to adapt your knowledge to use any of the others. So I chose Spring Data JDBC, just to eliminate one of the requirements out of my book, considering it's a book for at least beginners with frameworks. That was a good point.

Mark Heckler: I think in you mentioning this, again, this is one of the great things about a great conversation, it reminds me a lot of the ceremony. Data is a great example of the amount of ceremony that Spring Boot, and Spring Data in this specific instance, gets rid of because there's no reason to open and close connections, there's no reason to deal with driver manager because literally every time you deal with a database, you do the same sequence of steps in a Java EE, I'm thinking back to the old days, or Jakarta EE application. You have to get this connection. You have to deal with certain things. You close out the connection. You have to make sure that everything is clean. But every time you deal with a data store, you're doing that. So why wouldn't you want certain opinions to be incorporated into your application by the framework that handles that for you? If you know that literally 100% of the time, you're going to follow the same few steps, bracketing what you actually want to accomplish, why wouldn't you want that to be handled for you? There's literally zero variation in many of those cases. And in the very few exceptions, expose a property or create a bean and do things but it's so minimal.

You get to that point and you start realizing, wow, that was one of the eye-opening things. I talk about sometimes that we get numbed when we go through a lot of ceremony and boilerplate to do something the first time, it feels, "That's overwhelming. That's a lot of stuff I'm having to do just to issue this one update query when you're retrieving values." But I go through all this stuff to issue one statement. That's just crazy, and then to deal with what comes back, of course. So the first time, it feels like a lot of work. The second time, it feels like a lot of work. But by the time you do it, 10 or 20 or 50 times, it just seems like the normal thing you have to do, right? This is what we have to do. It's no big deal.

But when you see that there's a way to completely strike all of that and you talk about the conventions. In the book, you mentioned the conventions of the method naming. And I don't want to spoil the surprise. No spoilers for folks who haven't read the book yet. But you talk about different ways you can craft queries, or have the framework provide those queries based on a convention, once again, convention over configuration, and it's breathtakingly simple and deceptively powerful as well. And you start thinking, "Why isn't everyone doing this?" Yes.

Laurentiu Spilca: It also avoids tempting the developer to copy-paste a lot of lines of code.

Mark Heckler: Yes.

Laurentiu Spilca: One of the things that was happening when you were using the old fashioned JDBC way, or anyway, at least one of the ways where you write multiple lines of code, what I've seen is that the developers were tempted to just copy-paste them. And when you copy-paste code, then, of course, we already know that's not something you'd like, usually to do, because you copy-paste faults as well and yeah, we don't duplicate lines of code. 

Testing in Spring Boot

Mark Heckler: Yeah, there's a lot of baggage that comes along with that. I don't feel like we would be doing this conversation justice if we didn't talk about testing. And you cover testing in a chapter of your book. Testing is one of those things like you mentioned on data and several other topics, you literally could, and people have and will, write entire volumes about, and very valuable volumes. But you have to address it in a way, again, keeping the focus on, you know, "Spring, Start Here," the person who is new to Spring. How do you incorporate testing? How does it make sense to dip your toe into that water and to immediately get value out of testing your Spring application? I mean, I don't have a specific question, but I'm just curious what your thoughts were on testing. I notice you put it in the last chapter. This was something I struggled with too because you want to cover it upfront. But if you cover it upfront, do you feel like if you'd put it upfront it would have kind of muddied certain concepts that you wanted to highlight? I'm curious why at the end?

Laurentiu Spilca: Yes. So that's a very good question that some people already asked me. First of all, I didn't want to end the book until I have something about this thing there. So that's definitely something that should exist, whether it's the first chapter or the last chapter. In my perspective, I believe the reason I chose to put it in one chapter, by itself, is because there are usually two ways of writing technical books. Some authors, just accompany the code with unit tests in every chapter. So write the example, provide the test for that example. And the second approach is where you just take the tests, and you put them in one chapter, and all the others, they don't have anything related to unit tests.

So I chose the second one and when I chose the second approach, I was still thinking about this student that is my target. First of all, I just considered at the very beginning, that they don't know anything about this thing at all. In my mind, I have this student, they don't know anything, they don't even know what a unit test is. So if I give an example of a unit test, in this first chapter, or the second chapter after mentioning about for example, how to create a bean, then creating a bean is already something they have to learn. If you put them in a second subject, then it might be overwhelming for them. I was afraid to make the book for the target audience overwhelming. So I thought about what I did. I added the sidebar, some summary in the first or the second chapter and I said, I created unit tests for you and the book comes with 70 plus projects that I've studied throughout the book. If you already know what the unit test is, you might already know what the unit or integration test is, then you will find a unit tests with the project. So you can just stop now take a look at them and run them because you already know what the unit the test is. But for all the others just read the subject and then at some point, at the end of the book, we will discuss testing and how to test implementations and why the tests that we will find in the projects look the way they look like. So that's why I took this decision. It was a difficult decision because I don't think one approach is better than another. I just went the way I felt.

Mark Heckler: Yeah, and I didn't mean to put you on the spot because I struggled with that too, but I do think it's important to remember what the overwhelming focus of the book is, which is Spring concepts. And your first whole section was fundamentals. If it were a testing book, you know, "How to Do Spring Development Using Test-Driven Development," then that would probably be front and center. You'd have that with the first chapter and you'd use that throughout the entire book. But I really do appreciate that you incorporated it without having maybe overwhelmed the reader who's starting. You were very aware of your target audience, which is someone who's coming into Spring as someone new to Spring. It's a critical concept, but it's not something you want to get in the way of explaining perhaps what dependency injection is, right?

Laurentiu Spilca: Yes, yes.

Mark Heckler: Completely agree.

Laurentiu Spilca: And even the content of the last chapter was particularly difficult to choose because as you said some minutes ago, this thing is something that, again, can be part of more than one book, we have so many kinds of testing now, so many frameworks. You can do stopping testing, you can do just integration testing, you can integrate without the database, you can do integration tests with the database. I don't even know if I know all the options you have for testing. I'm pretty sure I don't know all of them. So how do you choose? I simply chose unit tests versus Spring integration tests. And in the very beginning, I wanted to have a third approach. Being the fact that many examples of the book were about web applications, I wanted to discuss also, using mock MVC, and this in the contract. Unfortunately, I didn't have enough space to integrate that subject also. But I tried at least to make a minimum of explanation of what the test is, why is it necessary? And people understand at least the steps. You prepare the scenario, you call the method, and then you validate the assumptions. And that was the plan of the last chapter, the one related to this.

Mark Heckler: Yeah, and I think you did a great job with that. I also do appreciate that you mentioned you do call-outs. So here's a book that you might want to check out. I know you probably didn't intend for me to mention this, but your "Spring Security" book is also out there, and I think that that's a very valuable reference as well for folks to check out if they're looking to secure their Spring applications. But that's something that you should take note of because Laurentiu has also created and written a superb volume about that as well. We could probably go on forever. We will later. But for this discussion, I do want to point out to folks that this is the book "Spring Start Here" by Laurentiu Spilca. Check it out. I just find it invaluable.

And I think no matter where you are on your Spring journey, or development journey, or career journey, I think this is a field that you can never know everything about, and that's a good thing. Because that gives us plenty of material, new material and material presented in different ways that we can make ourselves better. And I just thoroughly enjoyed this book. I hope folks will check it out and enjoy it as well. But, Laurentiu, I will let you get back to your evening there and we'll carry on in a different conversation. Thanks for joining me. And thanks to the folks at GOTO for providing this opportunity to chat in a little more structured format than we might otherwise.

Laurentiu Spilca: Thank you very much, Mark Heckler. Thank you for having the opportunity of this discussion. And guys, thank you again for reading our conversation hope you have an excellent time and a great time for study for the year. Cheers.

Mark Heckler: Always a pleasure. Go, Spring!