Spring Boot: для новых приложений выбирайте WebClient вместо RestTemplate

~ Реактивный и неблокирующий
~ Работает на event-loop, а не на модели один поток на запрос
~ Отлично подходит для микросервисной архитектуры

❌ RestTemplate (blocking)

@Service
public class ItemService {

    private final RestTemplate restTemplate;

    public ItemService(RestTemplate restTemplate) {
        this.restTemplate = restTemplate;
    }

    public Item getItem(Long id) {
        return restTemplate.getForObject(
            "https://api.example.com/items/{id}",
            Item.class,
            id
        );
    }
}

✅ WebClient (non-blocking)

@Service
public class ItemService {

    private final WebClient webClient;

    public ItemService(WebClient webClient) {
        this.webClient = webClient;
    }

    public Mono<Item> getItem(Long id) {
        return webClient.get()
            .uri("/items/{id}", id)
            .retrieve()
            .bodyToMono(Item.class);
    }
}

👉 Java Portal

Если у тебя Spring Boot приложение подключено как вложенный модуль и оно использует поддержку Docker Compose, то в IntelliJ IDEA нужно задать MODULE_WORKING_DIRECTORY, чтобы среда смогла корректно определить, где лежит файл compose.yaml.

👉 Java Portal

⭐️ Road To Highload: Крупноблочная архитектура

В видеопроекте Road to Highload Сергей Трегуб, руководитель бэкенд‑разработки продуктовых сервисов Яндекс 360, рассказывает, как крупноблочная архитектура упрощает коммуникацию между разными командами разработки и помогает быстро принимать решения: в каком компоненте разместить новую бизнес‑логику и какие дополнительные блоки потребуются для её поддержки.

Road to Highload — это цикл видеоматериалов от Яндекс 360 о том, как строятся системы, которыми ежедневно пользуются миллионы людей и тысячи компаний. Здесь обсуждаются high‑load и отказоустойчивость не по учебникам, а на основе многолетнего практического опыта.

Смотрите проект, чтобы узнать, как создаются одни из крупнейших облачных сервисов в России:

➕ Сайт проекта
➕ VK Видео
➕ Ютуб

Типы Серверов в Современных Системах

👉 Java Portal

Spring Boot: аккуратно задавайте границы @ComponentScan, чтобы случайно не просканировать целиком весь пакет.

Предположим, вы пишете что-то вроде @ComponentScan("com.mycompany"), хотя на самом деле нужно сканировать только часть подпакетов com.mycompany:

- Увеличивается время сканирования classpath
- Замедляется старт приложения
- Подтягиваются классы, которые вообще не должны регистрироваться как Spring-бины

Лучшие практики:

Полагайтесь на дефолты:

@SpringBootApplication
public class MyApplication { }

По умолчанию Spring сканирует только подпакеты пакета, в котором лежит MyApplication.

Сканируйте конкретные подпакеты:

@ComponentScan({
    "com.mycompany.myapp.product",
    "com.mycompany.myapp.order"
})

👉 Java Portal

Spring Boot: все важные аннотации

👉 Java Portal

Java совет: по возможности не возвращай из методов изменяемые внутренние коллекции. Это дает плюсы:

1. Не светишь внутреннее состояние, меньше рисков и утечек
2. Можно спокойно менять реализацию под капотом, не ломая остальной код

Если всё же нужно возвращать коллекции напрямую, можно сделать так:

- Вернуть глубокие копии коллекций (сложнее в реализации)

- Вернуть только read-only представление, например:

Collections.unmodifiableList(items)

👉 Java Portal

Может пригодится: самохостящаяся система uptime-мониторинга, которую можно развернуть у себя и следить за тем, работают ли твои HTTP/S сервисы. Приложение показывает статус, считает аптайм, умеет проверять SSL, есть публичные статус-страницы, уведомления и прочее.

Забираем здесь

👉 Java Portal

Java-лайфхак: record — это не только про данные. В них можно добавить свои конструкторы или методы для валидации.

// Конструкторы, статические методы и методы экземпляра:

public record Email(String address) {

    // Конструктор с валидацией
    public Email {
        if (address == null || !address.matches("^[\\w-.]+@([\\w-]+\\.)+[\\w-]{2,4}$")) {
            throw new IllegalArgumentException("Некорректный email: " + address);
        }
    }

