🚀 Продвинутый совет по Spring Boot 🚀

Используй ApplicationPidFileWriter, чтобы при старте приложения записывать его PID в файл.
Это удобно для ops-скриптов, health-checks в контейнерах и мониторинга процессов. 🔥

👉 Документация: https://docs.spring.io/spring-boot/api/java/org/springframework/boot/context/ApplicationPidFileWriter.html

#SpringBoot #Java #DevOps

💡 Полезный совет для Spring Boot

Если клиент прислал в JSON лишние поля, а вы их не используете — приложение может упасть при десериализации.

Чтобы такого не было, добавьте к DTO аннотацию:

@JsonIgnoreProperties(ignoreUnknown = true)

Тогда лишние поля просто игнорируются, и API продолжает работать без ошибок. Удобно при обновлении контрактов и поддержке разных версий клиентов.

#SpringBoot #Java #Backend #SoftwareEngineering

💡 Spring Boot совет

Используйте @Profile, чтобы загружать разные бины и конфигурации под разные окружения.
Например: dev для локальной разработки, prod для боевого режима, test для автотестов.

Так код остаётся чистым, а переключение окружений занимает секунды.

Пример:

@Profile("dev")
@Configuration
class DevConfig { ... }

@Profile("prod")
@Configuration
class ProdConfig { ... }

Запуск с профилем:
java -jar app.jar --spring.profiles.active=prod

Гибкость без if-ов и лишней логики в коде.
#SpringBoot #JavaDev

@javatg

🚀 Spring Boot Pro Tip: свой FailureAnalyzer

В Spring Boot можно перехватывать ошибки на этапе запуска и превращать их в понятные человеку сообщения. Для этого создан механизм FailureAnalyzer.

Зачем он нужен
- улучшает диагностику на старте приложения
- помогает быстро находить причины конфигурационных ошибок
- делает логирование чище и понятнее

Как работает
Вы создаёте свой класс, который анализирует исключение и возвращает читаемое описание проблемы и советы по исправлению.

Под капотом Spring Boot автоматически подцепит ваш анализатор и покажет дружелюбное сообщение вместо сырого stacktrace.

Документация:
https://docs.spring.io/spring-boot/how-to/application.html#howto.application.failure-analyzer

#SpringBoot #Java #FailureAnalyzer #Backend #DevTips

🚀 В Spring Boot можно точечно отключать ненужную автоконфигурацию через аннотацию
**@SpringBootApplication(exclude = …)**.

Это удобно, когда в проекте есть своя кастомная конфигурация, которая конфликтует с дефолтной, или когда вы хотите убрать лишние автоматические настройки и контролировать поведение вручную.

Так вы оставляете только нужные части автоконфигурации и избегаете скрытых конфликтов.

#SpringBoot #JavaDev

⚡️ Совет по Spring Boot

💡 Если нужно написать интеграционные тесты для Spring MVC-контроллеров и замокать всё остальное — используй @WebMvcTest.
Эта аннотация поднимает только MVC-слой (контроллеры, маппинг, валидацию), не загружая весь контекст приложения.

Это делает тесты быстрее, чище и проще.

#SpringBoot #JavaDev

🚫 Spring Boot: избегай FetchType.EAGER, если это не жизненно необходимо

Когда ты помечаешь связь как EAGER, ORM будет загружать её КАЖДЫЙ раз при загрузке сущности, даже если тебе эти данные вообще не нужны.

Что это значит на практике:

❌ Ты загружаешь Order - автоматически тянется и Customer
❌ Даже если ты не обращаешься к customer в коде
❌ Растёт объём данных, время запроса и нагрузка на БД

А дальше классика жанра — N+1 проблема:

1 запрос - получить список всех Orders
+ N запросов - получить Customer для каждого Order

И всё, производительность улетела.

EAGER кажется удобным, но это скрытая ловушка.
Гораздо безопаснее по умолчанию использовать LAZY и явно управлять загрузкой через JOIN FETCH, EntityGraph или DTO-проекции.

Контроль > магия.
#SpringBoot #Java #Backend

@javatg

🚀 Spring Boot: хочешь, чтобы Jackson создавал объекты из JSON явно и предсказуемо - используй @JsonCreator.

Почему это важно:
🟢 Jackson не “угадывает”, какой конструктор использовать
🟢 Каждый параметр жёстко привязан к полю JSON через @JsonProperty
🟢 Меньше магии - меньше багов при рефакторинге

Идеально для immutable-классов (`final` поля) и DTO.

@javatg

#SpringBoot #JavaDev

🚀 Spring совет: таймауты RestTemplate лучше настраивать централизованно

Если в проекте много REST-запросов через RestTemplate, не разбрасывай таймауты по коду.

✅ Правильнее сделать конфигурацию через RestTemplateBuilder:

- один общий RestTemplate с дефолтными timeout
- плюс отдельные клиенты под “медленные” сервисы (через `@Qualifier`)

