Czym się różni Spring od Spring Boot w typowej aplikacji backendowej

Czym się różni Spring od Spring Boot? Spring to framework i kontener wstrzykiwania zależności, który konfigurujesz samodzielnie. Spring Boot to warstwa na nim: startery, auto-konfiguracja i wbudowany serwer, dzięki którym projekt backendowy stawiasz w kilku minutach, a nie w kilku dniach. Różnica sprowadza się do zakresu odpowiedzialności i ilości konfiguracji, którą piszesz ręcznie.

Jak działa sam Spring, zanim dołożysz Boota

Spring Framework pojawił się w 2003 roku jako odpowiedź na ciężki wtedy Java EE. Daje kontener IoC, wstrzykiwanie zależności, programowanie aspektowe, obsługę transakcji i warstwę webową.

Brzmi dobrze, ale każdy z tych elementów musisz najpierw poskładać. W klasycznym podejściu piszesz plik konfiguracyjny XML albo klasę z adnotacją @Configuration.

Wskazujesz pakiety do skanowania, rejestrujesz beany, ustawiasz DataSource, TransactionManager, DispatcherServlet. Do tego dochodzi plik web.xml, jeśli wdrażasz aplikację na zewnętrznym serwerze.

Zobacz, jak wygląda konfiguracja bez Boota:

@Configuration
@ComponentScan("pl.radoszewski.app")
public class AppConfig {

    @Bean
    public DataSource dataSource() {
        HikariDataSource ds = new HikariDataSource();
        ds.setJdbcUrl("jdbc:postgresql://localhost:5432/mydb");
        ds.setUsername("user");
        ds.setPassword("pass");
        return ds;
    }

    @Bean
    public JdbcTemplate jdbcTemplate(DataSource dataSource) {
        return new JdbcTemplate(dataSource);
    }
}

Musisz też dodać zależności do pom.xml i zadbać o ich wersje. W typowej aplikacji backendowej oznacza to, że zanim napiszesz pierwszy endpoint, mijają godziny. Czasem dni, jeśli walczysz z konfliktami bibliotek. Różnica między Springiem a Spring Bootem zaczyna się właśnie tutaj: w Springu architektura aplikacji jest twoją decyzją i twoją pracą.

Spring to też ekosystem. Spring Data, Spring Security, Spring Cloud, Spring Batch. Każdy projekt konfigurujesz osobno, choć korzystają z tego samego kontenera. Możesz łączyć je w dowolny sposób, ale za każdym razem powtarzasz podobne czynności.

Gdzie w kodzie widać, czym się różni Spring od Spring Boot

Najprościej pokazać to na klasie startowej. W czystym Springu tworzysz kontekst ręcznie:

AnnotationConfigApplicationContext context =
    new AnnotationConfigApplicationContext(AppConfig.class);

W aplikacji webowej konfigurujesz DispatcherServlet i wrzucasz wszystko do XML-a. W Spring Boot cały start wygląda tak:

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

Jedna adnotacja zastępuje trzy: @Configuration, @EnableAutoConfiguration i @ComponentScan. Metoda main uruchamia wbudowany serwer. Nie musisz nic więcej dopisywać, żeby mieć działający endpoint REST. Taki model wdrożenia dobrze łączy się z konteneryzacją, którą wyjaśnia artykuł Docker dla początkujących.

Kontener, który w czystym Springu stawiałeś ręcznie, tutaj startuje automatycznie. Różnica w kodzie nie sprowadza się tylko do liczby adnotacji. W Springu sam decydujesz, kiedy tworzyć kontekst i jak go zamknąć. W Boot kontekst żyje tak długo, jak działa aplikacja, a SpringApplication.run() dodaje obsługę zdarzeń, banner i graceful shutdown.

W pliku pom.xml różnica też rzuca się w oczy. Bez Boota wypisujesz spring-core, spring-web, spring-webmvc, jackson-databind, javax.servlet-api i pilnujesz, żeby wersje do siebie pasowały. Z Bootem dodajesz spring-boot-starter-web i wersjami zajmuje się rodzic. To nie znaczy, że Spring zniknął. Pod spodem działa ten sam kontener, tylko ktoś odciążył cię z konfiguracji. Ta sama adnotacja @Autowired działa identycznie w obu przypadkach.

Jak działa auto-konfiguracja i skąd Boot wie, co włączyć

