Spring Boot: Up and Running

Spring Boot is a versatile and supportive environment for developers. Mark Heckler, the author of Spring Boot: Up and Running and Thomas Vitale, software architect at Systematic, explore many of its capabilities while discussing Mark’s book. They cover hot topics such as data integrations, deploying in production, security, and reactive vs imperative programming. They both share their views and transforming experiences of joining the Spring Boot community.

---

Intro

Thomas Vitale: Hi, everyone, and welcome to a new episode of "GOTO Book Club." I'm Thomas Vitale. I'm a Software Architect at Systematic in Denmark. I'm really passionate about Java, Spring Boot, about cloud-native technologies. Today I'm really, really happy to introduce you to Mark Heckler. The great Mark Heckler. He's a Principal Engineer at Microsoft. Before that, he was a developer advocate on the spring team, and he was also an airplane pilot. How cool is that, right, Mark? How did you get to become a pilot?

Mark Heckler: Oh my gosh. Well, thanks. I'm just happy to be here. You and have chatted over several years in various different venues and it's never enough time, so I'm just happy for another excuse to drink coffee and chat and catch up. But ever since I was a little kid, I always would look up at the sky when I'd see a plane or hear a plane go over and try to find it. It was something I always wanted to do. I kind of had a couple of like intros, like just touch points over the years, but nothing very serious until a few years ago when I decided to make it a little more serious.

Then over the pandemic, I actually wound up completing my private pilot's license and then my instrument rating. I have a simulator back here that I use when I can't get out when the weather's just terrible for a long stretch of time or something. Plus, I'll throw on a shameless plug, Microsoft Flight Simulator is just gorgeous and just really beautiful to fly with from a desk. My wife and I bought an airplane. It's not big, fancy or anything like that. It's just a very solid, stable, nice plane. And we take nice trips, you know, and it's just fun.

It's kind of fun to apply the analytical abilities as a developer to something different and kind of exercise your brain in different ways. If you've ever flown or talked to aviators or pilots, sometimes they talk about the visual flight rules, VFR flying, where you have to look outside the cockpit and you're looking around, maintain horizon, situational awareness, and look for aircraft. Then when you get your instrument rating, you take your focus back inside the cockpit, not exclusively, but obviously, if you've got very poor visibility, all you can see is your instruments.

But for us, for people like us, I mean, that's perfect, right? Because we trust the computer all the time. So whether it's analog gauges or digital and everything's digitized throughout the cockpit or not, nothing is you've got this full spectrum, you know, this full range, but it's a very natural, I feel like, a natural feeling for us to focus on trusting the gauges. That was something that I particularly enjoyed. So it also gives you a lot more flexibility in when you can fly because if the weather's kind of not great, you can still go out and fly and again, get to where you need to go or want to go at that point in time. So a lot of fun, a lot of fun.

Thomas Vitale: Yes that's really cool. And perhaps it gives you a fresh perspective about really how software impacts our daily lives also. How important it is that it works, that it's high-quality software that we can trust, especially in these domains where it's really critical that it doesn't fail. We have to be able to trust the measurements.

Mark Heckler: It is very true. That's a phenomenal point because you've got your software, which you have to trust. You also have the hardware, which has to be certified for airframe use or aircraft use. And then you also have the data because... And again, like any domain, if the data is stale you have problems. Well, of course, in aviation that could be life-threatening. So you have data that's provided by governments and by companies who bundle this up and supply it as data feeds or packages to your equipment.

It's kind of the three-way connection and the three-legged stool, you get the hardware software, and data and all of those have to be good, current, fresh, reliable, and resilient. In aviation, everything is usually too deep minimum. And the same thing with our systems, you have some form of resilience in some capacity to make sure you're always online, always servicing your customers and your community's needs. That's absolutely critical.

We do that kind of, I don't say without thinking because we're always thinking about that stuff, but it becomes such a naturally ingrained part of our lives that we just do it kind of, pardon the expression, on autopilot, right? Everything we do, we try to look at maintaining that backup plan two or three levels deep and whether we incur those costs or whether we just make those plans, one way or another, we have to accommodate those kinds of situations.

Thomas Vitale: So true. It's really great to chat with you today. As you said, we've been talking virtually for a while and we finally got to meet.

Mark Heckler: Yes.

Why Spring Boot?

Thomas Vitale: Also, a couple of months ago at Devops it was great. Yeah. So, today we are here also talking about your latest book "Spring Boot: Up and Running." A really great book. I can see the cover behind your "Spring Boot: Up and Running." So how come, yeah, did you decide to write this book? What was the idea behind it? How did you decide to approach, like, covering this subject?

Mark Heckler: That's such a terrible question to ask me because I feel like just by doing it, I broke promises that I'd made to myself. I had been asked and invited to contribute content and code to other books before. And I'd even co-authored a couple of them with just a phenomenal team of friends and fellow developers across different companies and parts of the industry.

And I had a great time, but I realized very quickly how much work went into creating the content and writing it and capturing it clearly and making sure that you kind of stayed on message and didn't like amble for 60 pages in a chapter, or didn't like wrap it up in 5. There's always this balance, what you include, what you don't include, and trying to get across the finish line.