    // Метод экземпляра
    public String domain() {
        return address.substring(address.indexOf('@') + 1);
    }

    // Статический метод
    public static Email from(String raw) {
        return new Email(raw.trim().toLowerCase());
    }
}

👉 Java Portal

Понимание Git worktree. Отличная фича Git, особенно актуальная в эпоху агентных ИИ.

Подробнее

👉 Java Portal

Git worktree — отличный способ поднять песочницу, куда можно запустить агентов искать решение, пока ты спокойно продолжаешь работу на master или другой ветке. На фото баш-скрипт, который : создаёт новый worktree/ветку под задачку с префиксом ga fix (типа fizzy--fix), а потом gd можно снести всё к чертям, когда закончил.

Если хочешь потыкать у себя — есть удобный gist для копипасты.

👉 Java Portal

Hidden классы в Java. Что скрывают Lambda выражения

С переходом Java на более безопасные и стандартизированные подходы к динамической генерации классов, скрытые (hidden) классы стали ключевым механизмом замены устаревшего Unsafe::defineAnonymousClass

Они решают проблемы доступности, управления жизненным циклом и контроля доступа, особенно актуальные для разработчиков фреймворков и языков на JVM. Хотя скрытые классы пока не полностью заменяют функциональность Unsafe, они лежат в основе ряда важных механизмов, такие как, например, реализация лямбд в JDK.

Подробнее

👉 Java Portal

Spring Boot совет

В тестах на Spring Boot можно без лишних настроек использовать RestTestClient через аннотацию @AutoConfigureRestTestClient

Для TestRestTemplate есть аналогичная аннотация — @AutoConfigureTestRestTemplate

@SpringBootTest
@AutoConfigureRestTestClient
public class PersonControllerTests {

    private static final String API_PATH = "/persons";

    @Test
    void add(@Autowired RestTestClient restTestClient) {
        restTestClient.post().uri(API_PATH)
                .body(Instancio.create(Person.class))
                .exchange()
                .expectStatus().is2xxSuccessful()
                .expectBody(Person.class)
                .value(person -> assertNotNull(person.getId()));
    }
}

👉 Java Portal

LATENCY VS THROUGHPUT

Когда пользователи говорят что приложение «тормозит», причина может быть в двух плоскостях:

* проблема latency (каждый запрос обрабатывается медленно)
* проблема throughput (система забита и не тянет нагрузку)

Иногда это вообще смесь обоих.

Latency — время, которое сервер тратит на выполнение одного запроса от начала до ответа.

Throughput — сколько запросов сервер способен обработать за единицу времени.

Представим, что ты инженер в сервисе доставки пиццы.

Сценарий 1:
Пользователь нажимает «Отправить заказ» и ответ долго крутится — значит высокий latency. Для пользователя это воспринимается как «всё лагает».
Низкий latency = быстрый отклик для каждого конкретного запроса.

Сценарий 2:
Ответы идут примерно по 100 мс — вроде норм. Но если система способна держать только 10 запросов в секунду, а одновременно приходит тысяча, всё разваливается. Это низкий throughput.
Высокий throughput = возможность обслуживать много пользователей одновременно.

Обе метрики критичны, особенно когда система растёт по нагрузке.

* Ответы быстрые, но при всплеске трафика сыпятся таймауты — проблема в throughput.
* Каждый запрос тормозит даже при маленьком трафике — проблема в latency.

» Как чинят проблемы с latency (ускоряем отдельные запросы)

Причины: медленные SQL-запросы, тяжёлые внешние API, прожорливая логика, геолокация сервера и так далее.
Обычно помогают индексы в БД, кэширование, оптимизация кода, CDN, профилирование узких мест.

» Как фиксят проблемы с throughput (увеличиваем пропускную способность)

Обычно упирается в ресурсы. Масштабирование: больше серверов, балансировка нагрузки, кэширование, горизонтальное расширение и т. п.

P.S. Для пользовательских API чаще гонятся за низким latency, а для фоновых задач типа batch-процессинга чаще важнее throughput, чем скорость каждого отдельного задания.

Всё упирается в то, под что именно ты оптимизируешься.

👉 Java Portal