WEBVTT 1 00:00:00.120 --> 00:00:02.560 Welcome to the deep dive, where we try to sift 2 00:00:02.560 --> 00:00:05.839 through all that information overload to bring you the insights 3 00:00:05.839 --> 00:00:07.480 you actually need fast. Yeah. 4 00:00:07.519 --> 00:00:09.640 There's so much out there, exactly. 5 00:00:09.439 --> 00:00:12.320 And today we're tackling a challenge that well, it plagues 6 00:00:12.359 --> 00:00:15.240 nearly everyone in software development, especially I think in the 7 00:00:15.320 --> 00:00:18.000 Java world. How do you keep up with all the 8 00:00:18.079 --> 00:00:22.839 constant change and build really high quality applications without just 9 00:00:22.879 --> 00:00:27.440 getting bogged down in endless configuration and boilerplates. 10 00:00:27.440 --> 00:00:30.399 Oh yeah, it feels like a constant battle sometimes. 11 00:00:30.399 --> 00:00:31.519 It really does, doesn't it. 12 00:00:31.519 --> 00:00:35.560 It absolutely does, And that's precisely why our deep dive 13 00:00:35.640 --> 00:00:39.200 today into hacking with Springboot two point four classic addition 14 00:00:39.600 --> 00:00:43.119 feels so relevant. Okay, spring Boot has I mean undeniably 15 00:00:43.159 --> 00:00:46.479 become a cornerstone of modern Java development for sure, and 16 00:00:46.719 --> 00:00:49.439 our mission here really is to extract the core insights 17 00:00:49.439 --> 00:00:51.679 from these sources to reveal how it acts as this 18 00:00:51.799 --> 00:00:54.759 powerful shortcut not just for productivity, but maybe for a 19 00:00:54.759 --> 00:00:58.240 deeper understanding of building truly robust, maintainable apps. 20 00:00:58.479 --> 00:01:00.759 Okay, so let's unpack this then. What is spring boot 21 00:01:00.840 --> 00:01:04.799 at its heart? The sources seem to frame it as 22 00:01:06.560 --> 00:01:09.400 powerful but also surprisingly simple. 23 00:01:09.599 --> 00:01:10.879 Yeah, that's a good way to put. 24 00:01:10.760 --> 00:01:16.680 It, defined by four key characteristics. It's fast, opinionated, portable, 25 00:01:17.079 --> 00:01:20.439 and production ready. The sound like pretty strong claims for 26 00:01:20.959 --> 00:01:23.120 streamlining the entire application life cycle. 27 00:01:23.200 --> 00:01:27.159 They are strong claims, and each word holds significant weight. 28 00:01:27.319 --> 00:01:29.439 When we say opinionated, what we're really talking about is 29 00:01:29.439 --> 00:01:33.599 spring Boot's genius for making smart, sensible assumptions. It looks 30 00:01:33.599 --> 00:01:36.439 at the libraries you've added. Say you add spring Web 31 00:01:36.560 --> 00:01:40.040 or a database connector, right, and it automatically configures a 32 00:01:40.079 --> 00:01:42.000 lot of the common settings for you. It's almost like 33 00:01:42.000 --> 00:01:44.680 having a seasoned expert looking over your shoulder saying, okay, 34 00:01:44.920 --> 00:01:47.640 given these tools here are probably the best of faults. 35 00:01:47.760 --> 00:01:50.439 Oh okay, So it makes educated guesses. 36 00:01:50.159 --> 00:01:54.719 For you precisely. And the beauty is these defaults dramatically 37 00:01:54.799 --> 00:01:57.719 cut down on configure But and this is key, you 38 00:01:57.719 --> 00:02:01.079 can always easily override them if you're project need something specific. 39 00:02:01.480 --> 00:02:04.040 This magic, as people call it, is driven by things 40 00:02:04.079 --> 00:02:08.080 like autoconfiguration and component scanning. They just, you know, effortlessly 41 00:02:08.159 --> 00:02:12.360 wire up your applications parts. Plus, it bundles embedded surflet 42 00:02:12.400 --> 00:02:15.520 containers like a patche Tomcat directly into your application. 43 00:02:15.719 --> 00:02:18.520 Right, So no more wrestling with server installations just to 44 00:02:18.560 --> 00:02:21.319 get a basic Hello World running exactly. 45 00:02:21.360 --> 00:02:25.000 It eliminates that entire headache, especially when you're just starting out. 46 00:02:24.919 --> 00:02:27.360 So it's not just about speed in writing the code, 47 00:02:27.360 --> 00:02:29.919 but speed to that first run. I remember the old 48 00:02:30.000 --> 00:02:33.919 days spending hours just getting a server set up. 49 00:02:34.080 --> 00:02:38.360 Hours. Yeah, And the perfect starting line for this nowadays 50 00:02:38.639 --> 00:02:43.000 is the Spring initializer. You know, start dot spring dot io. 51 00:02:43.039 --> 00:02:44.080 Oh yeah, I've used that. 52 00:02:44.120 --> 00:02:46.520 It's great, It is great. This web tool just quickly 53 00:02:46.560 --> 00:02:49.479 generates a project tailored to what you need. You pick 54 00:02:49.560 --> 00:02:52.759 your essential dependencies like spring web for web apps, time 55 00:02:52.840 --> 00:02:56.039 leaf maybe for templates, Spring boot test, which is crucial, 56 00:02:56.280 --> 00:02:59.719 absolutely crucial. The source material even highlights how it unconditionally 57 00:02:59.759 --> 00:03:04.000 inc includes spring boot starter test. It really underlines how 58 00:03:04.120 --> 00:03:05.439 vital testing is today. 59 00:03:05.680 --> 00:03:08.879 So you get a well structured, testable project right out 60 00:03:08.879 --> 00:03:10.120 of the gate in seconds. 61 00:03:10.159 --> 00:03:11.919 In seconds, it's a significant head start. 62 00:03:12.039 --> 00:03:15.439 Okay, so you've got this project generated, ready to go. 63 00:03:16.039 --> 00:03:20.599 What's the next step to actually turn it into something deployable. 64 00:03:20.800 --> 00:03:24.000 That's where the spring boot Maven plug game comes into play. 65 00:03:24.120 --> 00:03:27.520 It takes to your application all as dependencies everything okay, 66 00:03:27.560 --> 00:03:32.199 and packages them into a single self contained executable JR file. 67 00:03:32.639 --> 00:03:33.680 People often call it an. 68 00:03:33.680 --> 00:03:35.919 Uber JR right, the fat jar. 69 00:03:35.759 --> 00:03:38.919 Exactly, the fat jar, and this file is incredibly portable. 70 00:03:38.960 --> 00:03:41.080 You can run it anywhere a JDK is present with 71 00:03:41.240 --> 00:03:44.840 just a simple Java jar command. It really simplifies distribution. 72 00:03:45.719 --> 00:03:48.639 Someone I think it was Josh Long once said working 73 00:03:48.680 --> 00:03:51.400 with spring boot is like pair programming with the Spring developers. 74 00:03:51.680 --> 00:03:53.520 That's a perfect analogy, and I. 75 00:03:53.479 --> 00:03:59.680 Think that beautifully captures this feeling of well, almost effortless productivity. So, okay, 76 00:03:59.759 --> 00:04:03.159 we've establish that foundational magic. How does it translate into 77 00:04:03.400 --> 00:04:07.280 like faster, more effective daily work for developers, especially when 78 00:04:07.319 --> 00:04:09.840 we move beyond just the initial setup right. 79 00:04:09.719 --> 00:04:11.800 Because setup is one thing, but the day to day 80 00:04:11.800 --> 00:04:13.919 coding is where you spend most of your time. 81 00:04:13.919 --> 00:04:16.839 Exactly with the project up and running fast, the next 82 00:04:16.839 --> 00:04:19.959 big thing is usually the database. I mean, let's face it, 83 00:04:20.040 --> 00:04:21.720 almost no application lives about. 84 00:04:21.519 --> 00:04:22.519 Data, pretty much none. 85 00:04:22.600 --> 00:04:28.360 Yeah, So how does springboot take its philosophy of speed 86 00:04:28.720 --> 00:04:32.800 and dare I say fun into the often complex world 87 00:04:32.800 --> 00:04:33.720 of data management. 88 00:04:33.800 --> 00:04:37.480 It does this really elegantly through Spring Data JPA. Okay, 89 00:04:37.680 --> 00:04:42.199 this framework significantly cuts down the boilerplate code you need 90 00:04:42.279 --> 00:04:46.079 for data access. Instead of writing endless SQL or you 91 00:04:46.079 --> 00:04:51.120 know JPQL queries. You define simple interfaces, we call them repositories. 92 00:04:51.319 --> 00:04:54.199 And here's where the real power comes in, query derivation. 93 00:04:54.319 --> 00:04:55.680 Query derivation explain that? 94 00:04:55.879 --> 00:04:58.240 Okay? So you can just declare a method name in 95 00:04:58.279 --> 00:05:01.920 your repository interface like find by name containing string partial name, 96 00:05:02.319 --> 00:05:04.680 and spring Data looks at the method name, parses it, 97 00:05:04.720 --> 00:05:07.519 and automatically figures out and constructs the correct SQL query 98 00:05:07.560 --> 00:05:10.040 for you. You don't write the query code, You just describe 99 00:05:10.040 --> 00:05:11.759 what you want to find by naming the method. 100 00:05:12.000 --> 00:05:17.759 Wow. So less time writing repetitive sequel, more time focusing 101 00:05:17.839 --> 00:05:21.199 on the actual application logic. That sounds like a huge 102 00:05:21.199 --> 00:05:22.480 win for developer flow. 103 00:05:22.600 --> 00:05:26.120 It absolutely is, And for more complex stuff like dynamic 104 00:05:26.199 --> 00:05:30.439 search scenarios, spring Data offers something called query by example. 105 00:05:30.800 --> 00:05:31.720 Okay, how does that work? 106 00:05:32.120 --> 00:05:36.120 Well? Instead of creating like a million custom finder methods 107 00:05:36.240 --> 00:05:39.319 or those awful switch statement nightmares in your service layer 108 00:05:39.399 --> 00:05:41.839 to handle every possible search combo. 109 00:05:42.000 --> 00:05:43.240 Yeah, I've seen those right. 110 00:05:43.279 --> 00:05:46.120 Instead, you just assemble a simple probe object with the 111 00:05:46.120 --> 00:05:48.720 criteria you want to search on. You pass that probe 112 00:05:48.720 --> 00:05:52.120 to spring data, and it intelligently constructs the query based 113 00:05:52.120 --> 00:05:53.959 on the fields you set in the probe. 114 00:05:54.040 --> 00:05:55.000 That sounds much cleaner. 115 00:05:55.040 --> 00:05:57.839 It's incredibly clean, and it relates directly to something Greg 116 00:05:57.879 --> 00:06:01.680 Elternquis said, which our sources is highlight code you don't 117 00:06:01.680 --> 00:06:02.879 write has no bugs. 118 00:06:03.160 --> 00:06:04.680 H that's a good one and true. 119 00:06:04.800 --> 00:06:08.319 It's not just clever, it's fundamental. It directly reduces the 120 00:06:08.399 --> 00:06:11.800 places where errors can creep in less code, fewer bugs. 121 00:06:11.480 --> 00:06:14.800 A powerful principle. Now you know the old developer cycle 122 00:06:15.000 --> 00:06:19.240 code compile, waight, test, debug, repeat. Oh the waiting, those 123 00:06:19.279 --> 00:06:22.759 constant stop and start cycles, that mental tax of context switching. 124 00:06:23.120 --> 00:06:27.120 It can really drain your creativity. Yeah, how does springboot 125 00:06:27.160 --> 00:06:29.959 step in to maybe re engineer that daily rhythm make 126 00:06:30.000 --> 00:06:30.959 it less of a chore. 127 00:06:31.480 --> 00:06:35.199 This is where springboot deap pools is pretty indispensable. It's 128 00:06:35.199 --> 00:06:39.399 a specific module designed explicitly to slash those development loop times. 129 00:06:39.600 --> 00:06:41.680 Okay, dev tools, how does it work? Its magic? 130 00:06:42.040 --> 00:06:45.959 The secret is this really intelligent reloading mechanism. When you 131 00:06:46.040 --> 00:06:49.839 change your application code a Java class, for example, dev 132 00:06:49.879 --> 00:06:54.000 tools doesn't do a full application restart. Instead, it very 133 00:06:54.040 --> 00:06:57.920 precisely reloads only your modified classes, leaving the core framework 134 00:06:57.959 --> 00:07:02.199 and libraries running. It uses separate classloaders to achieve this, So. 135 00:07:02.160 --> 00:07:03.759 It's much faster than a full. 136 00:07:03.560 --> 00:07:07.519 Restart, massively faster. We're talking near instant feedback, sometimes cutting 137 00:07:07.560 --> 00:07:09.839 out those really frustrating weights we all remember. 138 00:07:10.040 --> 00:07:12.879 So not a full server reboot every time I hit save. 139 00:07:13.120 --> 00:07:15.639 That's a huge difference from the old days. I remember 140 00:07:15.680 --> 00:07:18.920 how much time we'd lose just waiting. What's the biggest 141 00:07:18.920 --> 00:07:20.240 gain you see teams get from this? 142 00:07:20.560 --> 00:07:26.000 Honestly, it's reclaiming cognitive energy, that constant interruption, that mental 143 00:07:26.040 --> 00:07:28.439 context switch. Every time you wait for a restart, it 144 00:07:28.519 --> 00:07:31.399 just vanishes. Developers stay in the flow. They can iterate 145 00:07:31.439 --> 00:07:34.519 on ideas much more rapidly. Makes sense, and def tools 146 00:07:34.560 --> 00:07:38.639 also provides helpful property defaults just for development. Like it 147 00:07:38.720 --> 00:07:43.160 automatically disables template cashing, spring dot timeleaf dot cash false 148 00:07:43.199 --> 00:07:43.720 is set for you. 149 00:07:43.879 --> 00:07:47.319 Oh nice, so you're not fighting stale cases during dev exactly. 150 00:07:47.360 --> 00:07:49.879 You don't have to manually tweak settings for your dev 151 00:07:49.959 --> 00:07:53.399 environment versus production. It just handles common sense to faults. Plus, 152 00:07:53.439 --> 00:07:56.199 it throws in things like liver load support for automatic 153 00:07:56.240 --> 00:07:59.480 browser refreshing handy, and it can activate increased web level 154 00:07:59.480 --> 00:08:03.759 logging for easier debugging with just a simple property logging 155 00:08:03.800 --> 00:08:06.959 dot level, dot webdbug. It basically automates away all those 156 00:08:06.959 --> 00:08:08.879 little frictions that add up and slow you down. 157 00:08:09.399 --> 00:08:12.759 Okay, so we've covered making development and iteration faster, even 158 00:08:12.759 --> 00:08:15.800 more enjoyable. But the ultimate goal, right is getting your 159 00:08:15.839 --> 00:08:20.439 application out there into production. How does Springboot help turn 160 00:08:20.560 --> 00:08:23.959 getting to production from maybe a frantic scramble to a 161 00:08:23.959 --> 00:08:25.040 more confident process. 162 00:08:25.360 --> 00:08:28.879 It aims to make deployment remarkably smooth. We already touched 163 00:08:28.920 --> 00:08:30.480 on those uber jars. 164 00:08:30.279 --> 00:08:31.759 Right, the self contained executables. 165 00:08:31.839 --> 00:08:36.000 Yeah, they give you incredible portability, just Javajar and your running. Yeah, 166 00:08:36.039 --> 00:08:40.159 but today containers are often the standard, right Docker everywhere? 167 00:08:40.519 --> 00:08:43.679 M definitely. So what's the spring boot story for Docker? 168 00:08:44.039 --> 00:08:47.840 It's got fantastic Docker integration. Now you can use traditional 169 00:08:47.919 --> 00:08:51.799 layer Docker files, and spring helps you optimize those layers 170 00:08:51.840 --> 00:08:56.039 for better caching of dependencies. Okay, but for an even simpler, 171 00:08:56.159 --> 00:09:00.879 almost zero Docker file approach, Springboot provides directly integration with 172 00:09:01.000 --> 00:09:02.080 Piquito build packs. 173 00:09:02.120 --> 00:09:03.799 Build packs what are those exactly? 174 00:09:03.840 --> 00:09:06.919 They're like smart systems that know how to build container 175 00:09:07.000 --> 00:09:10.320 images for specific types of applications like Java apps, without 176 00:09:10.320 --> 00:09:13.000 you needing to write a Docker file. Spring Boot integrates 177 00:09:13.039 --> 00:09:16.759 this via the springboot dot build image maven or gradal command. 178 00:09:16.519 --> 00:09:18.440 So one command and it builds the container. 179 00:09:18.679 --> 00:09:22.360 Pretty much, This single command builds a production ready container 180 00:09:22.399 --> 00:09:26.559 image for you. It automatically follows best practices, applies optimal 181 00:09:26.639 --> 00:09:30.440 layering for Docker caching, handle security patching. It removes the 182 00:09:30.480 --> 00:09:33.200 need to manually write and maintain Docker files. 183 00:09:33.240 --> 00:09:36.279 Wow, eliminating the Docker file That sounds like a big 184 00:09:36.320 --> 00:09:39.519 weight off of developers shoulders, especially for consistency. How does 185 00:09:39.519 --> 00:09:42.039 that help bigger teams or CICD pipelines. 186 00:09:42.200 --> 00:09:46.080 Yeah, for larger teams in CICD, it standardizes the build process, 187 00:09:46.120 --> 00:09:50.440 completely reduces errors, ensures everyone builds containers the same optimal way, 188 00:09:51.039 --> 00:09:54.360 and it also positions you well for future tech like grill. 189 00:09:54.200 --> 00:09:57.279 Vm ah native images. That's been getting a lot of buzz. 190 00:09:57.120 --> 00:10:01.200 Right the grell vm integration usually via Spring Native, which 191 00:10:01.240 --> 00:10:04.399 is well, it's been experimental, but maturing fast is a 192 00:10:04.399 --> 00:10:07.919 potential game changer. It compiles your spring boot app ahead 193 00:10:07.919 --> 00:10:10.759 of time into a native executable and the benefit is 194 00:10:11.000 --> 00:10:14.600 radically reduced startup time and a much smaller memory footprint. 195 00:10:14.799 --> 00:10:17.519 Our source material actually mentions an impressive startup time of 196 00:10:17.600 --> 00:10:20.720 like zero point two two six seconds for a Grail 197 00:10:20.840 --> 00:10:21.840 VM native image. 198 00:10:21.840 --> 00:10:24.440 Who under a quarter of a second blink of an eye. 199 00:10:25.080 --> 00:10:28.840 This is transformative for things like serverlest functions or micro 200 00:10:28.919 --> 00:10:31.799 services that need to scale up super fast, or just 201 00:10:32.000 --> 00:10:34.000 running in resource constrained environments. 202 00:10:34.039 --> 00:10:36.480 Yeah yeah, that kind of speed changes the economics of 203 00:10:36.480 --> 00:10:41.519 how you deploy and scale things. Okay, so application is built, containerized, 204 00:10:41.919 --> 00:10:47.240 maybe even native, it's deployed. What about day two keeping 205 00:10:47.240 --> 00:10:49.480 an eye on it troubleshooting? This is where spring boot 206 00:10:49.519 --> 00:10:51.360 Actuator comes in right precisely. 207 00:10:51.639 --> 00:10:55.000 Actuator is basically a suite of production ready features built 208 00:10:55.039 --> 00:10:58.279 right in from monitoring and managing your running application. It 209 00:10:58.360 --> 00:11:02.240 exposes several helpful and point over HTTP or JMX. 210 00:11:02.440 --> 00:11:03.440 Like what kind of endpoints? 211 00:11:03.480 --> 00:11:05.519 Well, the classic one is Actuator Health. It gives you 212 00:11:05.559 --> 00:11:08.879 an immediate status up or DWN simple. 213 00:11:08.559 --> 00:11:10.120 But essential get basic health check. 214 00:11:10.279 --> 00:11:13.639 But it gets smarter with a simple property setting like management, 215 00:11:13.679 --> 00:11:17.080 dot endpoint, dot health, dot show details always. It automatically 216 00:11:17.159 --> 00:11:19.919 includes diagnostic details from components it knows about, like your 217 00:11:19.960 --> 00:11:22.399 database connection status, disk space usage. 218 00:11:22.480 --> 00:11:25.039 Wait, so it knows about my database connection and disk 219 00:11:25.080 --> 00:11:28.519 space automatically without me coding custom checks. 220 00:11:28.480 --> 00:11:32.600 Yes, through that clever auto configuration. Again, it detects those 221 00:11:32.600 --> 00:11:37.120 components and includes relevant health indicators. This gives your ops 222 00:11:37.240 --> 00:11:40.960 team rich real time insights without you writing extra code. 223 00:11:41.399 --> 00:11:43.200 That is smart. What else, then. 224 00:11:43.120 --> 00:11:46.080 There's actuator info. You can use this to embed critical 225 00:11:46.080 --> 00:11:49.559 application details the exact build version, maybe the Java version 226 00:11:49.559 --> 00:11:52.360 it's running on, even the get commit id it was 227 00:11:52.360 --> 00:11:52.879 built from. 228 00:11:53.080 --> 00:11:56.399 Well, that's useful for debugging issues reported by users. 229 00:11:56.559 --> 00:12:00.000 Invaluable. Imagine a support call they can instantly check out 230 00:12:00.000 --> 00:12:01.919 actuator info and see if the user is running an 231 00:12:01.960 --> 00:12:04.480 old build No guesswork, But maybe one of the most 232 00:12:04.480 --> 00:12:06.799 powerful is actuator loggers bloggers. 233 00:12:06.840 --> 00:12:07.440 What does that do? 234 00:12:07.799 --> 00:12:11.519 This endpoint lets you dynamically view and change logging levels at. 235 00:12:11.519 --> 00:12:13.600 Runtime, change them while it's running. 236 00:12:13.720 --> 00:12:18.440 Yes, imagine a tricky production issue. You can temporarily dial 237 00:12:18.519 --> 00:12:21.440 up the logging for a specific Java package to say 238 00:12:21.879 --> 00:12:24.720 debug or even trace level. Watch the logs to see 239 00:12:24.720 --> 00:12:27.679 exactly what's happening, capture the information you need, and then 240 00:12:27.720 --> 00:12:30.879 dial it back down to ANFO or warn all without 241 00:12:30.960 --> 00:12:33.360 restarting the application or deploying new code. 242 00:12:33.559 --> 00:12:37.639 Wow. That ability to change logging on the fly in production, 243 00:12:38.200 --> 00:12:41.720 no restart That sounds like an absolute life saver for 244 00:12:41.840 --> 00:12:43.279 hunting down elusive bugs. 245 00:12:43.440 --> 00:12:46.840 It really really is. It's incredibly potent for live system debugging. 246 00:12:47.200 --> 00:12:49.679 And there are others too, like Actuator thread dump for 247 00:12:49.799 --> 00:12:51.440 analyzing thread states. 248 00:12:51.200 --> 00:12:53.440 Useful for deadlocks or performance issues exactly. 249 00:12:53.799 --> 00:12:57.080 Actuator heap dump generates a memory snapshot file and each 250 00:12:57.120 --> 00:13:00.440 prof file for deep memory analysis. If you suspect leaks, 251 00:13:00.960 --> 00:13:05.159 an Actuator TTP trace can track recent HTTP request response pairs, 252 00:13:05.519 --> 00:13:08.399 though you need to configure an in memory HTTP trace 253 00:13:08.440 --> 00:13:10.960 repository being for that one. It's a whole toolkit. 254 00:13:11.080 --> 00:13:15.480 It sounds like an incredibly powerful diagnostic toolkit. But with 255 00:13:15.559 --> 00:13:19.960 all that information potentially exposed, security must be a huge concern, right. 256 00:13:20.000 --> 00:13:21.720 You can't just leave all those endpoints open. 257 00:13:21.840 --> 00:13:24.879 That is an extremely important point. You absolutely must be careful. 258 00:13:24.960 --> 00:13:27.879 By default, only a few safe end points like health 259 00:13:27.879 --> 00:13:30.039 and info might be exposed over the web. You have 260 00:13:30.120 --> 00:13:33.320 to explicitly configure which other endpoints you want to expose 261 00:13:33.440 --> 00:13:36.279 using the management Dot endpoints dot web dot exposure dot 262 00:13:36.279 --> 00:13:37.039 include property. 263 00:13:37.159 --> 00:13:39.120 Okay, so it's opt in for the sensitive ones. 264 00:13:39.440 --> 00:13:42.000 Yes, and you should never just use to expose everything. 265 00:13:42.039 --> 00:13:44.639 That's a major security risk. You pick only what you need. 266 00:13:44.919 --> 00:13:49.600 Springboot provides robust security integration, usually with Spring Security, and 267 00:13:49.679 --> 00:13:52.840 you absolutely must use it to protect these endpoints properly 268 00:13:53.000 --> 00:13:53.440 makes sense. 269 00:13:53.559 --> 00:13:57.080 Secure by default explicit exposure, right, and you. 270 00:13:57.000 --> 00:14:00.159 Can also customize the base path, maybe change actuators to 271 00:14:00.200 --> 00:14:03.960 manage or something less guessable, just as another small layer. 272 00:14:04.120 --> 00:14:06.879 Good tip. Yeah, okay, So what's really fascinating here is 273 00:14:06.919 --> 00:14:09.759 how spring Boot helps build not just the app's core, 274 00:14:09.840 --> 00:14:13.799 but also its interfaces. Let's talk APIs. They're how our 275 00:14:13.799 --> 00:14:15.720 apps talk to the world or even to each other. 276 00:14:15.799 --> 00:14:19.679 Absolutely, and building simple Jason Web services with springboot is 277 00:14:19.759 --> 00:14:23.720 incredibly fluid. You use annotations like at rest controller, which 278 00:14:23.759 --> 00:14:25.840 tells Spring that the return value of your method should 279 00:14:25.840 --> 00:14:28.759 be automatically serialized, usually to Jason and written into the 280 00:14:28.799 --> 00:14:31.480 response body. And if you need more control, you can 281 00:14:31.559 --> 00:14:35.120 use response entity to set specific HTTP status codes like 282 00:14:35.159 --> 00:14:37.159 to a one created when you make a new resource 283 00:14:37.240 --> 00:14:37.759 or headers. 284 00:14:37.919 --> 00:14:40.879 Pretty straightforward for basic zero at APIs. 285 00:14:40.840 --> 00:14:44.480 Very but the real critical challenge for any API isn't 286 00:14:44.519 --> 00:14:48.399 just building version one point zero, it's managing API evolution. 287 00:14:48.720 --> 00:14:52.440 Ah, yes, how do you change things later without breaking 288 00:14:52.480 --> 00:14:56.559 everyone who's already using your API? That can cause chaos. 289 00:14:56.320 --> 00:15:02.480 Exactly, broken clients, widespread outages, costly refactoring efforts. It's a 290 00:15:02.559 --> 00:15:05.600 huge problem for long lived APIs. This brings to mind 291 00:15:05.679 --> 00:15:09.240 some interesting research by Jean Jacques dubray on the costs 292 00:15:09.240 --> 00:15:10.000 of versioning. 293 00:15:10.200 --> 00:15:11.559 Okay, what did that study find? 294 00:15:11.720 --> 00:15:15.799 Well, Dubrae identified basically three common patterns for API evolution. 295 00:15:16.039 --> 00:15:19.200 There's the knot where everyone is tied to one version, 296 00:15:19.360 --> 00:15:22.399 making any change super risky because it affects everyone I spakes. 297 00:15:22.799 --> 00:15:25.600 Then there's point to point where you maintain multiple versions 298 00:15:25.600 --> 00:15:29.399 of the API simultaneously. Think V one, v two, v three. Right, 299 00:15:29.440 --> 00:15:31.480 you see that a lot you do, but it drastically 300 00:15:31.559 --> 00:15:33.960 increases the maintenance burden on the server side. Yeah, you're 301 00:15:33.960 --> 00:15:37.519 supporting multiple code paths. The ideal, according to the study 302 00:15:37.600 --> 00:15:40.840 showing the lowest cost increase over time, is compatible versioning. 303 00:15:40.919 --> 00:15:43.519 Compatible version yeah, where you evolve the API on the 304 00:15:43.559 --> 00:15:46.279 same endpoint, adding new features or data, but in a 305 00:15:46.279 --> 00:15:49.360 way that doesn't break existing clients. They just ignore what 306 00:15:49.399 --> 00:15:52.039 they don't understand. This is really the gold standard for 307 00:15:52.080 --> 00:15:54.039 long term API health and sustainability. 308 00:15:54.159 --> 00:15:57.960 Okay, that makes sense. So if compatible versioning is the goal, 309 00:15:58.840 --> 00:16:02.799 how does spring boot help achieve that elusive backward compatible 310 00:16:02.840 --> 00:16:04.879 API you mentioned hypermedia earlier. 311 00:16:05.000 --> 00:16:08.960 Hypermedia is the absolute key think about why the World 312 00:16:08.960 --> 00:16:11.879 Wide Web itself is so successful and resilient. It didn't 313 00:16:11.919 --> 00:16:15.799 just give us static documents. It wetted data with navigational links. 314 00:16:16.120 --> 00:16:18.320 Click a link, go somewhere else, do something else. 315 00:16:18.399 --> 00:16:18.679 Okay. 316 00:16:19.000 --> 00:16:24.000 Spring heshat eoas hypermedia as the Engine of Application State 317 00:16:24.360 --> 00:16:27.240 is a project in the Spring ecosystem specifically for this. 318 00:16:27.840 --> 00:16:31.320 It gives you tools like entity model, collection model and link. 319 00:16:31.159 --> 00:16:32.600 Objects And what do these do? 320 00:16:32.840 --> 00:16:36.799 They let you infuse your API responses with these affordances, 321 00:16:36.840 --> 00:16:40.080 basically links that tell the client what actions are possible 322 00:16:40.159 --> 00:16:42.159 next based on the current state of the resource. 323 00:16:42.440 --> 00:16:44.320 So instead of the client guessing. 324 00:16:44.360 --> 00:16:47.320 Exactly, instead of the client having hardcoded logic like if 325 00:16:47.360 --> 00:16:50.480 the order status is pending, then show the cancel order button. 326 00:16:51.080 --> 00:16:54.240 The API response for that penning order would actually include 327 00:16:54.279 --> 00:16:57.240 a link with a relation type maybe will cancel. The 328 00:16:57.279 --> 00:17:00.240 client just looks for that specific link relation. If the 329 00:17:00.240 --> 00:17:03.360 cancel link is present in the response, it shows the button. 330 00:17:03.799 --> 00:17:06.240 If the order is shipped and the ATI doesn't include 331 00:17:06.240 --> 00:17:08.440 that link anymore, the button disappears. 332 00:17:08.640 --> 00:17:11.519 Ah, So the API tells the client what actions are 333 00:17:11.519 --> 00:17:14.000 currently valid. The client doesn't need to know the business 334 00:17:14.079 --> 00:17:14.920 rules behind. 335 00:17:14.680 --> 00:17:18.240 It precisely, it shifts the burden. The client moves from 336 00:17:18.319 --> 00:17:22.559 needing deep domain knowledge understanding the intricate business rules to 337 00:17:22.640 --> 00:17:26.680 needing only protocol knowledge understanding how to find and follow links. 338 00:17:27.160 --> 00:17:30.599 This fundamentally decouples the client and server. The server can 339 00:17:30.680 --> 00:17:34.119 now evolve its business logic and workflows, adding or removing 340 00:17:34.160 --> 00:17:37.079 available actions by just changing the links it sends back. 341 00:17:37.440 --> 00:17:39.039 The client adapts automatically. 342 00:17:39.279 --> 00:17:42.559 That sounds like a profound shift in API design. Less 343 00:17:42.559 --> 00:17:43.839 brittle clients. 344 00:17:43.720 --> 00:17:46.799 Much less brittle. And this approach also works really well 345 00:17:46.839 --> 00:17:52.240 with metadata formats like ALPS Application Level Profile Semantics. ALPS 346 00:17:52.319 --> 00:17:55.200 acts like a machine readable blueprint describing the meaning of 347 00:17:55.240 --> 00:17:58.759 your links and response structures. This is what true rest 348 00:17:58.839 --> 00:18:00.960 is really about, by the way, far more than just 349 00:18:01.240 --> 00:18:05.400 pretty urris or using JSON. It's about these hypermedia controls. 350 00:18:05.559 --> 00:18:09.240 Okay, this is powerful stuff, but also raises a big question. 351 00:18:09.680 --> 00:18:14.799 How do you document these kinds of dynamic evolvable APIs effectively? Yeah? 352 00:18:14.839 --> 00:18:18.920 And crucially, how do you stop that documentation from becoming 353 00:18:19.000 --> 00:18:22.640 instantly outdated? Which is, let's be honest, a chronic problem. 354 00:18:22.759 --> 00:18:26.319 Yes, stale documentation is the worst. That's where another Spring project, 355 00:18:26.400 --> 00:18:29.240 spring rest stocks comes in and is frankly brilliant. 356 00:18:29.279 --> 00:18:30.799 Okay, rest doos what's the approach? 357 00:18:30.920 --> 00:18:33.960 It takes a completely test driven approach. Instead of writing 358 00:18:34.000 --> 00:18:37.880 documentation manually separate from your code, which yeah, always gets 359 00:18:37.880 --> 00:18:40.960 out of sync always, Instead, your existing integration tests or 360 00:18:40.960 --> 00:18:45.160 controller tests automatically generate documentation snippets. Snippets like things like 361 00:18:45.200 --> 00:18:50.200 example curl requests, the exact HTTPE request headers and body, 362 00:18:50.240 --> 00:18:54.400 the corresponding HDDPU response headers and body example Jason payloads, 363 00:18:54.880 --> 00:18:57.799 all captured directly from tests that are actually running against 364 00:18:57.880 --> 00:18:59.160 your working API code. 365 00:18:59.200 --> 00:19:02.079 So the documentary is generated from the tests that prove 366 00:19:02.160 --> 00:19:04.559 the API works as expected exactly. 367 00:19:04.799 --> 00:19:07.839 Because the snippets come from passing tests, they are guaranteed 368 00:19:07.839 --> 00:19:10.240 to be accurate and reflect the current state of the API. 369 00:19:10.799 --> 00:19:12.599 If you change the API in a way that breaks 370 00:19:12.640 --> 00:19:15.519 a test, the test fails. If you update the test 371 00:19:15.519 --> 00:19:19.720 to pass with the API change, the generated snippets automatically. 372 00:19:19.200 --> 00:19:22.799 Update to So if my API changes and I forget 373 00:19:22.799 --> 00:19:25.599 to update the tests that generate the docks, the build 374 00:19:25.680 --> 00:19:29.759 potentially fails. That's a fantastic way to enforce accuracy. It is. 375 00:19:29.839 --> 00:19:32.720 It forces documentation to become a first class citizen in 376 00:19:32.759 --> 00:19:36.480 your development workflow, not an afterthought. These accurate snippets are 377 00:19:36.519 --> 00:19:39.880 then easily integrated into a nice API portal, usually using 378 00:19:39.920 --> 00:19:43.480 a side dooc formatting and some maven or gradal plugins. Yeah. 379 00:19:43.519 --> 00:19:46.880 It's a lightweight markup language, very suitable for technical documentation, 380 00:19:47.599 --> 00:19:50.720 and spring rest docks integrates beautifully with it. You can 381 00:19:50.799 --> 00:19:54.480 even configure your spring Boot application to serve this generated 382 00:19:54.519 --> 00:19:56.799 a side dooc documentation directly. 383 00:19:56.599 --> 00:19:59.279 So the docs live right alongside the API. 384 00:19:58.920 --> 00:20:01.920 They describe correct, ensuring it's always deployed with the code 385 00:20:01.920 --> 00:20:05.599 it documents, effectively killing the problem of stale documentation reaching 386 00:20:05.599 --> 00:20:09.880 your API consumers. Restos also provides handy preprocessors like pretty 387 00:20:09.960 --> 00:20:13.279 print to format JSON nicely, or mask links if you 388 00:20:13.319 --> 00:20:16.440 want to simplify hypermedia links in the examples, it gives 389 00:20:16.480 --> 00:20:19.240 you control over the final output for clarity. 390 00:20:19.480 --> 00:20:22.680 Wow, Okay, we have covered a ton of ground today. 391 00:20:22.839 --> 00:20:25.359 It feels like an incredible journey through spring Boot, doesn't it. 392 00:20:25.400 --> 00:20:28.720 We're really from making that initial development just blazing fast 393 00:20:29.119 --> 00:20:32.359 with opinionated defaults and tools like dev tools that give 394 00:20:32.400 --> 00:20:36.640 you back your mental flow to enabling robust, less error 395 00:20:36.680 --> 00:20:40.960 prone data access with Spring data, simplifying deployment dramatically with 396 00:20:41.000 --> 00:20:44.319 portable jars, and even zero docrophile container builds. 397 00:20:44.440 --> 00:20:45.680 Yeah, the bill packs. 398 00:20:45.599 --> 00:20:52.279 Streamlining operations with actuators insights, and finally really empowering truly evolvable, 399 00:20:52.359 --> 00:20:57.559 resilient APIs through hypermedia and self documenting tests with rest doocs. 400 00:20:58.200 --> 00:21:00.799 It's clear I think that the core value you proposition 401 00:21:00.920 --> 00:21:03.920