Speaker 1: Building modern software applications today. Wow, it often feels like
Speaker 1: you're trying to navigate this this vast, ever expanding ocean,
Speaker 1: doesn't it.
Speaker 2: It really does. Frameworks, patterns, deployment strategies.
Speaker 1: Yeah, the sheer volume can be overwhelming if you're trying
Speaker 1: to stay informed and you know, build genuinely robust system.
Speaker 2: Absolutely, the landscape just shifts constantly, trying to keep up
Speaker 2: with every single new thing.
Speaker 1: It's well, it leads to information overload pretty fast.
Speaker 2: Right, which is why having a guide, some kind of
Speaker 2: compass is just so.
Speaker 1: Crucial exactly to cut through all the noise.
Speaker 2: And that's exactly what we're bringing you today. We're diving
Speaker 2: headfirst into the core of modern application development. We're pulling
Speaker 2: out the really important nuggets from pro spring Boot three
Speaker 2: with Cotlin, And this isn't just about code, right, It's
Speaker 2: about understanding the why and the how behind these powerful
Speaker 2: tools that honestly make a lot of the Internet just work.
Speaker 1: And what's great here the source material comes from real experts,
Speaker 1: Peter Spieth and Felid Gutierra and Febe brings insights straight
Speaker 1: from VM where you know, the folks who actually create
Speaker 1: spring boot. Wow. Okay, so straight from the.
Speaker 2: Source, pretty much distilled down for clarity.
Speaker 1: So our mission for this deep dive is really to
Speaker 1: unpack how spring Boot, especially with Cotlin, takes these inherently
Speaker 1: complex software development tasks and just simplifies them, radically simplifies them.
Speaker 2: Yeah, show how it delivers these like surprising features right
Speaker 2: out of the box.
Speaker 1: Exactly and helps developers like you build apps that are fast,
Speaker 1: secure and crucially observable and ready for the.
Speaker 2: Cloud get ready for some aha moments. I think it
Speaker 2: can really shift how you view building apps.
Speaker 1: Think of this as your shortcut. We're cutting through the jargon,
Speaker 1: getting straight to what's genuinely important.
Speaker 2: And how you can actually apply to your own work
Speaker 2: right pretty much immediately.
Speaker 1: Okay, let's start with Springboot's core promise, then simplification and opinionation.
Speaker 1: So why spring Boot. The book makes it clear it's
Speaker 1: designed ground to be enterprise ready.
Speaker 2: Right with best practices just applied automatically.
Speaker 1: And that's the key.
Speaker 2: That's the key. The biggest advantage honestly, and it's a
Speaker 2: game changer for productivity, is that opinionated nature, meaning it.
Speaker 1: Makes choices for you sensible defaults.
Speaker 2: Exactly, sensible defaults, yeah, which leads to what the authors
Speaker 2: call sometimes zero configuration.
Speaker 1: Zero configuration. Okay, that sounds almost too good to be true.
Speaker 1: How much pain does that actually save?
Speaker 2: Well, think about the old days, right, all that XML
Speaker 2: or just tons of Java configu code just to get
Speaker 2: a basic web app talking to a database.
Speaker 1: Oh yeah, hours, sometimes days.
Speaker 2: Spring boots autoconfiguration isn't just convenient, it's like the whole
Speaker 2: paradigm shift. It means you can focus on your actual
Speaker 2: business logic, like from day.
Speaker 1: One, trusting the framework to wire up most of the infrastructure.
Speaker 2: Yeah, like ninety percent of it intelligently. It frees you
Speaker 2: from that boiler plate, letting you build complex stuff without
Speaker 2: getting bogged down and repetitive setup.
Speaker 1: That is a huge claim about productivity. But does that
Speaker 1: opinionated nature does it ever become a limitation? Do those
Speaker 1: defaults ever get in your way?
Speaker 2: It's a fair question. I mean, while it massively cuts
Speaker 2: down initial development time, sure there are times you need finer.
Speaker 1: Control, but you can override things.
Speaker 2: Oh yeah, absolutely. Springboot is designed to let you step
Speaker 2: in and override defaults pretty easily when you need to. Okay,
Speaker 2: and connecting this to the bigger picture, this whole approach
Speaker 2: also makes Springboot perfect for cloud native applications. It follows
Speaker 2: those twelve factor app principles right.
Speaker 1: The best practices for building scalable cloud.
Speaker 2: Apps exactly, things like dependency management, logging, config It handles
Speaker 2: that well. And it also sets you up for native
Speaker 2: images using AOT compilation with Grail VM.
Speaker 1: Which is huge for performance in the cloud. We'll definitely
Speaker 1: circle back to that, but let's stick into the magic
Speaker 1: a bit more. How does this autoconfiguration actually work? What
Speaker 1: happens when I run my app?
Speaker 2: So it all kicks off with the spring application class
Speaker 2: in Cotland. Your main method basically run this singleton, okay,
Speaker 2: but the real powerhouse, the thing you see everywhere is
Speaker 2: the at spring boot application.
Speaker 1: Annotation right, that one annotation, yeah.
Speaker 2: And it's actually an alias for three other critical ones
Speaker 2: You've got at spring boot configuration, which marks the class
Speaker 2: as a config source. At enable autoconfiguration, which is the
Speaker 2: trigger really. It starts the autoconfig based on what dependencies
Speaker 2: it finds on your class path.
Speaker 1: Ah, so it looks at my library exactly.
Speaker 2: And the third is that component scan which finds your
Speaker 2: own components, your controllers, services, that kind of thing.
Speaker 1: So if I just add, say the post Rascal driver
Speaker 1: dependency to my project. Yep, springboot sees that and just
Speaker 1: sets up a data source and maybe a transaction manager
Speaker 1: without me writing any code for it.
Speaker 2: That's precisely it. It sounds like a dream, but it works.
Speaker 2: It configures essentials, transaction manager for transactions, entity manager, factory
Speaker 2: if you're using JPA, the data source for connections, message
Speaker 2: converters for web stuff, even resource handler registry for static files.
Speaker 1: All that plumbing just handled, all.
Speaker 2: Handled without XML, without manual Java config beans most of
Speaker 2: the time.
Speaker 1: That's genuinely impressive. But what if I don't want one
Speaker 1: of those defaults. Say I have a really custom setup
Speaker 1: for web stuff, you can.
Speaker 2: Definitely control it that it enables autoconfiguration annotation, it has
Speaker 2: exclude and exclude name parameters. Ah okay, So if you
Speaker 2: didn't want the standard WEBNBC setup, you could just say
Speaker 2: exclude array of WEBMVC, autoconfiguration dot class. So you get
Speaker 2: the convenience, but you still have control.
Speaker 1: That's a good balance, okay. Shifting gears slightly. The book
Speaker 1: talks about personalizing your app beyond the core configuration. I
Speaker 1: was kind of amused by the custom banner thing.
Speaker 2: Yeah, it's a small touch, but it shows the level
Speaker 2: of detail instead of the default spring boot ask.
Speaker 1: Art, which is iconic but maybe not for every app.
Speaker 2: Right, you can just drop a banner dot txt file
Speaker 2: in src in main resources or set the spring dot
Speaker 2: banner dot location property.
Speaker 1: You can even use online generators right like patoorjk dot com.
Speaker 2: Yep makes something unique, or just turn it off completely
Speaker 2: with banner mode doff. It's simple but nice to have
Speaker 2: that option.
Speaker 1: So even the visual startup is configurable. What about passing
Speaker 1: arguments when you launch the app for different modes or environments?
Speaker 2: Spring good makes that super easy with the Application Arguments interface.
Speaker 1: Okay.
Speaker 2: Lets you easily grab both option arguments you know, things
Speaker 2: like enable or option value one exactly, and also non
Speaker 2: option arguments maybe like command words update or upgrade. Really
Speaker 2: useful for passing parameters at run time?
Speaker 1: And what about the app's life cycle? Are there hooks
Speaker 1: for running code at specific startup points?
Speaker 2: Yes, and there's a clear order. First, application runner gets
Speaker 2: called it gets those nice parsed application arguments. Then command
Speaker 2: line runner runs it gets the rostering arguments if you
Speaker 2: need those for some reason.
Speaker 1: The final signal the.
Speaker 2: Very last event signaling everything's initialized and ready to go.
Speaker 2: Is the application ready event? Understanding that sequence helps you
Speaker 2: plug in custom logic at the right time.
Speaker 1: That's a clear progression. Good to know. But once the
Speaker 1: app's running, how do we handle settings? You know, avoid
Speaker 1: hardcoding data based passwords everywhere. Let's get into configuration management.
Speaker 2: Okay, For basic single properties, you can just inject them
Speaker 2: using at value property.
Speaker 1: Name right, using that Spring expression language to an el exactly.
Speaker 2: Spitteel gives you a lot of power there. It pulls
Speaker 2: values straight from your application dot properties or application dot
Speaker 2: EML file.
Speaker 1: But what if I have a bunch of related settings,
Speaker 1: like all the connection details for some service, server, port, username,
Speaker 1: at value for each one seems messy?
Speaker 2: It would get messy fast. And that's where at configuration
Speaker 2: properties is fantastic. You can bind a whole group of
Speaker 2: properties like users, dot serve, dot server, users, dot service,
Speaker 2: dot port all into a single type safe class. Keeps
Speaker 2: things super clean and organized much better for maintainability.
Speaker 1: Nice And where did these properties actually come from? Is
Speaker 1: there a hierarchy? Like can an environment variable override something
Speaker 1: in my packaged application?
Speaker 2: Absolutely? And that's crue. Spring boot looks in multiple places
Speaker 2: application dot properties inside your jar first, then it looks
Speaker 2: for the same file outside the jar. Then environment variables,
Speaker 2: command line arguments, and the later ones win exactly. External
Speaker 2: sources always overwrite internal ones. So yes, an environment variable
Speaker 2: set in your deployment will trump a value inside the jar.
Speaker 2: Super useful for different environments.
Speaker 1: Takes total sense for cloud deployments and specifically for web apps.
Speaker 1: How does boot know whether to set up, for say, Tomcat,
Speaker 1: or for reactive netty.
Speaker 2: It smartly adapts based on your dependencies. If it sees
Speaker 2: Spring Bootstarter web, it assumes web application type servlet traditional
Speaker 2: blocking IO, usually with embedded Tomcat, okay. But if it
Speaker 2: find Spring Bootstarter web flux, it switches to web application
Speaker 2: type reactive, typically using Netty underneath for non blocking reactive handling.
Speaker 1: So it just figures it out based on what you include.
Speaker 2: GEP adapts seamlessly.
Speaker 1: Okay, that's flexible. Let's shift now to actually building things
Speaker 1: web development. First, classic question, at controller versus at rest control?
Speaker 1: What's the deal?
Speaker 2: Right? At rest controller is basically just a shortcut. It
Speaker 2: combines at controller with at response body.
Speaker 1: Okay, and what does that response body do? Again?
Speaker 2: It tells Spring that the return value of your method
Speaker 2: should be bound directly to the web response body, usually
Speaker 2: serialized as JSON by default.
Speaker 1: So at rest controller implies you're building an API that
Speaker 1: returns data like JSON.
Speaker 2: Exactly. If you used a plane at controller, you typically
Speaker 2: return like a view name for rendering HTML. If you
Speaker 2: wanted that controller to return JSON, you'd have to add
Speaker 2: at response body yourself. So for rest APIs at rest
Speaker 2: controller is almost always what you want.
Speaker 1: Got it that clears it up and static content HTML, CSS, JavaScript?
Speaker 1: Do I need a Patchy or Niekens in front Nope.
Speaker 2: Spring boot handles it automatically. It serves static content from
Speaker 2: standard locations in your class path, static public resources, or
Speaker 2: meta in free sources.
Speaker 1: So I just put my files there.
Speaker 2: Just put them there, and if you have an index
Speaker 2: dot html in one of those spots, boom, that's your
Speaker 2: home page. No extra config needed.
Speaker 1: Super handy. How about response formats like automatically getting JSON
Speaker 1: or maybe XML if a client asks for it.
Speaker 2: That's handled by HTPP message converters. Spring Boot sets these
Speaker 2: up for you. Jason works out of the box because
Speaker 2: the Jackson library is included with the webstarter and XML.
Speaker 2: If you add the Jackson XML extension dependency. Boot will
Speaker 2: automatically configure an XML converter two. Then it uses content
Speaker 2: negotiation based on the clients accept hitter to decide whether
Speaker 2: to send Jason or XML pretty.
Speaker 1: Smart okay, and can I tweak that Jason Serialization dates,
Speaker 1: for instance, can be formatted weirdly sometimes.
Speaker 2: Yep, easy fix. The default is a long ISO eight
Speaker 2: six oh one ish format, but you can change it
Speaker 2: globally with the spring dot Jackson dot datebomat property in
Speaker 2: application dot properties tailor it. However, you need.
Speaker 1: Good What about validating incoming data? Preventing bad data before
Speaker 1: it even hits my logic?
Speaker 2: Absolutely essential? Spring Boot integrates smoothly with the Jakarta validation API.
Speaker 1: So I can use annotation like at n blank exactly
Speaker 1: and not blank at not null at email at size,
Speaker 1: put them right on the fields of your request objects.
Speaker 2: If validation fails, spring Boot automatically handles it, usually returning
Speaker 2: a four hundred bad request with details. Keeps bad data out.
Speaker 1: And broader error handling. If something unexpected blows up deeper
Speaker 1: in my code, how do I give a clean error.
Speaker 2: Response for that? You use at controller advice along with
Speaker 2: at exception handler. This lets you centralize your exception handling logic.
Speaker 1: So one place to catch specific exceptions.
Speaker 2: Right, you can catch a custom retroboard not found exception
Speaker 2: for example, and format a nice consistent Jason error response
Speaker 2: across your whole API. Keeps your controllers cleaner.
Speaker 1: Okay, that makes sense. And mapping request to controller methods
Speaker 1: still the usual suspects like at get mapping, YEP at.
Speaker 2: Request mapping is the general one, but you'll mostly use
Speaker 2: the specifics at get mapping, at post mapping, at put mapping,
Speaker 2: at delete mapping. They map directly to the HDDP methods.
Speaker 1: And they support things like path variable.
Speaker 2: Oh yeah, pathvariables like email to pull values from the URL,
Speaker 2: plus flexibly use URL patterns using wild cards. You can
Speaker 2: also use response entity to have full control over the response,
Speaker 2: including headers like location.
Speaker 1: After creating something cool, okay, weblayer covered Now data Every
Speaker 1: app needs data persistence. How does boot simplify sl and
Speaker 1: no SQL databases? Let's start with SQL for SQL.
Speaker 2: The moment you add a database driver like the Postgres
Speaker 2: school one or do postgrisk, Correll, dot PRIs, aggressive, zeris
Speaker 2: growth counter Spring Boot auto configures.
Speaker 1: Things like the data source exactly.
Speaker 2: It sets up the data source and configures an efficient
Speaker 2: connection pool usually high CARICP by default without you doing anything.
Speaker 1: Wow, okay, no manual connection pool setup Nope.
Speaker 2: Saves a ton of boiler plate and ensures good performance
Speaker 2: right away.
Speaker 1: And what else does the framework offer for SQL?
Speaker 2: Well, the broader Spring framework gives you transaction management, so
Speaker 2: you can just annotate methods with at transactional and JDBC template,
Speaker 2: which massively simplifies raw JDBC code if you need to
Speaker 2: go that low level removes all that trycatch finally.
Speaker 1: Mess right the plan reduction again? What about setting up
Speaker 1: the database schema initially, especially for testing or local dev
Speaker 1: with embedded databases.
Speaker 2: Boot can auto initialize embedded databases like H two hsql derby.
Speaker 2: It looks for schema dot sql to create tables and
Speaker 2: data dot sql to populate them in your class path.
Speaker 1: Oh nice.
Speaker 2: It's even smart enough to look for platform specific scripts
Speaker 2: like schema dash H two dot sql or Schema dash
Speaker 2: postrescl dot sql. You can control which platform it uses
Speaker 2: with Spring dot sql dot in it dot platform.
Speaker 1: Very convenient for quick starts. Okay, moving up a level
Speaker 1: to Spring data, that's a big deal. What's the core idea? There.
Speaker 2: Spring Data revolves around repository interfaces think cred repository or
Speaker 2: paging and sorting repository.
Speaker 1: So I just define an interface.
Speaker 2: You define an interface that extends one of those, and bam,
Speaker 2: you instantly get standard methods like save fine by I,
Speaker 2: find old, delete biog implemented for.
Speaker 1: You without writing any SQL often.
Speaker 2: Yes, it uses query derivation based on method names. If
Speaker 2: you name a method find by email string email, spring
Speaker 2: data figures out the query. It's pretty magical.
Speaker 1: That is a huge time saver. Okay, so what about
Speaker 1: the specific implementations like Spring data JDBC.
Speaker 2: Spring Data JDBC gives you enhanced support on top of
Speaker 2: plane JDBC. It's built around the aggregate root concept from
Speaker 2: Domain driven Design Aggregate root. Yeah, it helps you model
Speaker 2: your data relationships cleanly, ensuring consistency, especially when you have
Speaker 2: complex optic graphs. It uses things like aggregate reference to
Speaker 2: manage links between entities.
Speaker 1: Okay, and the really popular one, Spring and Data JPA.
Speaker 2: Right. JPA simplifies using the jag of Persistence API, boot,
Speaker 2: auto Computers, a data source platform, Transaction Manager, NAT Manager,
Speaker 2: factory all the JPA infrastructure.
Speaker 1: And I just use annotations on my classes exactly at
Speaker 1: entity to market class at ID for the primary key,
Speaker 1: at generated value for generated IDs, at many, tone, at
Speaker 1: many tominy for relationships. And it can create the tables too, Right,
Speaker 1: I don't need schema dot A scale anymore often.
Speaker 2: Yes, JPA providers like Hibernate can generate the DDL Data
Speaker 2: Definition Language to create or update your schema based on
Speaker 2: your entity definitions when the app starts. Another big simplification.
Speaker 1: Wow. Okay, so that's data access covered. But what if
Speaker 1: I want to expose this data as a rest API
Speaker 1: without writing any controllers myself? Is that possible?
Speaker 2: It absolutely is. That's where Spring Data rest comes in.
Speaker 2: It's amazing.
Speaker 1: What does it do.
Speaker 2: It automatically builds a hyper media driven rest API directly
Speaker 2: from your Spring Data repository interfaces. Just add the dependency seriously,
Speaker 2: just like that, pretty much. Add the Spring Data restel
Speaker 2: explorer starter and you instantly get a discoverable API explore
Speaker 2: at http dot localhost dot a zero ad R. You
Speaker 2: can browse your resources, see the endpoints. It's incredible for
Speaker 2: rapid API prototyping.
Speaker 1: An API explorer pops up automatically. That's fantastic.
Speaker 2: Yeah, and you can customize the endpoint paths, the names
Speaker 2: used for resources, and so on using the at repository
Speaker 2: rest resource annotation if the defaults aren't perfect.
Speaker 1: Okay, that's seriously powerful. Now, what about new SQL databases
Speaker 1: like Mango dB or reddis is integration just as smooth.
Speaker 2: Pretty much. Yeah. For Mango dB adds Spring Bootstarter data.
Speaker 2: Mangun boot auto configures the connection you typically interact using
Speaker 2: Mango template or Mongo.
Speaker 1: Operations anything specific to now like with Docker.
Speaker 2: Yeah, if you're using doctor composed, make sure to set
Speaker 2: the Mango endb database environment variable so it knows which
Speaker 2: database to initialize. Oh, in Spring data, Mango dB adds
Speaker 2: a class field to your documents to help with mapping
Speaker 2: back to Java objects.
Speaker 1: Okay, and reddis for cashing or key value stuff.
Speaker 2: Similar story, add Spring Bootstarter data reddis. You can map
Speaker 2: your Java objects to Rettis hashes using the at rettis
Speaker 2: hash annotation. It stores data with clear keys like retroboard
Speaker 2: for the type and retroboard dot ued for specific instances.
Speaker 1: So SQL or nosea boot really smooths out the setup
Speaker 1: and basic operations. Okay, let's switch paradigms completely reactive programming.
Speaker 1: The book mentions the Reactive Manifesto. What's the core idea there?
Speaker 2: The Reactive Manifesto back from twenty fourteen lays out the
Speaker 2: traits of reactive systems. They need to be responsive, resilient,
Speaker 2: elastic and message driven.
Speaker 1: So quick, fault tolerant, scalable and using async messages exactly.
Speaker 2: It's about building systems that handle load and failure gracefully.
Speaker 2: Using asynchronous communication and back pressure is key so components
Speaker 2: don't get overwhelmed. It's a different way of thinking compared
Speaker 2: to traditional blocking code.
Speaker 1: A big shift. And how does Spring implement this on
Speaker 1: the JVM?
Speaker 2: Primarily through Project Reactor. It's a library based on the
Speaker 2: reactive stream specification that's a standard for ACYNC stream processing
Speaker 2: with back pressure. Reactor brings this non blocking, event driven
Speaker 2: approach to Java.
Speaker 1: And what are the main building blocks developers use in reactor?
Speaker 2: The two core types are monot and flux.
Speaker 1: T Mono andflux okay.
Speaker 2: Mono represents the stream of zero or one item. Think
Speaker 2: of it like an ACNC optional. Flux represents the stream
Speaker 2: of zero to n items. It's an asynchronous sequence.
Speaker 1: Got it? And when you use this with springboot, how
Speaker 1: do you reactive web and data look different.
Speaker 2: For reactive web you add spring boots Starter web flux boot,
Speaker 2: autoconfigures it, and crucially it defaults to using Netty instead
Speaker 2: of Tomcat as the server.
Speaker 1: Because netti is non blocking.
Speaker 2: Exactly ensures the whole iostack is non blocking. For reactive
Speaker 2: data access, you'd use reactive repository interfaces like reactive CRUD repository, so.
Speaker 1: The entire request path from web to database and back
Speaker 1: can be non blocking.
Speaker 2: That's the goal. It's essential for applications needing really high
Speaker 2: concurrency and low latency.
Speaker 1: Okay, a powerful option for specific needs. Now let's talk
Speaker 1: about communication within and between applications using messaging. How does
Speaker 1: spring boot handle events?
Speaker 2: Well, Spring itself has core events like context refreshed event.
Speaker 2: Spring boot adds its own like application ready event. We
Speaker 2: mentioned that one earlier fires when the app is fully ready.
Speaker 1: Can I create my own events for internal communication like
Speaker 1: decoupling parts of my app?
Speaker 2: Oh? Absolutely, it's a great pattern. You can create custom
Speaker 2: event classes by extending application event or even simpler, just
Speaker 2: anne tape method with at event listener.
Speaker 1: So I could have say a user activated event.
Speaker 2: Exactly publish that event when a user becomes active. Then
Speaker 2: have another component listen for at event listener and if
Speaker 2: you want the listener to run without blocking the publisher,
Speaker 2: just add at at ASNC. Really powerful for loose coupling.
Speaker 1: Nice. What about more traditional messaging systems JMS.
Speaker 2: Easy integration, add the starter for active MQ Spring Bootstarter,
Speaker 2: Active MQ or Artemis Spring bootstarter.
Speaker 1: Artemis and sending and receiving.
Speaker 2: You use JMS template dot convert and send to publish messages.
Speaker 2: To listen, you just annotate a method with at JMS
Speaker 2: listener specifying the Q or topic.
Speaker 1: Name and pubsub versus point to point.
Speaker 2: Simple property dot spring dot JMS dot pubsubdomain true switches
Speaker 2: it to topic mode published subscribe.
Speaker 1: Okay, straightforward. What about AMQP and RabbitMQ that has more
Speaker 1: complex concepts right exchanges, bindings it.
Speaker 2: Does MQP uses exchanges, bindings and queues. Messages go to
Speaker 2: an exchange first. Bindings are rules that wrote messages from
Speaker 2: an exchange to specific queues. Queues are where consumers pick
Speaker 2: messages up.
Speaker 1: So the exchanges like the central post office, bindings are
Speaker 1: the sorting rules. Queues are the mailboxes.
Speaker 2: Perfect analogy, and there are different types of exchanges for
Speaker 2: different routing logic direct uses a specific routing key, fan
Speaker 2: out broadcast to all bound cues. Topic uses wildcard routing
Speaker 2: keys like user or audit hashtag headers roots based on
Speaker 2: message headers.
Speaker 1: Lots of flexibility there. How to spring AMQP help.
Speaker 2: It gives you annotations like at rabbit listener to easily
Speaker 2: consume messages, and you can programmatically declare queues, exchanges and
Speaker 2: bindings using at qu at exchange and at que binding annotations,
Speaker 2: which simplifies set up a lot.
Speaker 1: Okay, powerful routing options. What about real time two way
Speaker 1: communication like for chat apps or live dashboards?
Speaker 2: For that, you typically use web sockets. It's a protocol
Speaker 2: providing full duplex communication over a single TCP connection. Client
Speaker 2: and server can both send messages anytime, and.
Speaker 1: People often use STOMP over web sockets.
Speaker 2: Yes. STOMP simple text oriented messaging protocol adds a layer
Speaker 2: on top providing message headers, destinations, and a pub submodel,
Speaker 2: making it easier to route messages to specific users or
Speaker 2: topics within the web socket connection.
Speaker 1: How do you set that up? In boot?
Speaker 2: Add Spring Bootstarter web socket UH on the server you
Speaker 2: use at enable web socket message broker and configure endpoints
Speaker 2: and brokers using web socket message broker configure.
Speaker 1: And the book also mentions our socket what's that for?
Speaker 2: Our socket is a newer binary protocol designed for high performance,
Speaker 2: low latency communication, especially between micro services.
Speaker 1: Binary not tech space.
Speaker 2: Right, and it supports more interaction models than just request response.
Speaker 2: You have fire and forget request stream, server streams, data
Speaker 2: back and channel fully bi directional streams.
Speaker 1: How do you use it with springboot ad.
Speaker 2: Spring bootstarter socket? You use our socket request or on
Speaker 2: the client side and at message mapping on the server
Speaker 2: side to handle incoming requests or streams. It's geared towards
Speaker 2: high throughput scenarios.
Speaker 1: Okay, so boot really covers the whole spectrum of communication needs.
Speaker 1: Now let's talk about getting these apps production ready spring Boot.
Speaker 1: Actuator is key here right for observability.
Speaker 2: Absolutely, Actuator is your go to for production insights. Yeah.
Speaker 2: It exposes a ton of useful information and management endpoints
Speaker 2: over HTTP or JMX, think metrics, health checks, environment variables,
Speaker 2: thread dumps, logger levels.
Speaker 1: Like a built in dashboard for your apps internals kind of.
Speaker 2: Yeah. It gives monitoring tools the hooks they need.
Speaker 1: What are the most critical endpoints?
Speaker 2: The main prefix is actuator. The most important one enabled
Speaker 2: by default is actuator Health. It gives a basic updown
Speaker 2: status but can be customized to check dependencies too and others.
Speaker 2: Actuator info for app info, Actuator Metrics for detailed metrics,
Speaker 2: Actuator loggers to view and change log levels on the fly,
Speaker 2: Actuator beans to see all the Spring beans, Actuator events
Speaker 2: for environment properties, Actuator audit events for security stuff. Lots
Speaker 2: of useful ones?
Speaker 1: Are they all enabled by default? Seems like some could be?
Speaker 2: Some good point? No, Only health and sometimes info are
Speaker 2: exposed over HTTP by default. You need to explicitly enable
Speaker 2: others using the management Dot endpoints dot web dot exposure DOT.
Speaker 3: Include property like health infometrics exactly, and for sensited ones
Speaker 3: like loggers or envy, you absolutely must secure them, usually
Speaker 3: by integrating Actuator with Spring security and requiring a specific
Speaker 3: role like actuator admin makes sense.
Speaker 1: Can I create my own Actuator endpoints for application specific stuff?
Speaker 2: Yep, It's surprisingly easy. You create a class annotated with
Speaker 2: that endpoint, and then methods inside annotated with that readoperation
Speaker 2: for deed, at write operation for PSD or at delete
Speaker 2: operation lets you expose custom state or operations.
Speaker 1: What about custom health checks, like checking if a downstream
Speaker 1: service is reachable?
Speaker 2: Definitely you implement the health Indicator interface. This lets you
Speaker 2: plug in custom logic, check a database, call an external API,
Speaker 2: verify a business rule, and have its status contribute to
Speaker 2: the overall Actuator health endpoint a much riger picture of health.
Speaker 1: Okay, and for the full observability trifecta metrics, logs tracing.
Speaker 1: How does actuator fit in?
Speaker 2: Actuator is the main integration point, especially for metrics. It
Speaker 2: uses micrometer underneath micrometer. Yeah, it's a vendor neutral application
Speaker 2: metrics facade think SLF four J. But for metrics, Actuator
Speaker 2: exposes micrometer metrics.
Speaker 1: Can I add my own business metrics easily?
Speaker 2: Yes? You can inject the meter registry and create counters, timers,
Speaker 2: gauges directly, or even better, use the ad observed annotation
Speaker 2: from Micrometer Observation AOP for a more declarative approach. You
Speaker 2: can also use things like handler interceptor to automatically time
Speaker 2: web requests.
Speaker 1: Okay, So metrics are covered. What about logs and distributed tracing?
Speaker 2: For logs, you typically can figure something like log back
Speaker 2: using logbackspring dot xml to output structured logs like JSON
Speaker 2: and then ship them off to a log aggregation system
Speaker 2: like Grafonoloki or elastic search.
Speaker 1: And tracing across micro services.
Speaker 2: For that you integrate with distributed tracing systems. Spring Boot
Speaker 2: has great support for Jaeger and Zipkin, often visualized with
Speaker 2: Graffana Tempo. My Chrometer Tracing handles the instrumentation.
Speaker 1: And Graffana brings it all together exactly.
Speaker 2: Use Prometheus often to scrape the actuated Prometheus metrics endpoint
Speaker 2: looking for logs, Tempo for traces, and then Graffana provides
Speaker 2: the unified dashboards to visualize everything. That's your full observability stack.
Speaker 1: That's a comprehensive setup. Okay, ensuring quality before production testing.
Speaker 1: How does springboot help there?
Speaker 2: It builds on the standard spring test framework but adds
Speaker 2: autoconfiguration goodness. The main tool for integration testing is at springboot.
Speaker 1: Test and that loads the whole application context.
Speaker 2: Yes, it loads the full context, making it very realistic.
Speaker 2: You can control the web environment, random port, moc numbi,
Speaker 2: past properties ARGs. It's flexible but can be slower.
Speaker 1: Right, loading everything can be slow. What if I just
Speaker 1: want to test one layer like my web controllers.
Speaker 2: That's where test likeses are brilliant. They load only the
Speaker 2: parts of the context relevant to a specific layer, making
Speaker 2: tests much faster. Example, at webmvictest is a big one.
Speaker 2: It focuses just on the web layer, your controllers, filters,
Speaker 2: et cetera. It auto configures mock them VC for sending
Speaker 2: mock HTTP requests and often uses at mockbeing to mock
Speaker 2: out service dependencies.
Speaker 1: So you test the controller in isolation pretty much.
Speaker 2: There's also at json test for testing Jason serial de
Speaker 2: serialization logic.
Speaker 1: Specifically, and for the data layer testing repositories.
Speaker 2: You have slices like at data JPay tests for jpa
Speaker 2: at data, Mango tests for manga deb at data edis
Speaker 2: test at jdbt tests. These load just a data configuration
Speaker 2: and often use an embedded database or mock the noseql client.
Speaker 1: But embedded databases aren't always the same as production. How
Speaker 1: do you test against a real database like postgress bowl reliably?
Speaker 2: That's the perfect use case for test containers. It's fantastic
Speaker 2: that does it work. You annotate your test class to
Speaker 2: use a container like a container for a post riscal
Speaker 2: container test container starts a real postgressfol instance in Docker
Speaker 2: just for your test run.
Speaker 1: Wow, a real database instance.
Speaker 2: For tests yep, and with at service connection, spring Boot
Speaker 2: tests can automatically configure your application context to connect to
Speaker 2: that container. It makes integration tests incredibly reliable. The at
Speaker 2: restart scope annotation is also useful to keep the container
Speaker 2: running between test methods in the same class, speeding things up.
Speaker 1: That's amazing for confidence, okay, equally critical security. How does
Speaker 1: spring boot security work under the hood.
Speaker 2: It's built around a chain of servelet filters. The entry
Speaker 2: point is usually delegating filter proxy, which passes the request
Speaker 2: to a filterchain proxy. This proxy manages multiple security filter
Speaker 2: chain instances, each potentially handling different URL patterns or security concerns.
Speaker 2: It processes the HTTP servelet request and HTTP servelet response.
Speaker 1: How do I add it to my project?
Speaker 2: Just add the spring boot starter security dependency. Springboot autoconfigures
Speaker 2: basic security immediately, which means usually it enables HTTP basic
Speaker 2: informed log in, secures all end points by default, and
Speaker 2: generates a default user with a random password into the
Speaker 2: console and startup just enough to get you started securely.
Speaker 1: How do I manage users properly, not just the default
Speaker 1: and memory one.
Speaker 2: For simple cases, you can configure in memory user details manager,
Speaker 2: but for real apps you implement the user detail service.
Speaker 1: Interface and that talks to my database.
Speaker 2: Typically, yes, you'd inject your user repository into your custom
Speaker 2: user detail service implementation to load user details. Spring security
Speaker 2: then uses a DEO authentication provider to check passwords against
Speaker 2: what your service.
Speaker 1: Returns, and you configure log in methods like form log in.
Speaker 2: Yeah. Using the HTDP security Configuration object, you call methods
Speaker 2: like HTTP basic or form log in to enable those mechanisms.
Speaker 2: You also configure authorization rules there, like request matchers, admin
Speaker 2: dot has role adm an.
Speaker 1: What about cores? That's always tricky.
Speaker 2: With front ends trucial, you can figure cores using a
Speaker 2: course configuration source being usually within your security configuration to
Speaker 2: allow requests from your front ends.
Speaker 1: Origin and reactive security.
Speaker 2: For web flex it's similar conceptually, but uses re active types.
Speaker 2: You can figure server HTTP security instead of HTTP security,
Speaker 2: and things like login handlers use reactive interfaces like server
Speaker 2: authentication success handler.
Speaker 1: Can I test security rules easily without doing a full
Speaker 1: log in and every test?
Speaker 2: Yes. The atwith mock user annotation is perfect for this.
Speaker 2: You can apply it to your at webmvictest or at webflux.
Speaker 2: Test methods to simulate a request coming from an already
Speaker 2: authenticated user with specific roles saves a ton of setup.
Speaker 1: Very handy. What about social login OOF two with GitHub.
Speaker 2: Or Google also well supported? Add Spring Bootstarter O two client.
Speaker 2: You can figure your client ID in secret from the provider,
Speaker 2: use environment variables or secrets management, never hardcode them. Spring
Speaker 2: Security handles the whole redirect dance and authentication flow smooth.
Speaker 1: The book also mentions Spring Authorization Server. What's that? Why
Speaker 1: would I run my own authorization server?
Speaker 2: That's for when you want to be the identity provider,
Speaker 2: maybe for your own suite of micro services or partner applications.
Speaker 2: Spring Authorization Server is a dedicated project providing a compliant
Speaker 2: OOF two point one and open id Connect one point
Speaker 2: zero server implementation built on Spring Security. You can figure
Speaker 2: clients scopes like users, dot red, token, settings, etc. Gives
Speaker 2: you full control over the identity aspect.
Speaker 1: Okay, so full spectrum of security. Let's shift to performance
Speaker 1: and deployment Spring boot native and AOT with galvim. What's
Speaker 1: the big deal with GraalVM.
Speaker 2: Galvm is a high performance JDK distribution key features are
Speaker 2: faster JIT compilation, support for multiple languages, and most importantly
Speaker 2: for this discussion, its native image capability.
Speaker 1: Native image What does that actually mean for my app?
Speaker 2: It means compiling your Java Cottlin code ahead of time
Speaker 2: AOT into a standalone native executable for a specific platform
Speaker 2: like Linux by sixty four. This executable does not require
Speaker 2: a JVM to run.
Speaker 1: No JVM. What's the benefit?
Speaker 2: Huge benefits. Drastically faster startup times think milliseconds instead of seconds,
Speaker 2: and significantly lower memory footprint, maybe tens of megabytes instead
Speaker 2: of hundreds. It's the game changer for serverless functions, containers
Speaker 2: anywhere resources or startup speed matter.
Speaker 1: That is a massive difference. How do you build one
Speaker 1: with Springboot?
Speaker 2: Typically using the build tool plugins like Doug gritlue Boot
Speaker 2: build Image or the Maven equivalent. This often uses cloud
Speaker 2: native build packs behind the scenes to perform the native
Speaker 2: compilation inside a container and package the result.
Speaker 1: And what spring boots specific role the AOT part exactly.
Speaker 2: The standard Java reflection and dynamic proxies that spring uses
Speaker 2: heavily are difficult for grailvm's static analysis, so spring boots
Speaker 2: AOT engine runs at build time, analyzes your application context
Speaker 2: figures out what beams, proxies and configurations will be needed
Speaker 2: at runtime, and generates extra source code and hints.
Speaker 1: So it pre computes the runtime configuration essentially.
Speaker 2: Yes, it generates code that GRAILVM can analyze statically, allowing
Speaker 2: the native compilation to succeed while preserving Springs functionality.
Speaker 1: What if my code does something really dynamic, like reflection
Speaker 1: that the AOT engine misses.
Speaker 2: That's where you need runtime hints. Can implement a runtime
Speaker 2: hints registrar interface to programmatically tell the AOT engine about
Speaker 2: specific reflection needs, resource loading, serialization, or proxy requirements that
Speaker 2: it couldn't detect automatically.
Speaker 1: Okay, so native images offer huge performance games enabled by
Speaker 1: Springs AOT processing. Now looming out to architecture spring Cloud
Speaker 1: for microservices. How to boot and cloud fit together.
Speaker 2: They're designed to work hand in glove. Springboot is perfect
Speaker 2: for building the individual microservices self contained runnable jrs with
Speaker 2: embedded servers. It aligns perfectly with those twelve factor app
Speaker 2: principles needed for micro services.
Speaker 1: Like codebase canfig dependencies processes exactly.
Speaker 2: Springboot gives you the ideal building block. Spring Cloud then
Speaker 2: provides the tools to handle the interactions and patterns needed
Speaker 2: in a distributed microservice system.
Speaker 1: And when we talk cloud development, it's more than just
Speaker 1: deploying to AWS right.
Speaker 2: It's about building applications natively for the cloud environment, leveraging elasticity,
Speaker 2: fault tolerance, managed services, moving beyond just lifting and shifting
Speaker 2: old apps to designing for the cloud from the start.
Speaker 1: So what are some key spring Cloud technologies that help
Speaker 1: manage this complexity?
Speaker 2: Okay, several key ones. First, spring Cloud Console or Eureka
Speaker 2: or Kubernety. Service discovery. It handles service registration and discovery.
Speaker 2: Services register themselves and clients can dynamically find where other
Speaker 2: services are running without hardcoding URLs. It can also manage
Speaker 2: externalized configuration.
Speaker 1: Essentral for dynamic environments.
Speaker 2: What else spring Cloud open fame. This makes calling other
Speaker 2: rest services incredibly easy. You just define a Java interface
Speaker 2: with annotations and fine handles creating the HTTP client, doing
Speaker 2: service discovery, client side load balancing. It feels like calling
Speaker 2: a local method.
Speaker 1: Nice abstraction. What about secrets, databased passwords, apikes?
Speaker 2: Spring Cloud Vault. It integrates with how she co op
Speaker 2: Vault or other secret managers to securely inject secrets into
Speaker 2: your application and run time. No more secrets and properties,
Speaker 2: files or environment variables. Volt handle secure storage, access control
Speaker 2: and even secret.
Speaker 1: Rotation critical for security. What about the entry point to
Speaker 1: the whole system.
Speaker 2: That's spring Cloud Gateway. It's an API gateway built on
Speaker 2: spring webslucks, so it's reactive and non blocking. It provides
Speaker 2: a single point of entry for all external requests. It
Speaker 2: can handle routing, applying security filters like rate limiting or authentication,
Speaker 2: load balancing, path rewriting, and implementing resilience patterns like circuit breaking.
Speaker 1: Circuit breaks.
Speaker 2: Yeah, if a downstream service starts failing, the gateway can
Speaker 2: trip the circuit and stop setting request to it for
Speaker 2: a while, preventing cascading failures and returning a fallback response instead.
Speaker 1: Smart and finally, orchestrating all these containerized services Kubernetes absolutely.
Speaker 2: Kubernetes k eights is the standard for container orchestration spring Cloud.
Speaker 2: Kubernetes provides integrations spring Cloud Starter, Kuberneteses Client all so
Speaker 2: your boot apps can seamlessly leverage K eight's features like
Speaker 2: config maps for configuration, secrets for secrets management, and KAID
Speaker 2: service discovery, all without much code change you deploy using
Speaker 2: Kid's deployment and service ammal manifests.
Speaker 1: So spring cloud provides the connective tissue for boot micro
Speaker 1: services in a cloud environment. Okay, one more advanced topic,
Speaker 1: extending boot itself with custom starters. Why bother creating your own?
Speaker 2: The main reasons are speed, consistency, and maintainability within your
Speaker 2: organization or team. If you have a common cross cutting
Speaker 2: concern like specific auditing, security checks or client library setup,
Speaker 2: you can package it as a starter.
Speaker 1: So new projects just include your starter exactly.
Speaker 2: They get all that boilerplate and configuration handled automatically, ensuring
Speaker 2: everyone follows the same pattern. It reduces setup time, It
Speaker 2: makes codebases more consistent and easier to maintain.
Speaker 1: Is it like using spring zone at enable annotations at
Speaker 1: enable web NBC at enable caching?
Speaker 2: Very similar concept. Those annotations trigger auto configuration. You can
Speaker 2: create your own custom that enable my feature annotation as
Speaker 2: part of your starter to make it easy for users
Speaker 2: to opt in to your functionality.
Speaker 1: Declaratively, how are starters typically structured?
Speaker 2: Usually as two modules. An autoconfigure module contains the core logic,
Speaker 2: the at configuration or at autoconfiguration classes often conditional using
Speaker 2: at conditional non annotations, any configuration properties, classes and the
Speaker 2: logic itself like aspects or beans.
Speaker 1: And the second module.
Speaker 2: A starter module. This one's usually very simple. It just
Speaker 2: declares dependencies on the autoconfigure module and any other third
Speaker 2: party libraries. Your feature needs users, then just depend on
Speaker 2: your my feature spring boots starter.
Speaker 1: Can you give a quick example.
Speaker 2: The book uses a my retroadit Starter example. It is
Speaker 2: a custom in my retrodit annotation an aspect my retro
Speaker 2: audit aspect uses at a round advice to intercept calls
Speaker 2: to annotated methods and log ondit info, and the auto
Speaker 2: configuration a my retroaddic configuration class marks at autoconfiguration conditionally
Speaker 2: enables the aspect maybe based on a property or if
Speaker 2: the custom at enable my retroad annotation is present, then
Speaker 2: you register this autoconfiguration clas in the special meta and
Speaker 2: f spring org dot, spring framework, dot boot, dot autoconfigure,
Speaker 2: dot autoconfiguration dot imports.
Speaker 1: File so it automatically wires up the auditing aspect if
Speaker 1: the starter is included and enabled. Clever okay. Wrapping up
Speaker 1: the book touches on some newer projects. What's exciting on
Speaker 1: the horizon.
Speaker 2: First, Spring modulith. This is interesting. It's not micro services,
Speaker 2: but it helps structure larger spring Boot modulates into well
Speaker 2: defined modules within the same.
Speaker 1: Codebase, modularity inside the monolith exactly.
Speaker 2: It helps enforce boundaries between modules, verifies dependencies of build time,
Speaker 2: and can even generate diagrams of your module structure. It
Speaker 2: encourages looser coupling, often through event driven communication between modules
Speaker 2: instead of direct calls. It's about making monoliths more manageable,
Speaker 2: a pragmatic approach. What else, Spring ai this is huge.
Speaker 2: It's a new framework bringing AI capabilities, especially large language
Speaker 2: models lms like GBT four directly into Spring applications.
Speaker 1: Like Python's lang chain but for Java Spring.
Speaker 2: Kind of yeah. It simplifies interacting with AIME models using
Speaker 2: concepts like chat client prompt templates and handling embeddings numerical
Speaker 2: representations of text for semantic understanding. Makes building AI powered
Speaker 2: features in Spring much.
Speaker 1: Easier, very cool and performance improvement.
Speaker 2: Virtual threads from Jaba twenty one are now supported in
Speaker 2: Spring Boot three point two plus okios. You just flip
Speaker 2: a switch Spring dot threads dot virtual dot enable true
Speaker 2: and tomcatter jety can start using lightweight virtual threads for
Speaker 2: handling requests.
Speaker 1: What's the benefit.
Speaker 2: Potentially massive throughput improvements for iobound applications without complex ACYN
Speaker 2: code because you can have millions of virtual threads with
Speaker 2: very little overhead compared to traditional platform threads.
Speaker 1: Wow, simple switch, big impact potentially. And finally, Graphql.
Speaker 2: Yeah, graph L is gaining traction as an alternative to
Speaker 2: rest It lets clients request exactly the data they need,
Speaker 2: no more, no less, reducing overfetching. Spring for Graphql provides
Speaker 2: excellent integration.
Speaker 1: How does it work?
Speaker 2: You define your API schema using GRAPHQOLS, Schema Definition Language
Speaker 2: SDL and a dog graphcuels file. Then in your Spring
Speaker 2: code you use annotations like at query mapping and at
Speaker 2: mutation mapping on methods to implement the resolvers for your
Speaker 2: schema fields. It also integrates with tools like graphuel for
Speaker 2: interactive testing.
Speaker 1: So a different way to build APIs fully supported. Wow. Okay,
Speaker 1: we have covered a lot of ground here. It's been
Speaker 1: a real deep dive, hasn't it.
Speaker 2: Absolutely from the core ideas of autoconfiguration, right.
Speaker 1: Through building web apps, data access messaging, then production stuff
Speaker 1: like actuator testing, security.
Speaker 2: Dative images. Spring Cloud for micro services even custom starters
Speaker 2: and bleeding edge things like AI and virtual threads.
Speaker 1: It really paints a picture of a comprehensive ecosystem.
Speaker 2: It does. It's about enabling developers to build sophisticated systems
Speaker 2: faster and more reliably, handling the boiler plate so you
Speaker 2: can focus on the unique value.
Speaker 1: So for you listening, what really stands out is how
Speaker 1: Spring boot, with this whole rich ecosystem, acts like this
Speaker 1: incredible orchestrator right. It lets you the developer, build complex
Speaker 1: applications quickly without getting totally bogged down on the plumbing.
Speaker 1: It empowers you to focus on your business logic. You
Speaker 1: can really see how all these pieces from a simple
Speaker 1: at rest controller to a full Kate's deployment fit together.
Speaker 2: It gives you the tools and the patterns to build
Speaker 2: modern software effectively.
Speaker 1: And as we saw with things like Spring Modulus and
Speaker 1: Spring AI, this whole landscape just keeps evolving, doesn't it.
Speaker 1: So here's the thought to leave you with, what if
Speaker 1: the next big leap isn't just about how services talk
Speaker 1: to each other, but how entire applications, maybe modular ones
Speaker 1: powered by AI can adapt and reconfigure themselves on the fly,
Speaker 1: almost like biological systems. What new Aha moments are waiting
Speaker 1: just around the corner in software architecture, Something to chew
Speaker 1: on as you continue your own explorations in this fascinating world.