Well, when you have a team of folks who are doing that, it's challenging, but when you look at the amount of work that is involved and you think, "Wow, would I want to do that all by myself?" Well, the upside is you get full creative control. Well, to some degree, you have an editor and a company that you're working with to publish, generally, but the downside is all that work falls on you, and the graphics and the examples, the diagrams, and I need to wordsmith this a little better because I'm not satisfied with it, instead of going, "Hey, Carl, you need to maybe rework that or something because that's not...I'm not exactly clear what you're saying."

You have to try to read that and catch that. And, of course, you have technical editors and stuff too, but you're trying to constantly write and revise your own stuff. And it's a huge amount of work, but as an advocate, I was always out talking to folks and doing presentations and just catching people afterward and them catching me and having great conversations, but certain questions would keep coming up. And I had teammates and colleagues who had written books, and they're good books, but everybody has a different perspective that they say I want to bring these things to the table because I think they're absolutely important.

And it's not that you don't think other things are important, you just have to choose. So, you choose what to include, and what not to include. You choose how to present what you're including, and maybe the extent that you cover it. And sometimes, I mean, let's face it, you'll write an article or a book and you'll say, "Well, I really didn't cover this one thing as well as I would've liked to, but I just didn't have the space to cover it without cutting something else." But those are trade-offs we all make. And each one of the other books that I would recommend to my colleagues and friends and teammates, I always felt like that, that their perspectives were excellent, but I had a different perspective.

And then when people would come up and say, "Well, what about this?" It's like, "Well, okay, that wasn't covered really well in this book, but it's kind of covered in this one." And then I'd take a note. If I ever do write a book, I will include it and I will mention this because this seems like a recurring theme people are confused about, or just curious about. So, I had this outline put together, and now a dear friend of mine, who's also an editor at O'Reilly contacted me and said, "Hey, I want to talk to you about doing some work with us." And in some other capacity, I don't remember exactly what it was.

We were just having a great conversation, just like we are here now. And somehow I just kind of slipped out and I said, "Yes, I've got this outline of stuff that I'm putting together. Just Spring Boot-based topics that I want to cover at some point, should I ever write a book?"

And she said, "Well, like what?" So I said, "Well, you know, this, that and the other thing." And she said, "Well, when can you get me an outline? I said, "Well, I've got it now, I can send it after we disconnect. It's just something I've had kind of compiling over the last couple of years." And I sent it to her and then she pinged me and said, "We need to talk because I really want to do this." And I said, "Oh, okay." You know, I'm thinking, maybe a year or two years out. And I'm still kind of not that interested in doing a solo book, but the more we talked about it, the more I thought, there really is a gap here.  Again, it's just a matter of what you choose to cover and what you don't and everybody's perspective is different.

So I felt like I could add to the conversation in a positive way, hopefully. So I wrote the book, and interestingly enough, it kind of hit over COVID where I spent a lot more time at home. So, I won't say I was able to get it done faster because what happens is, you've heard the expression "Work expands to fill the time allotted to it." So if you allow three months for something, it'll take three months. If you allot six months to it, it'll take six months. But what that did give me time to do is, is iterate on it a little bit more than what I may have been able to. The downside is no matter how much time you have, there's never enough time, there's always this amount of material that you're wanting to put into this much space, and you always still have to cut out things that you really wanted to include and not include them. So, what I started doing as you might imagine, is creating a checklist of things, like, should I do a follow-on book, I want to include these things too, or in lieu of something that I put in the first book. So I started that list while I was writing the first book and swearing I'd never do that, and we'll see.

Thomas Vitale: So perhaps, a year from now, we're gonna be here again, talking about the follow-up for your book.

Mark Heckler: Well, it's funny because we have been talking about with "Spring Boot 3" coming out, revising, but you know, here's the interesting thing because the fundamentals, which I tried to hit heavily on the fundamentals and then lead into some things that were, you know, more advanced topics, more broad-based, and not just beginner topics, but things that led naturally out of those topics and a lot of the foundational topics have not changed and will not change. You have increased capabilities and you have some things obviously that tweak and change of course, with a major version number.

But as far as those core fundamentals of things that we need to know, or that somebody new to the Spring Boot realm needs to know those are pretty solid, right? So whether you were on Spring Boot 1.X, 2.X, 3.X, those things at their core won't change, you know, different things about them will and you can take a few different explorations off in different directions. So there will be definite changes, but as far as the fundamentals, I feel like I've captured those pretty well. That said, like every other author, there are always things that are like, "Eh, I may tackle that a little differently next time." So we'll see.

Thomas Vitale: Yes. Spring Boot was really a game changer in the Java ecosystem. I remember when, yeah, I was working with spring framework at the university and one day the professor introduced Spring Boot, and wow, it was mind-blowing because I spent so much time working on a lot of different infrastructure of features in the application, like getting all the security done, all the data integration and then Spring Boot. Okay. So all my code now I can just remove it, it's not vivid anymore.

In the beginning, I was a bit sad because I spent so much time on that. And then I realized, "Oh, wait, I don't need that anymore. Now I can focus on the business logic." And I found out that I spent so much time on all these supporting functions, but not much on the business logic which was really small. I mean, it was a university project, so it was a small thing. Right. It was really a game changer for me. What are your thoughts, like, what was your experience with Spring Boot, and…

