Spring Boot YAML vs Properties: Porównanie Konfiguracji i Pytania Rekrutacyjne 2026

Spring Boot obsługuje dwa formaty konfiguracji: YAML (application.yml) oraz Properties (application.properties). Oba osiągają ten sam cel, jednak różnią się składnią, czytelnością i zastosowaniami w konkretnych przypadkach. Niniejsze porównanie przedstawia praktyczne różnice oraz omawia pytania rekrutacyjne dotyczące zewnętrznej konfiguracji Spring Boot.

Porównanie Składni YAML i Properties

Najbardziej widoczna różnica dotyczy sposobu reprezentacji danych hierarchicznych. Pliki Properties używają notacji kropkowej w każdej linii, podczas gdy YAML wykorzystuje wcięcia do wyrażania zagnieżdżenia.

# application.properties
server.port=8080
server.servlet.context-path=/api
spring.datasource.url=jdbc:postgresql://localhost:5432/mydb
spring.datasource.username=admin
spring.datasource.password=${DB_PASSWORD}
spring.jpa.hibernate.ddl-auto=validate
spring.jpa.show-sql=false

Równoważna konfiguracja YAML grupuje powiązane ustawienia wizualnie:

# application.yml
server:
  port: 8080
  servlet:
    context-path: /api

spring:
  datasource:
    url: jdbc:postgresql://localhost:5432/mydb
    username: admin
    password: ${DB_PASSWORD}
  jpa:
    hibernate:
      ddl-auto: validate
    show-sql: false

YAML redukuje powtórzenia, gdy wiele właściwości dzieli ten sam prefiks. W pliku properties spring.datasource pojawia się trzykrotnie, podczas gdy YAML deklaruje go jednokrotnie.

Zarządzanie Profilami w Konfiguracji Spring Boot

Profile Spring Boot umożliwiają różne konfiguracje dla środowisk deweloperskich, staging i produkcyjnych. Oba formaty wspierają profile, jednak YAML obsługuje je bardziej elegancko.

W przypadku plików properties wymagane są osobne pliki dla każdego profilu:

# application-dev.properties
server.port=8080
spring.datasource.url=jdbc:h2:mem:devdb
logging.level.root=DEBUG

# application-prod.properties
server.port=80
spring.datasource.url=jdbc:postgresql://prod-server:5432/proddb
logging.level.root=WARN

YAML wspiera składnię wielu dokumentów w pojedynczym pliku przy użyciu separatora ---:

# application.yml
spring:
  profiles:
    active: dev

---
spring:
  config:
    activate:
      on-profile: dev
server:
  port: 8080
logging:
  level:
    root: DEBUG

---
spring:
  config:
    activate:
      on-profile: prod
server:
  port: 80
logging:
  level:
    root: WARN

Od Spring Boot 2.4 właściwość spring.config.activate.on-profile zastąpiła starszą składnię spring.profiles. Dokumentacja Spring Boot szczegółowo opisuje aktywację profili.

Listy i Złożone Struktury Danych

YAML doskonale radzi sobie z reprezentacją list i zagnieżdżonych struktur. Ma to znaczenie przy konfiguracjach reguł bezpieczeństwa, mapowań CORS czy niestandardowych beanów.

# application.yml
app:
  security:
    allowed-origins:
      - https://sharpskill.dev
      - https://api.sharpskill.dev
    cors:
      allowed-methods:
        - GET
        - POST
        - PUT
        - DELETE
    jwt:
      secret: ${JWT_SECRET}
      expiration-ms: 86400000

Odpowiednik w properties wymaga notacji indeksowej:

# application.properties
app.security.allowed-origins[0]=https://sharpskill.dev
app.security.allowed-origins[1]=https://api.sharpskill.dev
app.security.cors.allowed-methods[0]=GET
app.security.cors.allowed-methods[1]=POST
app.security.cors.allowed-methods[2]=PUT
app.security.cors.allowed-methods[3]=DELETE
app.security.jwt.secret=${JWT_SECRET}
app.security.jwt.expiration-ms=86400000

Dodanie nowego origin w pliku YAML oznacza dopisanie linii. W properties każdy istniejący indeks musi pozostać poprawny, a nowy wpis wymaga kolejnego numeru indeksu.

Typowo-Bezpieczna Konfiguracja z @ConfigurationProperties

Spring Boot 3.4 wiąże wartości konfiguracyjne z klasami Java poprzez @ConfigurationProperties. Oba formaty działają identycznie z tą adnotacją.

import org.springframework.boot.context.properties.ConfigurationProperties;
import java.util.List;

@ConfigurationProperties(prefix = "app.security")
public record AppSecurityProperties(
    List<String> allowedOrigins,
    CorsConfig cors,
    JwtConfig jwt
) {
    public record CorsConfig(List<String> allowedMethods) {}
    public record JwtConfig(String secret, long expirationMs) {}
}

Swobodne wiązanie Spring Boot automatycznie konwertuje między różnymi konwencjami nazewnictwa. Właściwość app.security.allowed-origins wiąże się z allowedOrigins niezależnie od tego, czy źródłem jest YAML czy properties.

import org.springframework.context.annotation.Configuration;
import org.springframework.boot.context.properties.EnableConfigurationProperties;

@Configuration
@EnableConfigurationProperties(AppSecurityProperties.class)
public class SecurityConfig {
    