Auto-konfiguracja sprawia, że Spring Boot zachowuje się jak gospodarz, który przewiduje twoje potrzeby. Przy starcie przegląda classpath i sprawdza warunki. Jeśli widzi spring-boot-starter-web, konfiguruje DispatcherServlet i wbudowany Tomcat. Jeśli widzi sterownik do bazy i spring-boot-starter-data-jpa, tworzy DataSource i EntityManagerFactory. Jeśli widzi H2, ustawia bazę w pamięci.

Wszystko opiera się na adnotacjach warunkowych: @ConditionalOnClass, @ConditionalOnMissingBean, @ConditionalOnProperty. Definicje tych konfiguracji siedzą w plikach META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports. W starszych wersjach był to spring.factories.

Kolejność ma znaczenie. Auto-konfiguracja odpala się po twoich beanach. Jeśli sam zdefiniujesz DataSource, Boot odpuści i nie będzie wchodził ci w drogę. Możesz też wyłączyć wybrane fragmenty przez @EnableAutoConfiguration(exclude = ...) albo właściwość spring.autoconfigure.exclude. To daje kontrolę bez rezygnacji z wygody. W praktyce oznacza to, że Boot dostarcza domyślne zachowanie, ale nie zamyka ci drogi do własnych ustawień.

Możesz napisać własną auto-konfigurację. Wystarczy klasa z @Configuration i wpis w pliku imports. Boot sprawdzi warunki i włączy twoje beany, jeśli aplikacja spełni wymagania. Tak działają biblioteki firm trzecich, które chcą się integrować z Bootem.

Testowanie aplikacji: co się zmienia w praktyce

W czystym Springu testy konfigurujesz ręcznie. Piszesz klasę testową z adnotacjami @RunWith(SpringJUnit4ClassRunner.class) i @ContextConfiguration(classes = AppConfig.class). Musisz wskazać konfigurację, a czasem też nadpisać beany.

W Spring Boot dostajesz gotowe adnotacje. @SpringBootTest uruchamia cały kontekst. @WebMvcTest ładuje tylko warstwę webową z MockMvc. @DataJpaTest stawia bazę H2 i testuje repozytoria.

Te slice testy działają szybciej i nie wymagają ręcznego składania kontekstu. Jeśli testujesz kontroler, nie musisz podnosić całej aplikacji. To oszczędza sekundy, które przy dużym projekcie zamieniają się w minuty.

Serwer wbudowany i model wdrożenia

W czystym Springu aplikację pakujesz do pliku WAR i wrzucasz na zewnętrzny Tomcat, Jetty albo WildFly. Konfigurujesz serwer, ustawiasz pulę wątków, deployujesz.

W Spring Boot domyślnie dostajesz wbudowany Tomcat i plik JAR. Uruchamiasz go komendą java -jar aplikacja.jar. Nie musisz instalować serwera na maszynie. To upraszcza wdrożenia w Dockerze i na Kubernetesie. W polskich firmach, które stawiają mikroserwisy, taki model jest dziś standardem. Ogłoszenia o pracę w Polsce często wymieniają Spring Boot obok Javy, rzadko czysty Spring.

Nie oznacza to, że Boot nie umie w WAR. Możesz ustawić packaging na war i wdrożyć aplikację na zewnętrznym serwerze. Przydaje się to w środowiskach, gdzie administracja narzuca wspólny Tomcat. Wtedy tracisz część zalet wbudowanego serwera, ale zachowujesz auto-konfigurację i startery. Sprawdź, jakie wymagania ma twój zespół operacyjny, zanim wybierzesz model wdrożenia.

Zarządzanie zależnościami i wersjami

Bez Boota sam ustalasz wersje bibliotek. Spring 6 wymaga Javy 17, Hibernate 6, Jackson 2.15. Jeśli pomyślisz się o jedną wersję, dostajesz NoSuchMethodError albo ClassNotFoundException. Debugowanie takiego błędu potrafi zjeść cały dzień. To problem znany także w innych ekosystemach, gdzie trzeba rozwiązać konflikt wersji React 18.

Spring Boot rozwiązuje problem przez parent POM i BOM. Projekt spring-boot-starter-parent dziedziczy po spring-boot-dependencies, gdzie każda biblioteka ma przypisaną wersję. Ty podajesz tylko nazwę startera. Nadpisanie wersji jest możliwe przez , ale robisz to świadomie.

Przykład nadpisania wersji Hibernate:

<properties>
    <hibernate.version>6.4.0.Final</hibernate.version>
</properties>

Startery grupują zależności według funkcji. spring-boot-starter-web ciągnie Spring MVC, Jacksona i Tomcat. spring-boot-starter-test daje JUnit 5, Mockito i AssertJ. spring-boot-starter-security wciąga Spring Security.

