Spring Boot Fundamentals

Both configure the same things — server port, datasource URL, logging levels, custom properties — just in different syntax. .properties is flat key=value pairs; .yml (YAML) supports nested structures natively, which reads more cleanly for deeply grouped configuration (and is required for some structures like a list of maps). YAML is whitespace/indentation-sensitive, which trips people up; .properties has no such fragility but gets repetitive for deeply nested keys.

# application.properties
spring.datasource.url=jdbc:postgresql://localhost/db
spring.datasource.username=app

# application.yml
spring:
  datasource:
    url: jdbc:postgresql://localhost/db
    username: app

Instead of building a WAR and deploying it to an externally installed Tomcat, Spring Boot bundles the servlet container (Tomcat by default, Jetty or Undertow as swap-in alternatives) directly inside the runnable JAR. Starting the application programmatically starts an embedded server instance on a configured port — so "running the app" is just java -jar app.jar, with no separate server installation, configuration, or deployment step. This is a big part of why Spring Boot apps are so friendly to containerized deployment (Docker) — the artifact is fully self-contained.

@Value("${some.property}") injects a single configuration value directly into a field — a lighter-weight alternative to binding a whole @ConfigurationProperties class when you just need one or two values.

Spring Boot reads configuration from many sources, applying them in a defined precedence order (highest wins on conflict) — roughly, from highest to lowest priority: command-line arguments, JVM system properties, OS environment variables, profile-specific application-{profile}.yml, then the base application.yml, then @PropertySource-declared files, then defaults set in code. This lets ops override a single value at deploy time (e.g. an environment variable) without touching any config file baked into the jar.

Actuator adds production-monitoring endpoints to a Spring Boot app with almost no setup — just add the spring-boot-starter-actuator dependency. It exposes endpoints like /actuator/health (is the app and its dependencies — DB, disk space — healthy?), /actuator/metrics (JVM memory, request counts, custom metrics), /actuator/env (resolved configuration properties), and /actuator/info — the exact set of endpoints exposed over HTTP is configurable (most are disabled by default except health/info, since some leak sensitive internal detail).

@Value injects one property at a time — fine for a single field, awkward once you have a whole related group of settings. @ConfigurationProperties binds a whole prefix of properties onto a strongly-typed class in one shot, including nested objects and lists, with IDE auto-complete support and centralized validation (via Bean Validation annotations on the properties class).

@ConfigurationProperties(prefix = "app.mail")
record MailProperties(String host, int port, @NotBlank String from) { }

// application.yml:
// app.mail.host: smtp.example.com
// app.mail.port: 587
// app.mail.from: noreply@example.com

@Service
class MailService {
    MailService(MailProperties mailProperties) { ... } // fully populated, type-safe object
}

Adding springdoc-openapi-starter-webmvc-ui (the modern successor to the older springfox library) automatically scans your controllers and generates an OpenAPI specification — a machine-readable description of every endpoint, its parameters, and response shapes — plus a browsable Swagger UI page (typically at /swagger-ui.html) where you can try requests directly from the browser. Annotations like @Operation, @Parameter, and @Schema let you add human-readable descriptions on top of what's inferred automatically from your method signatures and DTOs.

@Async on a method makes Spring run it on a separate thread (from a configurable task executor) instead of the caller's thread — the call returns immediately, letting the caller move on rather than block waiting for that method to finish.

@EnableAsync // required on a @Configuration class to activate @Async processing
@Service
class NotificationService {
    @Async
    void sendEmail(String to) { ... } // caller doesn't wait

    @Async
    CompletableFuture<Report> generateReport() { ... } // caller can await/compose the result later
}

Limitations worth knowing: it only works through the same Spring AOP proxy mechanism as @Transactional, so self-invocation bypasses it just like the transactional self-invocation gotcha; exceptions thrown inside a void @Async method are simply logged, not propagated to the caller (since the caller already moved on); and it needs @EnableAsync explicitly enabled to take effect at all.

Spring's caching abstraction (@EnableCaching + a cache provider like Caffeine or Redis) lets you cache a method's return value declaratively, without hand-writing cache-lookup logic inside the method itself.

@Cacheable("users")                 // cache the result, keyed by the argument(s)
User findById(Long id) { ... }        // subsequent calls with the same id skip the method body entirely

@CachePut("users")                    // always runs the method, but updates the cache with the result
User update(User user) { ... }

@CacheEvict("users")                  // removes the entry so the next read is fresh
void delete(Long id) { ... }

Like @Transactional and @Async, this works via an AOP proxy — the same self-invocation limitation applies, and the cache key defaults to the method's arguments unless you customize it with a SpEL key expression.