Так у тебя:
- единая точка настройки
- меньше багов в проде из-за “вечных” запросов
- проще дебажить и менять параметры

💡 Особенно полезно в микросервисах, где внешние сервисы могут подвисать.

#SpringBoot #JavaDev

⚡ Spring Boot: как отключить лишнюю авто-конфигурацию

Иногда Spring Boot запускает больше, чем вам нужно.

Если у вас:
- кастомная конфигурация
- конфликт с дефолтными настройками
- ошибки при старте DataSource или JPA
— проблема может быть в auto-configuration.

Решение — отключить ненужные модули через @SpringBootApplication.

Пример:

@SpringBootApplication(
    exclude = {
        DataSourceAutoConfiguration.class,
        HibernateJpaAutoConfiguration.class
    }
)
public class MyApplication {
    public static void main(String[] args) {
        SpringApplication.run(MyApplication.class, args);
    }
}

Когда это полезно:

• вы используете свою конфигурацию базы
• приложение не работает с БД, но зависимости есть
• тестовые или lightweight-сервисы
• миграция старого проекта

Spring Boot умный.
Но иногда ему нужно сказать: “не делай это за меня”.

#SpringBoot #Java #Backend

⚡️ Spring Boot: полный контроль над HTTP-ответами через ResponseEntity

Если нужно управлять не только телом ответа, но и статусом и заголовками — используйте ResponseEntity.

Что это даёт:
- Явно задаёте HTTP-статус (200, 404, 201 и т.д.)
- Добавляете кастомные заголовки
- Возвращаете любой объект в body
- Контролируете поведение API на уровне протокола

Пример:

@GetMapping("/users/{id}")
public ResponseEntity<User> getUser(@PathVariable Long id) {
    User user = userService.findById(id);

    if (user == null) {
        return ResponseEntity.status(HttpStatus.NOT_FOUND).build();
    }

    return ResponseEntity
            .status(HttpStatus.OK)
            .header("Custom-Header", "UserFound")
            .body(user);
}

• разные статусы для разных сценариев (404, 400, 204)

• REST API с чёткой семантикой
• добавление headers (pagination, tokens, meta)
• возврат пустого ответа без body

Совет:
Если метод просто возвращает данные - достаточно вернуть объект.
Если нужен контроль над HTTP - всегда ResponseEntity.

@javatg

#SpringBoot #Java #Backend #SoftwareEngineering

🚀 Spring Boot: не отдавайте JPA Entity напрямую в API - используйте DTO на границах

Если возвращать Entity из контроллера, вы жёстко связываете API с внутренней моделью базы. Любое изменение в persistence-слое может сломать внешний контракт.

DTO решает сразу несколько проблем:

• API становится независимым от слоя данных
• Избегаете ошибок LazyInitializationException
• Не утечёт лишняя информация (например, password, internalNote)
• Улучшается безопасность и контроль над тем, что видит клиент

Идея простая:
Entity - для базы
DTO - для API

Конвертируйте Entity → DTO в сервисе или через mapper (MapStruct / manual mapping).

Чистые границы = стабильный API и меньше багов.

#SpringBoot #Java #Backend #SoftwareEngineer

🚀 Ускоряем Spring Boot без изменения кода

Многие приложения тормозят не из-за бизнес-логики, а из-за логирования.
Каждый лог - это I/O операция. При высокой нагрузке это становится узким местом.

Решение - асинхронное логирование через Logback.

Что происходит:
- сообщения складываются в очередь
- отдельный поток обрабатывает их в фоне
- основной поток не блокируется
- меньше задержек и выше throughput

Настройка проста - добавьте logback-spring.xml в:
src/main/resources/

Пример конфигурации:

<configuration>

    <!-- Async wrapper -->
    <appender name="ASYNC_CONSOLE"
              class="ch.qos.logback.classic.AsyncAppender">
        <appender-ref ref="CONSOLE"/>
        <queueSize>5000</queueSize>
        <discardingThreshold>0</discardingThreshold>
        <includeCallerData>false</includeCallerData>
    </appender>

    <!-- Console appender -->
    <appender name="CONSOLE"
              class="ch.qos.logback.core.ConsoleAppender">
        <encoder>
            <pattern>
%d{yyyy-MM-dd HH:mm:ss} %-5level [%thread] %logger - %msg%n
            </pattern>
        </encoder>
    </appender>

    <root level="INFO">
        <appender-ref ref="ASYNC_CONSOLE"/>
    </root>

</configuration>

Когда это особенно полезно:

• high-load сервисы
• микросервисы с большим количеством логов
• API с высокой RPS
• продакшен-окружение

⚠️ Важно: при аварийном завершении часть логов из очереди может потеряться. Для критичных логов используйте файл + async.

Маленькая настройка - большой прирост производительности.

#SpringBoot #Java #Backend #Performance

