What Spring Boot Is

Here is the main method of a small booking service written in plain Java, with no framework.

SeatRepository seats = new SeatRepository();
PaymentClient payments = new PaymentClient(paymentUrl, paymentTimeoutMillis);
EmailSender sender = new EmailSender(mailHost, mailPort);
Notifier notifier = new Notifier(sender);
BookingService bookings = new BookingService(seats, payments, notifier);
Copy

Five lines create five objects, and each line must come after the objects it needs. None of these lines books a seat, because they exist only to build the objects that do.

A real service has hundreds of such objects, plus a web server, settings, and database connections. The sections below show which of this work Spring and Spring Boot take over, and what happens when the smallest Spring Boot application starts.

The Work Around Your Code

Every backend service contains two kinds of code: code that does the business work, and code that prepares the program so that work can run. In the booking service, the business work is short: it checks that a seat is free, charges the customer, reserves the seat, and sends a confirmation. The preparation work is longer:

• Creating and connecting objects. Each object needs its dependencies (the other objects it calls) before it can be built.
• Reading settings. The payment URL, a timeout, and the mail server differ between a laptop and production.
• Receiving HTTP requests. Some code must listen on a port, read each request, and call the right method.
• Talking to a database. Connections must be opened, shared, and returned, and a booking must succeed or fail as one unit.
• Running in production. Operators need health checks, metrics, and logs.

The program below does only the first two, by hand: its settings are fixed in the code, and main builds every object. Run it to see the order of construction and two bookings of the same seat.

It prints the following:

