🍃 Розділ 5 · Питання #22

Що таке стартер в Spring Boot

Щоб запустити найпростіший REST-контролер із підтримкою JSON, розробник повинен був вручну знайти та прописати в pom.xml понад 10 бібліотек: spring-web, spring-webmvc, jackson-d...

🍃 Spring Spring Boot 📄 Вихідний Markdown

🟢 Junior Level

Starter (стартер) у Spring Boot — це спеціальний агрегуючий дескриптор залежностей (шаблонний набір бібліотек), який дозволяє одним рядком у pom.xml або build.gradle підключити всю необхідну функціональність для вирішення конкретного технологічного завдання.

Проблема, яку вирішує Starter

До появи стартерів (Класичний Spring): Щоб запустити найпростіший REST-контролер із підтримкою JSON, розробник повинен був вручну знайти та прописати в pom.xml понад 10 бібліотек: spring-web, spring-webmvc, jackson-databind, jackson-core, tomcat-embed-core, hibernate-validator і вручну стежити за їхньою сумісністю версій (ризик потрапити в так зване пекло залежностей — Jar Hell).

У Spring Boot зі стартером: Достатньо підключити один артефакт:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

Spring Boot автоматично підтягне всі транзитивні залежності протестованих та гарантовано сумісних версій.

Популярні стандартні стартери

  • spring-boot-starter-web — розробка REST API та вебдодатків (включає Spring MVC, Jackson та вбудований Tomcat).
  • spring-boot-starter-data-jpa — робота з базами даних (Spring Data JPA, Hibernate, HikariCP).
  • spring-boot-starter-security — автентифікація та авторизація (Spring Security).
  • spring-boot-starter-validation — валідація параметрів та DTO (Hibernate Validator, специфікація Jakarta Validation).
  • spring-boot-starter-test — модульне та інтеграційне тестування (JUnit 5, Mockito, AssertJ, Hamcrest, Spring Test).

🟡 Middle Level

Правила іменування стартерів (Naming Convention)

Команда Spring встановила сувору угоду щодо іменування артефактів:

Офіційні стартери від Spring / VMware:
    spring-boot-starter-{name}
    Приклад: spring-boot-starter-data-redis, spring-boot-starter-amqp

Сторонні та корпоративні стартери (Open Source, компанії):
    {name}-spring-boot-starter
    Приклад: mybatis-spring-boot-starter, grpc-spring-boot-starter, company-audit-spring-boot-starter

Важливо: Стороннім розробникам заборонено починати назву артефакту зі spring-boot-starter-*, оскільки цей префікс зарезервовано для офіційного дерева модулів Spring.

Управління версіями: BOM (Bill of Materials)

Стартери не містять номерів версій у коді проєкту, якщо проєкт підключений до BOM:

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>3.2.0</version>
</parent>

Батьківський POM транзитивно успадковує spring-boot-dependencies — спеціальний POM-файл без коду, у секції <dependencyManagement> якого жорстко зафіксовані узгоджені версії сотень сторонніх бібліотек (SLF4J, PostgreSQL, Hibernate, Netty, Jackson).

Як використовувати Spring Boot без spring-boot-starter-parent

Якщо в проєкті вже є корпоративний <parent>, BOM підключається через scope=import:

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-dependencies</artifactId>
            <version>3.2.0</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

🔴 Senior Level

Канонічна архітектура кастомного стартера: Двомодульний патерн

За офіційним гайдом розробки Spring Boot промисловий стартер повинен розділятися на два модулі:

                       ┌───────────────────────────────────────────────┐
                       │          mycompany-spring-boot-starter        │
                       │           (Порожній «парасольковий» артефакт) │
                       └───────────────────────┬───────────────────────┘
                                               │ транзитивно тягне
                                               ▼
          ┌─────────────────────────────────────┴─────────────────────────────────────┐
          ▼                                                                           ▼
