Java

Если обычного return user уже мало, в Spring Boot есть ResponseEntity<T>. Он позволяет явно управлять всем ответом: • статусом HTTP • заголовками • телом ответа • обработкой ошибок • поведением API в нестандартных сценариях Пример: пользователь найден - возвращаем 200 OK, тело ответа и кастомный header. Пользователь не найден - возвращаем 404 NOT FOUND без лишней магии...

В Java @Override - это не украшение над методом, а простая защита от глупых ошибок. Представь базовый класс: class Report { void print() { // ... } } Ты хочешь переопределить метод, но случайно пишешь prnt() вместо print(): class PDFReport extends Report { void prnt() { // ... } } Код скомпилируется. Но метод print() не переопределён. Ты просто создал новый метод с опечаткой, а старое поведение осталось на месте...

Когда API начинает сыпаться ошибками, главный вопрос не «что сломалось», а «где именно сломалось». Request ID решает эту боль просто: каждому входящему запросу выдаётся уникальный идентификатор, который потом проходит через логи, заголовки и внутренние вызовы. В итоге можно быстро найти весь путь конкретного запроса: • где он пришёл • какой сервис его обработал • на каком шаге появилась...

В Spring Boot не нужно размазывать обработку ошибок по каждому endpoint через бесконечные try/catch. Для этого есть @RestControllerAdvice. Идея простая: вы выносите обработку исключений в один глобальный класс, а контроллеры оставляете чистыми. Например: @RestControllerAdvice public class GlobalExceptionHandler { @ExceptionHandler(ResourceNotFoundException.class) public ResponseEntity<?> handleNotFound(ResourceNotFoundException ex) { return ResponseEntity .status(HttpStatus.NOT_FOUND) .body(new ErrorResponse("NOT_FOUND", ex...

@ConditionalOnClass - одна из тех аннотаций, из-за которых Spring Boot кажется умным. Она говорит фреймворку: «Включи этот bean или конфигурацию только если нужный класс реально есть в проекте». Простой пример: @Configuration @ConditionalOnClass(DataSource.class) public class DataSourceAutoConfiguration { // загружается только если доступен javax.sql.DataSource } То есть Spring Boot не пытается настраивать всё подряд. Он смотрит: • есть ли нужная библиотека в зависимостях...

Классический сценарий: Вы грузите список заказов: orderRepository.findAll() А потом в цикле обращаетесь к order.getItems(). Hibernate сначала делает один запрос за заказами, а потом ещё по одному запросу на каждый заказ, чтобы достать items. 100 заказов = 101 SQL-запрос. И вот здесь спасает @EntityGraph. Он позволяет явно сказать репозиторию, какие связи нужно подтянуть сразу: @EntityGraph(attributePaths = {"items"}) В итоге Hibernate может сгенерировать один запрос с JOIN, вместо десятков лишних походов в базу...

Если у вас есть scheduled task, не стоит хардкодить интервал прямо в аннотации: `@Scheduled(fixedRate = 5000)` Лучше вынести значение в конфиг: `@Scheduled(fixedRateString = "${task.interval}")` А в application.properties указать: `task.interval=5000` Почему так лучше: •...

Если frontend и backend живут на разных доменах или портах, браузер начнет резать запросы по CORS. Это не баг Spring Boot и не проблема React. Это нормальный механизм безопасности браузера. Правильный способ - настроить CORS на стороне backend. В Spring Boot это можно сделать глобально через WebMvcConfigurer: указать маршруты, разрешенные origins, HTTP-методы, заголовки и работу с credentials. Главное - не ставить бездумно * везде подряд, особенно если используете cookies, токены или allowCredentials(true)...

В Spring Boot не стоит бездумно писать что-то вроде: @ComponentScan("com.mycompany") На первый взгляд удобно: фреймворк сам просканирует весь пакет и найдет нужные компоненты. Но проблема в том, что он может просканировать слишком много. Это увеличивает время classpath scanning, замедляет старт приложения и иногда подтягивает классы, которые вообще не должны были становиться Spring-компонентами. Лучший вариант - полагаться на дефолтное поведение: @SpringBootApplication...

Классика: приходит запрос с дополнительным полем, которого нет в DTO и ты ловишь UnrecognizedPropertyException. Клиент добавил поле, ты не обновил модель - всё падает. Решение в одну строку: @JsonIgnoreProperties(ignoreUnknown = true) public...

@RestController - это не просто удобство, а скрытая магия, про которую многие забывают. Под капотом это комбинация @Controller + @ResponseBody . То есть тебе не нужно писать @ResponseBody в каждом методе - всё работает автоматически. • Меньше...

Многие даже не замечают, как теряют скорость из-за автoboxing в Stream API. ❌ Плохо (создаются объекты Integer): Stream<Integer> boxed = Stream.of(1, 2, 3, 4, 5); int sum = boxed.reduce(0, Integer::sum); Каждое число → объект → лишняя память + нагрузка на GC ✅ Хорошо (работа с примитивами): int sum = IntStream.of(1, 2, 3, 4, 5)...