Objects created by main, in order:
  1. SeatRepository
  2. PaymentClient (https://payments.example.com, 2000 ms)
  3. EmailSender (mail.example.com:587)
  4. Notifier
  5. BookingService

  email to ana@example.com: Seat A12 is yours
Booked seat A12 for ana@example.com
Seat A12 is already taken
Copy

The order matters, because Notifier needs an EmailSender and the sender must therefore exist first. If PaymentClient later needs a retry policy, someone must create that policy in main and pass it in, and every test that builds a PaymentClient must change as well.

Spring: A Container That Builds Your Objects

The Spring Framework is a library that creates the objects of your application, connects them to each other, and manages them while the program runs. The part that does this is the container. It is also called the IoC container, for inversion of control, because the framework now controls construction instead of your code. Spring calls each object that the container manages a bean.

With Spring, you no longer write the five lines in main. You mark each class so the container can find it, and you declare its dependencies as constructor parameters:

@Service
public class BookingService {
    private final SeatRepository seats;
    private final PaymentClient payments;
    private final Notifier notifier;

    public BookingService(SeatRepository seats, PaymentClient payments, Notifier notifier) {
        this.seats = seats;
        this.payments = payments;
        this.notifier = notifier;
    }
}
Copy

At startup, the container finds every marked class and reads its constructor. It works out an order that builds each dependency first, and then it calls the constructors itself. BookingService changed by one annotation only, so a unit test can still create it with new.

Notice what happens when PaymentClient gains a RetryPolicy. By hand, main gains a line and an edit, while with the container only the PaymentClient constructor changes, and the container builds the policy first.

Spring also provides web support, data access, transactions, and security. However, plain Spring leaves many choices to you: which libraries to combine, which versions work together, and which server to deploy to.

Spring Boot: Spring With the Setup Already Chosen

Spring Boot is a layer on top of the Spring Framework that chooses sensible defaults, so a working application needs very little setup. It adds four things:

• Starters. A starter is one dependency that brings a tested set of libraries. For example, spring-boot-starter-webmvc brings Spring MVC (the web framework of Spring) and the Tomcat web server.
• Auto-configuration. At startup, Spring Boot looks at the libraries on the classpath (the libraries the program can load). It creates the beans those libraries need, unless you have defined your own.
• An embedded server. The web server runs inside your application. One command starts the service, and nobody installs a separate server.
• Externalized configuration. Settings come from application.properties, environment variables, or command-line arguments. The same build therefore runs on a laptop and in production.

The Smallest Spring Boot Application

The two classes below are a complete web application. The Spring Initializr (start.spring.io, a site that generates new Spring Boot projects) creates the first one, and the second adds one endpoint.

@SpringBootApplication
public class BookingApplication {
    public static void main(String[] args) {
        SpringApplication.run(BookingApplication.class, args);
    }
}

@RestController
class HelloController {
    @GetMapping("/hello")
    String hello() {
        return "Booking service is running";
    }
}
Copy

The single call to SpringApplication.run does four things, in this order:

1. It creates the container.
2. Because of @SpringBootApplication, it scans the package of BookingApplication and every package below it, where it finds HelloController.
3. Auto-configuration finds Spring MVC and Tomcat on the classpath. It creates the beans that route HTTP requests to controllers and write responses.
4. It starts the embedded Tomcat server, which listens on port 8080 unless a setting changes it.

A request to http://localhost:8080/hello now returns the text "Booking service is running". You wrote no server code, no routing table, and no wiring.

Notice that steps 2 and 3 are different mechanisms. Component scanning finds your own classes, while auto-configuration creates beans for libraries. Many confusing problems in Spring Boot come from mixing up the two.

What Spring Boot Costs

Spring Boot removes setup work, but it has three costs.

• Decisions you did not make. A default can surprise you, such as a timeout or a pool size that nobody chose. To change a default, you must know where it comes from.
• Behavior you cannot see in your files. A bean created by auto-configuration appears in no file you wrote. When something goes wrong, you must know how to ask Spring why a bean exists.
• Startup time and memory. Scanning classes and creating beans takes work. A Spring Boot service starts more slowly and uses more memory than a plain Java program of the same size.

This course reduces the first two costs by explaining each mechanism. You will build a tiny container, a proxy, and an auto-configuration rule in plain Java before you use the real ones.

The Booking Service

The running example is the booking service of an event ticketing app. Venues hold events, events have seats, and customers book seats. The service starts here as one endpoint and, over the course, gains a database, transactions, security, tests, and production monitoring. Its hardest problem appears early: two customers who try to book seat A12 at the same moment.

Key Takeaways

• A backend service holds business code plus preparation work: wiring objects, reading settings, serving HTTP, and managing connections.
• The Spring container creates your objects, called beans, and connects them by reading their constructors.
• Spring Boot adds starters, auto-configuration, an embedded server, and externalized configuration on top of Spring.
• SpringApplication.run creates the container, scans your packages, applies auto-configuration, and starts the server on port 8080 by default.
• Defaults save time, but you must know where each one comes from to change it.

The smallest application fits in two classes, yet a generated project holds more: a build file, a resources folder, and a test. Inside a Spring Boot Project opens each of them.

Practice Questions

1. In the hand-wired program, a developer moves the Notifier line above the EmailSender line. What happens, and why does a Spring application not have this problem?

<details><summary>Show answer</summary>

The program no longer compiles, because the Notifier line uses the variable sender before it is declared. In plain Java, the developer must keep the lines in a working order. The Spring container reads each constructor and builds the dependencies first, so no developer maintains that order.

</details>

2. BookingApplication is in the package com.example.booking. A teammate adds a controller in com.example.web, and its endpoint returns 404 Not Found. What is the likely cause?

<details><summary>Show answer</summary>

Component scanning never found the controller. Scanning starts at the package of the application class and covers only the packages below it, and com.example.web is not below com.example.booking, so the controller never became a bean. Moving it to com.example.booking.web fixes the problem.

</details>

3. A colleague says, "We use Spring Boot, so we no longer use the Spring Framework." Is this correct?

<details><summary>Show answer</summary>

No. Spring Boot is built on top of the Spring Framework and does not replace it. The container, Spring MVC, and transaction support all come from the Spring Framework. Spring Boot chooses library versions, creates beans through auto-configuration, embeds the server, and reads settings from standard places.

</details>

4. The booking service must listen on port 9090 in production, while developers keep port 8080 on their laptops. Does the team need a code change?

<details><summary>Show answer</summary>

No. The port is a setting, not code. Spring Boot reads the port from the server.port property. In production, the team sets the environment variable SERVER_PORT to 9090, and Spring Boot uses that value instead of the default. The same build runs in both places.

</details>