Recommended talk: Cloud Native with Spring Boot & Kubernetes • Thomas Vitale • GOTO 2021

Mark Heckler: It's funny you mention that because I think as developers, when we do something really well, like you've probably had some really, really clever code in there to do some things, and then when you find out, well, that really great code that I wrote, really tight, really efficient, really elegant code, that's just no longer needed. That's a little, I don't know, frustrating, I guess, but on the other hand, as you said, it's a matter of perspective because if you look at that, like, "I worked really hard on that." That's frustrating. If you look at it as, "Well, great. Now I don't have to worry about maintaining that. Now I can go on and focus on these things that really matter to my customers, my users, my community members who are contributing or using this software or using these libraries, whatever, that's gratifying.

So it's a matter of perspective. It's weird, right? Because many of us come to Spring from the Java EE/now Jakarta EE perspective. So we're used to a lot more boiler played in a lot of ways. And I was not unhappy, you know, I mean, once... I always tell people, you get used to as a developer, but specifically as an enterprise Java developer "in the old days" you know, like before spring. And that could be last month for some folks, you know, it's not like...or next month even.

But when you're used to doing things with a lot of boilerplate, the first time, it feels like a lot, right? I mean, you do a lot of heavy lifting to open it to establish a connection pool and open a connection to your database and do different things, you know, just so you can query. Just so you can find out how many records are in a table. You do the 50 small steps, I'm kind of exaggerating, but you have to do a lot of stuff just to find out you have, 50 records or whatever in a table.

So you go through all of this. And the first time it feels like a lot of work. And the second time it still feels like kind of a lot of work, but you're starting to get into the swing of things. So by the time you do that, 8 or 10 times, even though you're doing almost exactly the same steps every time, it just feels natural. I mean, this is how it's done, right? So you do this all the time. And then when you come to Spring...and you're like, wow, you know, and Spring Boot in particular with Spring Data, and you've got your repository sport.

And I realize I'm jumping heading potential conversation topics if we want to explore this, but when you get to the point that you have a repository and you're extending an interface, and again, for those of you who are not familiar with "Spring Boot" yet, apologies. But if you read the book, you will be... Or many other good books, I don't wanna just point you to mine, although mine's, I hope, is okay. But if you get to the point where it's, like, okay, Spring in general, Spring framework, and then, of course, the very spring project, spring data, Spring Boot, of course, spring cloud, spring cloud stream, you know, so many other umbrella projects, spring security, they take the position of opinions.

So if you do the same thing over and over and over again, and by and large, with very little variation, that's something that's prime for abstraction, that's prime for templatizing. I'm trying to think of a better way to say it that isn't necessary, doesn't imply a particular implementation here, and I'm failing right now. But it's prime for making an opinion out of that. So if you know that, okay, each time I want to talk to a database, I have to do these 50 simple steps, why can't we take the opinion that those steps are done for you in a consistent way, in this particular way by default.

Now, if you need to override that... And this is kind of where I go back before the Spring framework, because frameworks have existed for a long time in a lot of languages, but they weren't always very flexible. So, if you wanted to do something, you either did it the framework way or no way at all because that was the only way to do it. But Spring framework and especially "Spring Boot" building on that, you have a preferred way of doing it, an opinionated way, but if you need to override that, you many times can set a property or define a bean of a particular type, and Spring Boot's auto-configuration will look and say, "Oh, this property's defined. You wanna override this capability? So I'll back off and let you do that."

So it makes it really simple to do that, but 80% to 90% of the time, if you're doing things the same way over and over again, you just want it to be handled for you so you can focus on, as you said, the things that actually provide business value. So, to bring this back around, if you're coming from the Java EE world, for instance, and you have done things a certain way and it requires several steps to get there and you come into Spring and you're like, "What? I don't have to do anything. I just extend this interface and it's all like magic." You hear that term a lot. You know, it's magic, too much magic.

It's not magic, folks. It's technology. This is a very, very rigorous technology. It works, it's very easily inspected to see what's happening, and it's easily overridden, but it is a little disconcerting when you first come into it. So that was my experience too. When I started working with Spring, I was like, "Hey, I've got all this code that now it's just junk. I don't need this anymore. What's happening? I don't know what's happening under the hood." Well, again, that's when you learn how you can find out what's happening under the hood.

Every day you have new folks coming into the Spring ecosystem. People coming from other languages, from other environments, from other approaches, using Jakarta EE and you have students graduating from university. So having a way to share fundamentals and kind of that gentle on-ramp I think is super important to get people started hopefully in a constructive way. 

How to approach data integration in Spring Boot?

Thomas Vitale: Yes. And that's actually why I liked the way you started the book. Focusing on the main features of Spring Boots, for example, dependency management. So you don't need to care about that. If you want to just start, you're starting right now with Spring Boot, you don't have to worry about that. You have these starter dependencies, which are great. You explain auto-configuration, so it's not magic. As you said, like, doing things for you, so you can inspect the code and see what it's doing. And if you're not okay with that, you can change it, and customize it because it's completely flexible even if there are these opinionated conventions in the code.

And as you said, one of the main things, I guess, was data integration also you spent a few chapters on data integration and also the different levels of obstructions provided by the framework, which is great because the reader gets different perspectives at different levels of obstructions. And also, yeah, getting familiar with different ways of solving data integration and based on some use cases you can choose one way or another. So I really like that. Yeah. Let's talk about that. Like how did you decide to approach that topic? And I'd love your thoughts on that.