Dzięki temu pom.xml jest krótszy i czytelniejszy. W czystym Springu musiałbyś wymienić każdą z tych bibliotek osobno i samodzielnie sprawdzić, czy nie ma konfliktów.

Kiedy zostać przy czystym Springu, a kiedy wybrać Boota

W nowym projekcie backendowym bierz Spring Boota. Nie ma sensu ręcznie kleić konfiguracji, którą Boot robi za darmo. Jeśli chcesz najpierw uporządkować podstawy, zobacz Spring Boot co to jest i dlaczego. Mikroserwisy, REST API, aplikacje z bazą danych, kolejki, security - Boot sprawdza się wszędzie.

Jeśli pracujesz nad starym systemem z konfiguracją XML i nie chcesz rewolucji, możesz zostać przy czystym Springu i migrować moduł po module. Boot pozwala importować stare pliki XML przez @ImportResource, więc przejście nie musi być skokiem na głęboką wodę. Migracja starego projektu na Boota może zająć 2-3 sprinty, jeśli konfiguracja jest rozproszona.

Czasem sam Spring wystarczy. Piszesz bibliotekę, mały batch, narzędzie uruchamiane z linii poleceń. Wtedy wbudowany serwer i auto-konfiguracja to zbędny balast. Zdarzają się też projekty, w których firma ma własny framework oparty na Springu i Boot by mu przeszkadzał.

Zastanawiasz się, czym różni się Spring od Spring Boota w twoim kontekście? Odpowiedz sobie na trzy pytania. Czy chcesz szybko wystartować? Czy zespół zna XML-owy Spring? Czy potrzebujesz wbudowanego serwera?

Odpowiedzi zwykle wskazują kierunek. Zanim podejmiesz decyzję, sprawdź, ile osób w zespole zna czysty Spring. Jeśli połowa projektu stoi na XML-u, nagła migracja może wywołać chaos. Lepiej wprowadzać Boota moduł po module i porównywać czas potrzebny na konfigurację.

Najczęstsze pytania

Czy Spring Boot to framework?

Spring Boot to narzędzie zbudowane na Spring Frameworku. Sam w sobie nie jest osobnym frameworkiem do pisania logiki. Dostarcza konfigurację, startery i wbudowany serwer, żeby szybciej uruchomić aplikację. Pod spodem i tak działa kontener Springa. Możesz go traktować jako zestaw ułatwień, a nie zamiennik.

Czy mogę używać Spring Boot bez Springa?

Nie. Spring Boot nie istnieje bez Spring Frameworka. Każda aplikacja Bootowa tworzy kontekst Springa, używa wstrzykiwania zależności i adnotacji z pakietu org.springframework. Boot tylko opakowuje te mechanizmy i dostarcza domyślne konfiguracje. Nie da się go odciąć od fundamentu.

Czy Spring Boot jest szybszy od Springa?

Wydajność aplikacji w czasie działania jest podobna. Oba przypadki używają tego samego kontenera i tego samego serwera. Różnica leży w czasie developmentu. Boot skraca konfigurację i eliminuje powtarzalne czynności, więc szybciej przechodzisz od pomysłu do działającego kodu. W benchmarkach nie zobaczysz przepaści.

Czy w Spring Boot można pisać konfigurację XML?

Tak, ale to rzadkość. Boot domyślnie stawia na Javę i adnotacje. Jeśli masz stary kontekst XML, możesz go zaimportować przez @ImportResource. W nowych projektach nie ma po co wracać do XML. Właściwie cała idea Boota opiera się na odejściu od ręcznego XML-a.

Co to jest starter w Spring Boot?

Starter to zestaw zależności spakowany pod jedną nazwą. spring-boot-starter-web zawiera Spring MVC, Jacksona i Tomcat. spring-boot-starter-data-jpa zawiera Hibernate i Spring Data JPA. Dodajesz jedną linijkę w pom.xml i masz komplet bibliotek w spójnych wersjach. Startery nie zawierają kodu, tylko opis zależności.

Czy Spring Boot nadaje się do dużych aplikacji?

Tak. Wiele dużych systemów w Polsce i na świecie działa na Spring Boot. Auto-konfiguracja nie przeszkadza w skalowaniu, bo można ją nadpisać. Boot wspiera mikroserwisy, moduły, kolejki i bazy danych. Ograniczeniem jest raczej architektura, którą wybierzesz, a nie sam Boot.