⚠️ Spring Boot: не включайте publish-request-params в production

В Spring Boot есть настройка:

spring.mvc.publish-request-params=true

Она включает логирование параметров HTTP-запросов.

Это удобно в dev-среде, потому что можно видеть:

• request headers
• query parameters
• form data

Обычно это используют вместе с фильтром:

@Bean
public CommonsRequestLoggingFilter logFilter() {
    CommonsRequestLoggingFilter filter = new CommonsRequestLoggingFilter();
    filter.setIncludeQueryString(true);
    filter.setIncludeHeaders(true);
    filter.setIncludePayload(true);
    filter.setMaxPayloadLength(1000);
    filter.setAfterMessagePrefix("COMPLETE REQUEST: ");
    return filter;
}

Но есть важная проблема.

В production такие логи могут случайно сохранить чувствительные данные пользователей.

Например:

POST /login
{
  "username": "john",
  "password": "mypassword"
}

Если включено логирование payload, такие данные могут попасть в:

• application logs
• log-агрегаторы
• мониторинг системы

А это уже серьёзная уязвимость безопасности.

Поэтому правило простое:
- включайте publish-request-params только в dev
- никогда не логируйте request body в production
- маскируйте чувствительные поля (`password`, token, `authorization`)

Маленькая настройка -
но может привести к утечке данных.

#SpringBoot #Java #Backend #Security

⚠️ Маленькая настройка в Spring Boot, которая может спасти от скрытых багов.

Лучше не менять значение по умолчанию:

spring.main.allow-bean-definition-overriding=false

Что это делает?
Если в приложении два бина с одинаковым именем, Spring не запустится.

И это на самом деле хорошо.

Почему:
✔ помогает сразу увидеть конфликт конфигурации
✔ не даёт одному бину тихо перезаписать другой
✔ предотвращает скрытые баги в DI

Если же включить:

spring.main.allow-bean-definition-overriding=true

• тогда второй бин молча перезапишет первый.

В результате приложение запустится, но будет использовать не тот бин, который вы ожидали.

И такие баги потом очень сложно найти.

Иногда лучше получить ошибку при старте, чем искать проблему в продакшене.

#SpringBoot #Java #Backend

⚡️ Полезные ресурсы по Java 🚀 Max

@javatg

⚠️ Spring Boot ошибка, которую делают почти все

Большинство просто добавляет:

spring-boot-starter-web
и не думает дальше.

Но вот в чём проблема 👇

Этот стартер тянет за собой:

- встроенный сервер (Tomcat)
- лишние зависимости
- ненужный overhead

👉 даже если тебе нужен только MVC

💡 Правильный подход:

Если тебе нужен только Spring MVC —
используй:

spring-boot-starter-webmvc

Что это даёт:

• 📦 меньше зависимостей
• ⚡ быстрее запуск
• 🧹 чище архитектура
• 💸 меньше ресурсов

🔥 Когда это критично

- микросервисы
- serverless
- high-load системы
- оптимизация старта

🧠 Инсайт

Чем меньше лишнего ты тащишь в проект
→ тем проще его поддерживать

👉 Не ставь "на всякий случай"
Ставь только то, что реально нужно

#springboot #java

⚡️ Полезные ресурсы по Java 🚀 Max

@javatg

🍃 Spring Boot 4: проверьте зависимости Flyway и Liquibase

После обновления одной зависимости flyway-core или liquibase-core недостаточно для автоконфигурации миграций. В Spring Boot 4 поддержку технологий вынесли в отдельные модули.

Используйте соответствующий стартер:

* Flyway → spring-boot-starter-flyway
* Liquibase → spring-boot-starter-liquibase

Для тестов, включая test slices:

* spring-boot-starter-flyway-test
* spring-boot-starter-liquibase-test

Все перечисленные зависимости относятся к группе org.springframework.boot. Тестовые стартеры добавляются с областью test в Maven или через testImplementation в Gradle.

Руководство по миграции: https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-4.0-Migration-Guide#module-dependencies

#SpringBoot #Java #Flyway

🍃 Не раскладывайте весь Spring-проект по папкам controller, service и repository.

В новом This Week in Spring Джош Лонг советует группировать код по функциональности, используя подход Spring Modulith. Например, orders, payments, users, внутри которых находятся относящиеся к ним слои.

Ещё в подборке:

• JobRunr 9: поиск упавшего шага и задач, вызывающих замедление, остановка выполнения без потери работы.
• Spring AI: разбор агентных паттернов и вызова инструментов от руководителя проекта Кристиана Цолова.
• Progen CLI: видео о генерации каркаса приложения.
• IntelliJ IDEA: обзор новых возможностей.
• A Bootiful Podcast: разговор с создателем Jenkins Косуке Кавагути.

https://spring.io/blog/2026/10/13/this-week-in-spring-october-13th-2026

#Java #SpringBoot