Mark Heckler: I knew you were going to ask that. This is tough because everything we do revolves around data, and as we kind of were talking about the flight data, you know, the airport data, all that stuff, it's sometimes critically important. Life and death are important. Sometimes it's just very useful. And I don't want to say it's less important, although it's hard to argue anything's more important than life versus death, the data is what really adds value to most applications.

There are a few applications whose reason for being doesn't revolve around data that are either provided or received, but generally very few. So it makes sense to have a way, a robust way, and a consistent way to deal with data that you're receiving or storing, retrieving, and storing in some fashion. Spring data is the data umbrella, I guess you'd call it the project umbrella for various ways of interacting with data stores in the Spring Boot and Spring ecosystems.

So, I've worked with several different databases over the course of my career, as well as several different databases with Spring data. So whether it's a NoSQL database or whether it's a relational database, you have capabilities like JPA, JDBC, which get you pretty much anything relational with very few exceptions. You have NoSQL databases. So document stores and wide table and graph and gosh, I'm trying to think like in memory and caching, just anything.

Spring data allows you to build on key abstractions that apply at some level across the board. So you have template-based access, and then building on that, you have repository-based access because there are going to be certain operations that regardless of the data structure are going to kind of be in demand and useful across the board.

So being able to find a particular record or instance of something, being able to delete a particular record or instance of something, finding all instances of something. I mean, these are things that kind of cut across all different data stores. So it makes sense to make those APIs very consistent to the point you can, and then to be more specific where you can't. And that's what Spring data allows you to do. So that was why I felt it was important to do that.

I, of course, used an aviation theme in the book to pull from, because I have a little device that pulls in, it's not really radar, but it's position reports from airplanes in the area. I created an option for if somebody isn't connected to that kind of thing. And I told in the book how to build your own, you know, basically with an antenna and a Raspberry Pi and whatnot. But if you...

Thomas Vitale: I think that was really interesting, that you chose to use the aviation domain for the example because sometimes I guess it's hard to come up with examples that are about interesting and educational. So I really appreciated that in your book.

Recommended talk: Spring, Start Here • Laurentiu Spilca & Mark Heckler • GOTO 2022

Mark Heckler: Even if you generate data it's useful, but it's not as interesting as when it's live. And I was trying to think what I could use that was live. And, of course, one, my love for flying. But two, you just need something that's like up to the minute. And if somebody isn't connected, I wanted them to still be able to do the examples, but if they wanted to do that, I mean, that's fascinating to see that you've got a Boeing 737, or an Airbus A320 that's flying over you to get to the airport that's, you know, 40 miles away and they're going to be landing or however many kilometers, sorry.

Aviation is one of those weird domains in that we mix Imperial and metric units. So you have all the temperatures in Celsius. You have, at least in the U.S., barometric pressure in terms of inches of mercury. It's just really weird. And you have nautical miles versus statute miles, and some things are statute and some... It's bizarre, but it's kind of, I don't know, once you get used to it, you kind of tune it out and just kind of go with it. But live data is always more fascinating regardless of what the domain is. If you can see it live and it's relevant to that second, I find that much more engaging for me, personally than, you know... That's why I liked and still like IoT stuff, because when it feeds you a steady stream of current, even if it's just current temperature data. Anything that's live is always more fascinating than just canned example data.

I wanted to try to show some different examples of Spring data and how it works with the different data stores to the point that somebody new to the subject would say, "Oh, this makes sense. I can use this, this, and this. And this foundation is very similar. It's very... It's set up to help me as a developer. And then when I need to deviate from that, I need to go off in a different direction, it's not that hard to do." So, that's how I kind of worked out from there.

Thomas Vitale: That was a great section, and really interesting to read.

Mark Heckler: Well, thank you.

Reactive programming and Spring Boot

Thomas Vitale: I guess one other big topic in your book is reactive programming. You have a couple of chapters about that. This is quite an interesting topic. The spring ecosystem has support for a reactive stack. So we have parity between imperative and reactive. That is great because we can build using the same programming model. So without having to learn too much new. Same obstruction, same interfaces, we can build these more scalable, more resilient, more cost-efficient applications. How did you cover the topic in the book? And so do you think...

Mark Heckler: I'm going to answer first with a question.

Thomas Vitale: Yes.

Mark Heckler: What is your... I don't want to say preference, that says it's a little hard, but do you lean more toward the I'm in the imperative camp or do you lean more toward the reactive seems natural, I tend to go with that first or something else?

Thomas Vitale: So if we are talking specifically on the programming model, so building these streams of data, I feel like it's more natural to me. And when I'm working with imperative applications and try to replicate that programming model, of course, I can't do that 100%, but once you get over the first step that might seem too different working with reactive programming. Then you overcome the first step and then at some point you just, something click and you realize, oh, but this feels much more natural to express the problem there that I want to solve. So when I work with imperative applications, I end up trying to do the same, but sometimes I just pay up because it cannot be done. That's my take on it.

Recommended talk: Full-stack Reactive Java with Project Reactor & Spring Boot 2 • Mark Heckler • GOTO 2018