┌─────────────────────────────────┐                         ┌─────────────────────────────────┐
│ mycompany-spring-boot-          │                         │          mycompany-core         │
│ autoconfigure                   │                         │  (Чистий Java SDK/клієнт        │
│ (Автоконфігурація, умови,        │                         │   без прив'язки до Spring Boot) │
│  @AutoConfiguration, BPP)       │                         └─────────────────────────────────┘
└─────────────────────────────────┘
  1. mycompany-core: бізнес-бібліотека (SDK, клієнти мережевих протоколів, допоміжні класи). Вона не повинна залежати від Spring Boot, щоб її могли використовувати розробники класичних Java/Kotlin-додатків.
  2. mycompany-spring-boot-autoconfigure: містить класи автоконфігурації (@AutoConfiguration), класи конфігураційних властивостей (@ConfigurationProperties) та умовні анотації (@ConditionalOnClass).
  3. mycompany-spring-boot-starter: порожній POM-модуль, який просто об’єднує залежності на core та autoconfigure. Саме його підключає кінцевий користувач.

Реалізація автоконфігурації в Spring Boot 3.x

  1. Клас властивостей конфігурації: ```java package com.mycompany.starter.properties;

import org.springframework.boot.context.properties.ConfigurationProperties;

@ConfigurationProperties(prefix = “mycompany.client”) public class MyCompanyProperties { private String apiKey; private int timeoutMs = 3000; private boolean enabled = true;

// гетери та сетери
public String getApiKey() { return apiKey; }
public void setApiKey(String apiKey) { this.apiKey = apiKey; }
public int getTimeoutMs() { return timeoutMs; }
public void setTimeoutMs(int timeoutMs) { this.timeoutMs = timeoutMs; }
public boolean isEnabled() { return enabled; }
public void setEnabled(boolean enabled) { this.enabled = enabled; } } ```
  1. Клас автоконфігурації (@AutoConfiguration): ```java package com.mycompany.starter.autoconfigure;

import com.mycompany.core.MyClient; import com.mycompany.starter.properties.MyCompanyProperties; import org.springframework.boot.autoconfigure.AutoConfiguration; import org.springframework.boot.autoconfigure.condition.ConditionalOnClass; import org.springframework.boot.autoconfigure.condition.ConditionalOnMissingBean; import org.springframework.boot.autoconfigure.condition.ConditionalOnProperty; import org.springframework.boot.context.properties.EnableConfigurationProperties; import org.springframework.context.annotation.Bean;

@AutoConfiguration @ConditionalOnClass(MyClient.class) @EnableConfigurationProperties(MyCompanyProperties.class) @ConditionalOnProperty(prefix = “mycompany.client”, name = “enabled”, havingValue = “true”, matchIfMissing = true) public class MyCompanyAutoConfiguration {

@Bean
@ConditionalOnMissingBean
public MyClient myClient(MyCompanyProperties properties) {
    return new MyClient(properties.getApiKey(), properties.getTimeoutMs());
} } ```
  1. Реєстрація в реєстрі Spring Boot 3: Створюється файл src/main/resources/META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports: 
    com.mycompany.starter.autoconfigure.MyCompanyAutoConfiguration

Генерація метаданих для IDE автодоповнення

Щоб у файлах application.yml кінцевих користувачів працювало автодоповнення властивостей стартера (з описами та підказками типів), до модуля автоконфігурації підключають процесор анотацій:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-configuration-processor</artifactId>
    <optional>true</optional>
</dependency>

Під час компіляції процесор генерує файл META-INF/spring-configuration-metadata.json, який розпізнається IntelliJ IDEA та VS Code.

🎯 Шпаргалка для інтерв’ю

30-секундна відповідь

Starter у Spring Boot — це агрегуючий модуль залежностей, що вирішує проблему збирання та сумісності бібліотек для конкретного завдання (Web, JPA, Security).

  • Усуває проблему Jar Hell завдяки синхронізації версій через BOM (spring-boot-dependencies).
  • Включає набір транзитивних бібліотек та модуль автоконфігурації (*-autoconfigure).
  • Іменування: офіційні стартери іменуються суворо spring-boot-starter-*, а сторонні та корпоративні — *-spring-boot-starter.
  • За канонічним стандартом стартер будується за двомодульним патерном: чистий Java-клієнт + модуль автоконфігурації з реєстрацією в .imports-файлі.

4 каверзних питання з відповідями

  1. Чому промисловий стартер рекомендується ділити на два модулі (autoconfigure та starter)? Відповідь: Модуль autoconfigure містить усі біни, анотації та умови Spring Boot. Модуль starter — це порожній артефакт, що об’єднує залежності. Такий поділ дозволяє підключати модуль базової бібліотеки (core) у проєкти, де не використовується Spring Boot (наприклад, мікросервіси на Micronaut, Quarkus або звичайні консольні утиліти), не змушуючи їх тягнути транзитивні залежності Spring.

  2. Як використовувати управління версіями Spring Boot, якщо проєкт не може успадковуватися від spring-boot-starter-parent? Відповідь: Через секцію <dependencyManagement> у pom.xml, імпортувавши артефакт spring-boot-dependencies з атрибутами <type>pom</type> та <scope>import</scope>. Це дозволяє перевизначити батьківський POM на корпоративний, зберігши централізоване керування версіями Spring Boot.

  3. Чому офіційні стартери називаються spring-boot-starter-*, а сторонні *-spring-boot-starter? Відповідь: Це сувора угода щодо іменування Spring Boot. Префікс spring-boot-starter-* зарезервовано для офіційної команди Spring Framework / VMware. Сторонні бібліотеки (наприклад, mybatis-spring-boot-starter, camel-spring-boot-starter) зобов’язані використовувати постфікс, щоб користувачі легко відрізняли офіційні компоненти екосистеми від сторонніх.

  4. Навіщо в стартер підключають spring-boot-configuration-processor? Відповідь: Цей анотаційний процесор аналізує класи з @ConfigurationProperties під час компіляції та генерує JSON-маніфест META-INF/spring-configuration-metadata.json. На основі цього файлу IDE (IntelliJ IDEA, Eclipse) забезпечують підсвічування, перевірку типів та автодоповнення параметрів стартера в application.properties та application.yml.

Червоні прапорці (чого категорично не можна говорити)

  • ❌ «Стартер — це звичайний JAR-файл, що містить лише скомпільовані класи логіки» — стартер у першу чергу агрегує залежності та запускає автоконфігурацію.
  • ❌ «У своєму проєкті можна назвати стартер spring-boot-starter-mycompany» — порушення конвенції іменування; назва має бути mycompany-spring-boot-starter.
  • ❌ «Стартери жорстко прив’язують номери версій до кожної транзитивної бібліотеки всередині pom.xml проєкту» — версіями керує централізований BOM (spring-boot-dependencies).
  • ❌ «У Spring Boot 3 для реєстрації стартера все ще використовується spring.factories» — у Boot 3.x автоконфігурації реєструються у файлі META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports.

Пов’язані теми