    private final AppSecurityProperties securityProperties;
    
    public SecurityConfig(AppSecurityProperties securityProperties) {
        this.securityProperties = securityProperties;
    }
    
    // Konfiguracja CORS wykorzystująca securityProperties.cors().allowedMethods()
}

Więcej informacji o wzorcach konfiguracji Spring Security znajduje się w module podstaw Spring Security.

Najczęstsze Pytania Rekrutacyjne o Konfigurację Spring Boot

Konfiguracja jest częstym tematem na rozmowach rekrutacyjnych Spring Boot. Rekruterzy oceniają zrozumienie zewnętrznej konfiguracji, ustawień specyficznych dla środowiska oraz wiązania właściwości.

Pytanie: Jaka jest kolejność pierwszeństwa źródeł konfiguracji?

Spring Boot ładuje konfigurację z wielu źródeł w określonej kolejności. Źródła o wyższym priorytecie nadpisują te o niższym:

1. Argumenty wiersza poleceń (--server.port=9000)
2. Właściwości systemowe Java (-Dserver.port=9000)
3. Zmienne środowiskowe systemu operacyjnego (SERVER_PORT=9000)
4. Właściwości specyficzne dla profilu (application-{profile}.yml)
5. Właściwości aplikacji (application.yml lub application.properties)
6. Adnotacje @PropertySource
7. Domyślne właściwości przez SpringApplication.setDefaultProperties

Kandydat znający tę kolejność demonstruje zrozumienie sposobu rozwiązywania konfliktowych wartości przez Spring Boot.

Pytanie: Kiedy wybrać properties zamiast YAML?

Pliki properties mają przewagę w określonych sytuacjach:

• Wsparcie IDE: Niektóre starsze IDE zapewniają lepsze autouzupełnianie dla plików .properties
• Znajomość w zespole: Składnia properties jest prostsza dla programistów nowych w Spring Boot
• Wartości jednoliniowe: Płaskie konfiguracje bez zagnieżdżenia nic nie zyskują na YAML
• Integracja z narzędziami budowania: Filtrowanie zasobów Maven i Gradle działa bezpośrednio z properties

YAML sprawdza się lepiej gdy:

• Konfiguracja ma głębokie zagnieżdżenie (trzy lub więcej poziomów)
• Wiele profili należy do jednego pliku
• Listy wymagają częstych modyfikacji
• Czytelność ma znaczenie przy złożonych konfiguracjach

Pytanie: Jak obsługiwać wrażliwe wartości konfiguracyjne?

Nigdy nie należy commitować sekretów do kontroli wersji. Spring Boot oferuje kilka podejść:

# application.yml - odwołanie do zmiennej środowiskowej
spring:
  datasource:
    password: ${DB_PASSWORD}

Dla systemów produkcyjnych Spring Cloud Config Server lub HashiCorp Vault zapewniają scentralizowane zarządzanie sekretami. Przewodnik monitorowania Actuator omawia zabezpieczanie wrażliwych endpointów.

Walidacja Konfiguracji w Spring Boot 3.4

Spring Boot waliduje klasy @ConfigurationProperties podczas uruchamiania w połączeniu z adnotacjami Jakarta Bean Validation.

import jakarta.validation.constraints.NotBlank;
import jakarta.validation.constraints.Positive;
import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.validation.annotation.Validated;

@Validated
@ConfigurationProperties(prefix = "app.database")
public record DatabaseProperties(
    @NotBlank String url,
    @NotBlank String username,
    @Positive int poolSize
) {}

Jeśli app.database.pool-size brakuje lub jest ujemne, aplikacja szybko kończy działanie podczas uruchamiania z czytelnym komunikatem błędu. Ta walidacja działa identycznie dla źródeł YAML i properties.

Pliki Konfiguracyjne Specyficzne dla Środowiska

Spring Boot 3.4 wspiera dodatkowe lokalizacje plików konfiguracyjnych poza domyślnym src/main/resources. Właściwość spring.config.import ładuje zewnętrzne pliki:

# application.yml
spring:
  config:
    import:
      - optional:file:./config/
      - optional:configserver:http://config-server:8888

Prefiks optional: zapobiega błędowi uruchamiania gdy plik nie istnieje. Ten wzorzec umożliwia lokalne programowanie z domyślnymi wartościami, podczas gdy produkcja pobiera konfigurację z centralnego serwera.

Kluczowe Wnioski dla Konfiguracji Spring Boot

• YAML redukuje powtórzenia dla konfiguracji ze współdzielonymi prefiksami i obsługuje listy bardziej przejrzyście
• Pliki properties sprawdzają się przy płaskich konfiguracjach i w zespołach mniej zaznajomionych ze składnią YAML
• Spring Boot 3.4 traktuje oba formaty równoważnie dla wiązania i walidacji @ConfigurationProperties
• Zarządzanie profilami w YAML utrzymuje powiązane środowiska w jednym pliku, redukując rozproszenie plików
• Pierwszeństwo konfiguracji podlega określonej kolejności: argumenty wiersza poleceń nadpisują zmienne środowiskowe, które nadpisują konfigurację z plików
• Wrażliwe wartości należą do zmiennych środowiskowych lub systemów zarządzania sekretami, nigdy do plików w kontroli wersji
• Użycie spring.config.import umożliwia ładowanie konfiguracji z zewnętrznych źródeł w środowiskach produkcyjnych