Mark Heckler: It's so weird because my experience matches yours to a Tee. Everybody comes from a different perspective. So folks who are used to dealing with that kind of thing are used to thinking in terms of events and actors they are finally catching up. We're not talking to those folks. We're talking about the folks who are heavily based on an imperative type of model, a blocking type of model. And in many ways it is very, I don't want to say simple, nothing in tech is simple per se, but it's much more straightforward. It's much more approachable.

The problem is, of course, that when you start getting into more complex scenarios, it gets very complex very quickly. And that's where you go. Well, and where most of us, I think, probably look at and go, "Well, maybe this reactive thing is something we can use. And, of course, reactive streams focus on those interactions primarily. But it does bake in certain things. It lends itself naturally to a functional approach, to immutability. You know, you have a lot of things.

I always tell people it's also based if you're familiar with... Which early on, it seemed like people... You say, "Hey, if you use Stream API and Java." And they're like, "No, I haven't really gotten into that yet." Well, I mean, that was Java aids. I mean, you don't probably hear that as much anymore as you did when Streams kind of was starting out. But still it's not something that every... especially if you're maintaining brownfield applications if you are using some older applications...maintaining, I should say some older applications, you may not use a lot of Stream API even now.

I think it's helpful to remember and realize where folks are coming from because many times we're out there kind of like reaching out, reaching forward, and not everybody has that ability based on their work environment. So at least not to the same extent, it varies. 

Let's say we're coming into this new, we're looking at reactive streams, maybe that'll solve my problem, and you look at it and you think, wow, that's incredibly different. It seems really weird and kind of cumbersome, and I'm not sure I'm following this whole method of chaining, and does this make sense? And when does this happen and why is it not doing anything in the event of not subscribing to it and whatnot, the publisher?

So, initially, it's quite a different paradigm, but then once you kind of gets your head around it, you don't even have to be an expert at it. Once you kind of understand the concepts and how they fit together, it's like a jigsaw puzzle, you get enough pieces together and you start to recognize the picture and you think this is actually elegant. This works more nicely than the other does. I'm the same way. I approach things reactive first and then look at the blocking approaches maybe.

If you have a smaller application that doesn't have any scalability issues... I always tell people, that if you have a brownfield application or system of applications and everything's working, you're not having any scalability issues, your demand is not wildly fluctuating, everything's working, you're not having scaling issues, you may never need to change that to a reactive system, because once you start if you don't push that reactive streams paradigm throughout the entire pipeline, the entire stack, you don't gain all of the benefits from it.

In fact, sometimes you incur some of the costs of it without seeing the direct benefits of it, like any technology choice, right? So you may never change that system out, that system of apps out, but there are many cases where once you start that, then you go, "Wow, now that I've started here, I can retool this and I can retool this and I can change out my database drivers for reactive drivers.

And now you've got, you know, as we said, now you're cooking with gas. Now you've got the ability to do a lot more things and reduce some bottlenecks and improve. As you mentioned, the resource utilization and get more out of the same money you're spending or maybe even spend a little less to accomplish the job better than you were before. So, sorry, I get on a tear. And I'm kind of the same boat, I like the reactive first approach and, you know, with things like looming I think you're gonna see more people have more different options, which options to a point are always a good thing, right?

Sometimes you can have too many obviously, but I think that allows you to take advantage of some of the advantages of reactive programming and still maintain that imperative model, especially if you're coming from an imperative-based application or system of applications. But you also have that as a different option should you want to go reactive? So it's good to have choices.

Thomas Vitale: It's really good. I feel to recommend. So if you're new to reactive, you're thinking about going reactive, then I recommend first perhaps having some experience with the Java Stream API if you haven't used that because it will make things much easier once you get used to that paradigm of chaining different operations in a more functional way than when switching to reactive, the new part will be a synchronous way of how things work, but then the chaining and the stream feel already more natural because of what the experience with the Java Stream API.

Mark Heckler: Yes. And Lambdas, and the whole back pressure, these are topics and, and I guess, experience, if you've got...if you've worked with Lambdas before. Again the further we get from Java 8 in terms of down the road, the less that's going to be a concern. But if you're very familiar with Stream API and Lambdas, then you're probably not going to feel too lost when you're starting to work with reactive streams. Again, as long as you remember to subscribe, always subscribe.

Thomas Vitale: Yes. If you're in doubt, just subscribe.

Mark Heckler: Just subscribe. Yes, exactly.

Security in application development

Thomas Vitale: So moving to a different topic, this is one of my favorite subjects in application development, security.

Mark Heckler: Oh, yes.

Thomas Vitale: That you also, of course, cover in your book. You mentioned the overall paradigm and abstractions used by Spring security and specifically how it's used in two different cases. So when using more standard form login-based authentication, but also more sophisticated authentication and authorization with open and reconnect or to...

How did you decide which features to cover because security gates are such a wide subject? Very challenging, I think.

Mark Heckler: I think that the reason I covered it the way I did is I think if you're writing a small application for a very small number of users, it's like a, I don't wanna say departmental level, because even that's.. you've got a lot of considerations there, but if you got a very small application and you just want to do very minimal security, a forms-based authentication does a nice job of it. Now that said, huge limitations there.

But here's the other thing that gives you, is it allows you to introduce concepts at a level that most of us, I always joke that I'm the least secure person there is, and that's not because I don't know anything about security, it's because I don't trust myself. I think that's a good position to be in because you should never trust yourself too much. Always, verify everything and double-check and have somebody else double-check, have the system work for you, the platform work for you to try to secure your applications.

But that said when you start off with something that, is "relatively simple" yes, I did the air quotes. I try not to do that too much, but when you start off with forms-based authentication and authorization, it allows you to see those concepts in a streamlined way as possible. I'll take it even higher now for folks who are brand new to this, authentication and authorization, so they're easy to mix up because they both start with auth and we're human. So we misspeak. But generally, authentication is you are who you say you are and authorization is should you have access to resource X.

So, if you walk up to your company, let's say you're back in the office, or let's say you visit your office and you show your employee ID badge, that's authentication. I am who I say I am, right? So the guard at the front desk lets you on by. You go to the elevators, you go up to the third floor or whatever, and then you swipe into a particular room, or let's say you're coded based on your department, so you have to swipe in, so that's an authorization. Am I authorized to be in this room? So you've authenticated. I am who I say I am and you're authorized to be where you want to go.

So the same thing applies to resources, right? I am who I say I am, so I should have access to this application. Then do I have access to this resource? And that's your authorization like, okay, this is my photo, this is my document or things like that. So, they're very important concepts. Forms-based authentication allows you to kind of show all those in the simplest way and then going into the OpenID and oauth2 allows you to demonstrate that in a much more robust and scalable and industry-accepted and standardized way across the board.

We see various OpenID and oauth2 providers everything from Google, Facebook, Microsoft, GitHub, and I'm trying to think of others. Probably a dozen others who... Okta. In fact, I used Okta in the book. I mentioned that because they're just a great provider as well. It allows you to kind of segue naturally I think, and then get to where you want to go. 

Thomas Vitale: I like that. You covered all the most important topics. I like your teaching approach, how you build on top of the most basic scenario, then add on top of that and show the reader how we get to the more complex scenario in a way that the reader doesn't feel lost. 

Mark Heckler: Hopefully.

Thomas Vitale: ...Read Spring Boot after running, it's a great book.

Recommended talk: Expert Talk: Software Security • Jim Manico & John Steven • GOTO 2022

Mark Heckler: Hopefully, because most of the time, security is one of those topics that I think we're all a little... And again, I think rightfully so and in a good way, in a lot of ways, we're nervous because the stakes are so high in some ways. And as a developer, you spend most of your time working on business value, add type stuff.  Maybe you're programming complex chemical equations in software, or maybe you're programming, like change this button to blue, it doesn't matter. You're focusing on the end-user experience far more than you're focused on security.

We can discuss whether this should be the case, but generally speaking, the functional requirements tend to kind of dominate our thinking. I always hate that term, nonfunctional requirements, but the requirements like security are absolutely essential and critical to be baked in from the start and all the way through and constantly verified and tested and refined and improved. Most of us don't feel as qualified to do that as we do for the functional requirement side of things. So it's easier in many ways, us being human to go, "I don't know where to start, so I just will start." But we need to get past that and start easing Into that. That's the chapters.

Deploying production-ready apps in SpringBoot

Thomas Vitale: It's critical, so it's important to better understand it. Earlier I mentioned, how Spring Boot changed a lot of things. When I moved from Spring framework to Spring Boot, one of the things that I really liked the most was how easy was to build a production-ready application. So much built-in with the embedded server and executable standalone Java applications that we really like in cloud-native application and Spring product which is amazing, like out of the box, you get all these endpoints for monitoring and managing the application. You get multiple ways of deploying the application., I really like that you cover all the most important parts of that in your book as well.

Mark Heckler: Well, it's interesting you bring that up because when I wrote the book, Spring native was in early stages. I debated on whether to cover it. It was present but there were still a lot of things that were kind of early incubation. There was really nothing going into production and certainly not advised by the Spring team to go into production at that stage with it. So, I intentionally left it off just because there was so much other stuff I wanted to cover. I didn't feel like I was missing it that will be different in the next edition.

But that said, I think, in technology we have a hype cycle, right? And I think some of our fellow technologists in other groups, in other projects, in other organizations really have hyped the whole native code thing. And it's very important. I don't want anybody to mistake what I'm saying that it's important, but like every technology, what we as developers and technologists in general, not just developers, tend to do is find out about a new tool and you've heard the expression, "To the man with the hammer, everything looks like a nail." Well, that's not just men. I have a hammer everything looks like a nail.

So, that's both bad and good, right? We get a new tool and we want to hammer everything if we think it's a hammer, right? So everything looks like a nail and we hammer it. And some stuff we find new uses for that are really great. And that's wonderful, you know because we're trying different things. Some things we just start banging on screws and banging on, you know, nuts and bolts and banging on like, I don't know, pipes and breaking them. So, the same thing goes with native compilation.

I don't see a time where it will ever replace every JVM-based workload because the JVM does some things exceedingly well. I mean, JVM-based Java applications in some ways can outperform native code. In some ways, they can't. Then you have things like throughput and adaptability and a lot of things like platform adaptability. So, there are going to be use cases that fit beautifully for native code and not as beautifully in other ways.

I think the early on in the hype cycle, like all things it's native code everywhere. It's not realistic, whatever the percentage is, whether 10% of all job applications will run natively. And the next three years, five years, whatever, or 90%, there will be some percentage probably somewhere in between, Right? So it's a very important part of the story, but it's part of the story. Now, it's coming into Spring Boot 3, Spring Framework 6.

You're looking at that becoming an increasingly important part of the story, but between you and me, do you see every workload going native? Probably not. You know, some number. So, that'll be in there, but coming back to the current edition, those things are still vitally important. You have the ability to deploy what's typically called an executable jar. Then you have the ability to play a fully executable jar. Which is a little bit of a misnomer. It embeds a script that you can run on a Linux machine for instance where you don't have to do a Java desk jar, you just run the jar and that works.

There's a great piece in the appendix. I think it's appendix A, or maybe one of the other appendices in the Spring Boot documentation that explains that fully, which is fascinating reading. If folks haven't read that, please, go do that. Seriously, I'm not making this up. It is fascinating reading. And it's a quick read too, so win-win. But you've got container-based applications. You have the ability to create using cloud-native build packs to bundle things up and create them as a container, as an image I should say.

Which takes any bit of pain that might have been there out of the mix and gives you a lot of the power to, again, deploy anywhere with Spring native capabilities baked in now. You have the ability to generate native images in containers, which, double your pleasure, and double your fun. So you have a lot of capabilities that solve all of those various different use cases and still allow you to use all the best of Spring. It's just getting better with every release, every, update. Anyway, I covered all the stuff except for the Spring native stuff in the addition of the book because that was early and rather dynamic and rather fluid. But that it's starting to come into its own too. 

Recommended talk: Kotlin - Ready for Production • Hadi Hariri • GOTO 2017

Thomas Vitale: But now with the new version of Spring framework 6 and Spring Boot 3, we also get it out of the box, like as part of the core framework. So you got a benefit from all those improvements even when working with JVM application, which is amazing. Without changing anything, just by upgrading to the new version, and then we get all these optimizations and we get faster startup time, even when not working with native images or with reduced memory footprints.

Mark Heckler: See, that's the thing that I think so many times we miss. Because when we talk about native code, it's brilliant when it's running, but it's not so brilliant when you're trying to develop for it, right. So, there's always gonna be that data aspect, even if your intended target is always going for that application is always gonna be native, but it allows you... the Spring team has been super about taking any kind of optimizations that make sense and you benefit from them across the board.

So when they can make something work better with native many times by default makes it work better with your, your JVM-based, I shouldn't say deployments, but packaging. But in many cases, even if it doesn't naturally align, they find ways to make things a win-win, right? So, you benefit either way and you benefit both ways, which is pretty awesome.

Testing in Spring Boot

Thomas Vitale: So we haven't talked about testing, which is also another fascinating subject and very important in our development life cycle. Of course, you cover testing in your book. What are your thoughts on testing and also on the amazing support provided by Spring Boot with the integration test and slice test? We have a lot of help from the framework actually facilitate writing test once again, reducing all the burden on developers to set up the whole framework and infrastructure to run a more sophisticated test.

Mark Heckler: I was talking with another gentleman before and you and I have talked about this to some degree. You'd love to approach a book, an intro book even, the same way you would with a new project, which is test first, right? But it doesn't always make sense to do that because then you lose the topic that you're wanting to cover in the surrounding shroud of testing. So, what I did is a similar thing to what he did, which is you cover testing, but you cover it much later than perhaps you would like, but it makes sense to establish the foundational concepts I think first. It's, again, trade-offs, right? It's an all three, you're going, "This isn't optimal. But, it's more optimal than the option that I could have chosen with the other route.

So testing is critically important, right? One thing that I think Spring does brilliantly is it allows you, as you mentioned, the testing slices, you've got your unit testing, you can do integration testing, you have several different ways and levels layers, I'm trying to think of the best way to say that, of testing your application and applications to make sure that you have suitable outcomes whether that be performance and proper values and etc.

Sometimes you hear folks say, "Well, you know, why would you need slices if you can run through all your tests fast enough that you don't need to do that?" Well, again, it's good to have options. And there are many cases where you want to isolate and test a specific isolated bit of functionality. And I think the slices give you that capability, but let's say you do want to expand the range of them. It doesn't mean you shouldn't focus on making your test as tight as possible. Because if you just wastefully test, and that sounds weird, doesn't it?

But if you don't scope in on the things that you specifically want to test and evaluate, because you can "afford to be wasteful," you may miss things that you want to verify and validate specifically that this works. So it's good to have those options. You can test very specific, tiny bits of functionality to make sure you get the exact response you want. You can test overarching capabilities within an application. You can test interactions between applications and you have all those abilities in Spring Boot and the testing that it supports. So again, I, love how... I start to say we, but, you know, it's the Spring community and the Spring team. I love how we kind of embrace come in where you need to come in and then build out from there. Did that answer your question? Testing is such a huge topic.

Recommended talk: The Art of Unit Testing • Roy Osherove & Dave Farley • GOTO 2021

Thomas Vitale: Yes, it is. Once again, also with testing, we have this convention over configuration and the framework helping us provide these opinions that, of course, we can customize. And the weird thing is that also like through auto configuration and by looking just at how the framework is built, we get inspiration about best practices and ways that we can also use to build our own customizations and perhaps auto-configuration with our libraries in our organizations or extended test capabilities with new slices, depending on the type of applications that we do. I think that's also a great thing that I like about the framework that also extends the framework. You learn so much just by looking at the code, best practices, and how to solve problems in an efficient way, effective way. Yeah.

Mark Heckler: Yes. Can't agree more.

Configuring Spring Boot applications

Thomas Vitale: So another topic perhaps configuration. To wrap it up we can also cover some configuration subjects in your book and the way that we can configure Spring Boot applications. And also, in that case, we get a lot of help to achieve production rate applications that we can configure in different ways depending on the environment.

Mark Heckler: That's one of those topics that seems like such a simple topic, right? I mean, it's basically just properties, right? But it's one of those things that when I start showing people this, it's one of my favorite things to show because it's super simple conceptually, but the extent that the Spring developers spring, Spring Boot family of developers in spring framework and even again, various projects as they incorporate the, I don't want to say the connections, but incorporate the capabilities, you start to realize the level of thought that has gone into this into making Spring Boot production-ready. Because if you have ways to incorporate the environment and by the environment, it can be like a configuration server, a config server via Spring cloud, which can back into GitHub repositories and Git repositories and HashiCorp Vault.

And I just a gazillion different... Gazillion that's a new number, but anyway, a lot of different options from the back end. Then you have just your environment. You can pass things on the command line. You can pull from environment variables. You can have cloud platform variables. I mean, there are so many different things that you can use, application up properties, internal and external to the jar. I mean, so many different ways that you can feed parameters, feed configuration settings into your applications. Is that what you meant or did I just go down a different path?

Thomas Vitale: That's perfect.

Mark Heckler: I use that in one of my debugging Spring Boot applications sessions that I just started working out because again, it's a very simple concept. It's a simple topic, but it's like, how do you isolate where that's coming from? You need to not make assumptions and say, "Well, I think it's coming from here." Well, that's no good. Is it coming from here? Where are you getting that value? Why is that creeping into your application which ironically I use actuator for some as well, because actuator shows you that source of truth in many ways when you have multiple conflicting paths into your application for a particular setting, a value.

And as we mentioned earlier, just having a value defined, just having a property defined can alter your auto-configuration because when Spring Boot's auto-config says, "Oh, you have this property, define your overriding this normal set of opinions that I would apply here. That can make a huge difference. Again, if you're new to Spring Boot, that can be a little disconcerting or jarring as I like to say. Pun intended. But it's an extremely powerful tool that you can use as a developer to work wonders on your behalf. Talk about tying it all together. The configuration settings and the actuator and Spring Boot auto-config, allow you to do some incredible things, very simply.

Thomas Vitale: Yes. So just to sum up the great book that Mark Heckler wrote, "Spring Boot: Up and Running" covers all these different topics that we've been discussing today, but even more like, for example, we haven't talked about web applications and rest APIs that's covered too. And reactive is covered also with a lot of different subjects. Our, server, for example, is not just based on interaction. We haven't talked about that, there are so many interesting topics.

So if you're starting with Spring Boot or you're already working with Spring Boot, I still recommend reading the book because there are very useful insights and yeah, important features and points that you might not know about the framework and the features of Spring Boot. So "Spring Boot: Up and Running." And I guess where can people find you, Mark, online? Twitter? And...

Mark Heckler: The best way to reach me is like the best way to reach you, and is Twitter, right? I mean, email is out there, of course, mark@thehecklers.com is my primary email, but that's the email that I checked the least infrequently, I always say. And my corporate email address, same thing. I check it from time to time, but literally, Twitter is the fastest way to reach me. So mkheck, Mike, kilo, hotel, echo, Charlie, kilo. It's just mkheck on Twitter. So reach out to me there.

If you just find me there and follow me and you can send me a DM immediately, even if I haven't even seen your initial follow, I'll get it. My DMs are open. So I encourage questions, comments, feedback, and just wide-ranging chats publicly. Or if you have stuff you wanna talk about privately, don't wanna share it with the world, send me a DM and it's all good, but yeah, Twitter's the place to hang, right? I mean, for better and for worse, it's just a...

Thomas Vitale: It's a good place.

Mark Heckler: Yeah. Yeah. It's like the coffee shop online, right? Except you have to bring your own coffee.

Thomas Vitale: It is where we met.

Mark Heckler: Yes, that's true. 

Thomas Vitale: And we haven't talked about coffee. Too bad.

Mark Heckler: We need more time. Always more time.

Thomas Vitale: Yes. So if you love coffee, also follow Mark so you can chat about him.

Mark Heckler: Absolutely. Coffee is where it is. I mean, it's what powers everything else. So, Thomas, thank you so much.

Thomas Vitale: Thank you very much for being here today. You can find the book everywhere, online, paper. And follow Mark Heckler on Twitter and thanks for being with us today. So see you next time.

Mark Heckler: Thanks so much.

Thomas Vitale: Have a great day.

Mark Heckler: Thomas, awesome to chat with you again, and looking forward to the next time already.

Thomas Vitale: Likewise. Yes, let's do that again.

Mark Heckler: Please.

Thomas Vitale: See you.