🧙‍♂️ Spring Boot: Магия под капотом (Starters & AutoConfig)

Вы когда-нибудь задумывались: почему вы просто добавляете одну строчку в pom.xml, пишете main метод, и у вас волшебным образом поднимается Tomcat, настраивается JSON-конвертер и подключается логирование?

За этим стоят два кита Spring Boot: Starters и AutoConfiguration.

1️⃣ Starters (Стартеры) - "Всё включено"

В старом Spring, чтобы сделать веб-приложение, нужно было вручную найти версии для Spring MVC, Tomcat, Jackson, Validation API... и молиться, чтобы они были совместимы.

Starter — это готовый набор зависимостей (dependencies), собранный в один пакет. Это как "Комбо-обед" в ресторане.

🔴Хотите Веб? Добавляете spring-boot-starter-web.
* Внутри: Tomcat + Spring MVC + Jackson + Logback.


🔴Хотите Тесты? Добавляете spring-boot-starter-test.
*Внутри: JUnit + Mockito + AssertJ + Hamcrest.



Вам больше не нужно думать о версиях библиотек. Spring Boot следит за "BOM" (Bill of Materials) и гарантирует, что все версии внутри стартера дружат друг с другом.

2️⃣ AutoConfiguration - "Умный детектив"

Это мозг фреймворка. Когда приложение запускается, Spring Boot начинает сканировать ваш classpath (все подключенные библиотеки jar).

Он рассуждает примерно так:

1. "Так, я вижу, что в зависимостях есть класс H2Driver?" "Значит, программист хочет базу данных. Создам-ка я ему бин DataSource с настройками для H2!"
2. "Я вижу классы Tomcat и Spring MVC?" "Значит, нужно поднять встроенный веб-сервер на порту 8080 и настроить DispatcherServlet."
3. "О, программист сам создал свой бин DataSource?" "Окей, тогда я отступаю и свою автоконфигурацию не применяю."

Вся эта логика держится на аннотациях @Conditional...:

🔴@ConditionalOnClass: Создать бин, если найден класс X.
🔴@ConditionalOnMissingBean: Создать бин, ТОЛЬКО если программист не создал такой же сам.

⚙️ Главная кнопка: @SpringBootApplication

Вы вешаете эту аннотацию над main классом. На самом деле это "матрешка", внутри которой спрятаны 3 другие аннотации:

@SpringBootConfiguration // Говорит: "Это конфигурационный класс"
@EnableAutoConfiguration // Говорит: "ВКЛЮЧИ МАГИЮ!" (запусти сканирование classpath)
@ComponentScan           // Говорит: "Ищи пользовательские бины в этом пакете"
public @interface SpringBootApplication { ... }

🕵️‍♂️ Pro-Tip: Как увидеть магию?

Иногда автоконфигурация мешает, или вы не понимаете, почему Spring решил подключить ту или иную базу.
Добавьте в application.properties одну строчку:

debug=true

При запуске в консоль вывалится Condition Evaluation Report. Там будет честно написано:

🔴✅ Positive Matches: Что Spring настроил сам (и почему).
🔴❌ Negative Matches: Что Spring проигнорировал (потому что не нашел нужных классов или вы перекрыли это своим бином).

🔥 Итог

🔴Starters экономят время на подбор зависимостей.
🔴AutoConfiguration экономит время на написание рутинных конфигов.
🔴Spring Boot работает по принципу Convention over Configuration (Соглашение важнее конфигурации): "Я дам тебе лучшие настройки по умолчанию, но ты всегда можешь их изменить".

#SpringBoot #Java #Starters #AutoConfig

📲 Мы в MAX

👉@BookJava

🎮 Анатомия REST Controller: Входящие и Исходящие

Раньше, чтобы вернуть JSON, нужно было танцевать с бубном. В Spring Boot это делается "из коробки" благодаря библиотеке Jackson, которая тихо работает в фоне.

1️⃣ @RestController vs @Controller

Это первый вопрос на собеседовании.

🔴@Controller: Олдскул. Используется, когда мы возвращаем HTML-страницы (Thymeleaf, JSP). Чтобы вернуть JSON, нужно над каждым методом вешать @ResponseBody.
🔴@RestController: Современный стандарт для REST API.
🔴Это просто @Controller + @ResponseBody над всеми методами.
🔴Всё, что возвращает метод, автоматически превращается в JSON.



2️⃣ Принимаем данные (3 главных способа)

Как вытащить информацию из запроса?

А. Из пути URL (@PathVariable)
Используем, когда параметр - это часть адреса ресурса.

🔴URL: GET /users/42
🔴Код:

@GetMapping("/users/{id}")
public User getById(@PathVariable Long id) { ... }

Б. Из параметров запроса (@RequestParam)
Используем для фильтрации, сортировки или опциональных параметров.

• URL: GET /users?role=ADMIN&age=25
• Код:

@GetMapping("/users")
public List<User> search(
    @RequestParam String role, 
    @RequestParam(required = false) Integer age // Опционально
) { ... }

В. Из тела запроса (@RequestBody)
Используем для отправки сложных объектов (обычно в POST/PUT запросах). Spring возьмет JSON и сам превратит его в Java-объект (DTO).

• JSON: { "name": "Alex", "email": "[email protected]" }
• Код:

@PostMapping("/users")
public User create(@RequestBody UserDto userDto) { ... }

3️⃣ Управляем ответом (ResponseEntity)

Просто вернуть объект User, это хорошо (статус будет 200 OK). Но что, если мы хотим вернуть 404 (Not Found) или 201 (Created)?

Для этого используем обертку ResponseEntity<T>.

💻 Пример: Идеальный контроллер

@RestController
@RequestMapping("/api/v1/users") // Общий префикс для всех методов
public class UserController {

    private final UserService service; // Внедряем через конструктор

    public UserController(UserService service) {
        this.service = service;
    }

    // 1. Получить всех (GET 200 OK)
    @GetMapping
    public List<User> getAll() {
        return service.findAll();
    }

    // 2. Найти одного (с управлением статусом)
    @GetMapping("/{id}")
    public ResponseEntity<User> getOne(@PathVariable Long id) {
        return service.findById(id)
                .map(user -> ResponseEntity.ok(user)) // 200 OK
                .orElse(ResponseEntity.notFound().build()); // 404 Not Found
    }

    // 3. Создать (POST 201 Created)
    @PostMapping
    public ResponseEntity<User> create(@RequestBody UserDto dto) {
        User created = service.save(dto);
        return ResponseEntity.status(HttpStatus.CREATED).body(created);
    }
}

⚡ Jackson Magic (Pro-Tip)

Иногда вам не нужно отдавать все поля объекта (например, пароль).
Не пишите код для скрытия! Используйте аннотации Jackson прямо в DTO:

• @JsonIgnore - поле не попадет в JSON.
• @JsonProperty("full_name") - поле fullName в Java станет full_name в JSON.

🔥 Итог

• Используйте @RestController для API.
• @PathVariable - для ID (/users/1).
• @RequestParam - для фильтров (/users?sort=name).
• @RequestBody - для больших данных (JSON).
• Возвращайте ResponseEntity, чтобы контролировать HTTP-статусы.

#SpringBoot #REST #Controller #API #Java


📲 Мы в MAX

👉@BookJava

💾 Spring Data JPA: SQL больше не нужен?

Spring Data JPA это абстракция над Hibernate (который, в свою очередь, является реализацией JPA).
Его главная киллер-фича: Генерация запросов из названий методов.

🏗 1. Сущность (@Entity)

Сначала мы объясняем Java, как выглядит наша таблица. Обычный класс превращается в таблицу с помощью пары аннотаций.

@Entity // Это таблица в БД
@Table(name = "users") 
public class User {
    @Id // Это Primary Key
    @GeneratedValue(strategy = GenerationType.IDENTITY) // Авто-инкремент
    private Long id;
    
    private String email;
    private int age;
    private boolean active;
    
    // Геттеры, сеттеры...
}

🪄 2. Репозиторий (Магия)

Вместо написания класса UserDao, мы просто создаем интерфейс.

public interface UserRepository extends JpaRepository<User, Long> {
    // Здесь пусто! Но методы уже есть.
}

Наследуясь от JpaRepository, вы сразу получаете готовые методы:

🔴.save(user) - сохранить/обновить.
🔴.findById(id) - найти по ID (возвращает Optional).
🔴.findAll() - найти всех.
🔴.deleteById(id) - удалить.

Ни одной строчки SQL писать не пришлось! 😎

🔮 3. Derived Queries (Запросы из имени)

Что, если нужно найти пользователя по email? Или всех активных пользователей старше 18 лет?
Вы просто пишете метод в интерфейсе с правильным названием, и Spring сам составляет SQL-запрос.

public interface UserRepository extends JpaRepository<User, Long> {

    // SQL: SELECT * FROM users WHERE email = ?
    Optional<User> findByEmail(String email);

    // SQL: SELECT * FROM users WHERE active = true AND age > ?
    List<User> findByActiveTrueAndAgeGreaterThan(int age);

    // SQL: EXISTS (SELECT 1 FROM users WHERE email = ?)
    boolean existsByEmail(String email);
}

Синтаксис простой: find + By + ИмяПоля + Условие (если нужно).

🛠 4. Если магия не справилась (@Query)

Иногда названия методов становятся слишком длинными и уродливыми (findByNameAndAgeAndActiveAnd...). Или нужен сложный JOIN.
Тогда мы берем управление в свои руки и пишем запрос на JPQL (Java Persistence Query Language) - это SQL, но оперирующий классами, а не таблицами.

@Query("SELECT u FROM User u WHERE u.email LIKE %:domain%")
List<User> findUsersByEmailDomain(@Param("domain") String domain);

⚡ Транзакции (@Transactional)

База данных требует транзакций (всё или ничего).
В Spring Boot методы репозитория уже транзакционны (только на чтение).
Если же вы в сервисе делаете несколько операций подряд (снять деньги, перевести деньги), вешайте @Transactional над методом сервиса.

@Service
public class PaymentService {
    @Transactional // Если упадет ошибка, все изменения откатятся
    public void transferMoney() {
        repo.withdraw(...);
        repo.deposit(...);
    }
}

🔥 Итог

Spring Data JPA убирает 90% рутинной работы с БД.

1. Создали @Entity.
2. Создали интерфейс extends JpaRepository.
3. Нужен поиск? Написали метод findByField.
4. Сложный запрос? Написали @Query.

#SpringBoot #JPA #Hibernate #Database #SQL

📲 Мы в MAX

👉@BookJava

🚑 Global Exception Handling: Красиво падаем

Представьте: пользователь запрашивает ID, которого нет.

🔴Плохой сценарий: Сервер выплевывает стэктрейс на 500 строк, раскрывая внутренности БД. Статус 500 Internal Server Error. Клиент в шоке.
🔴Хороший сценарий: Клиент получает аккуратный JSON: {"status": 404, "message": "User not found"}.

Раньше, чтобы добиться хорошего сценария, приходилось писать try-catch в каждом методе контроллера. Это ужасно.
В Spring Boot есть элегантное решение - @ControllerAdvice.

🛡 Что это такое?

Это перехватчик (Interceptor), который работает по принципу Аспектно-Ориентированного Программирования (AOP). Он "сидит" над всеми вашими контроллерами и ловит исключения, которые вылетели из них, прежде чем они дойдут до пользователя.

🛠 Как настроить? (3 шага)

1. Создаем DTO для ошибки

Нам нужен красивый формат ответа, чтобы фронтенд всегда знал, чего ожидать.

public record ErrorResponse(int statusCode, String message, LocalDateTime timestamp) {}

2. Создаем Глобальный Обработчик

Используем аннотацию @RestControllerAdvice. Это тот же @ControllerAdvice, но он автоматически добавляет @ResponseBody ко всем ответам (мы же пишем REST API).

Внутри класса мы пишем методы-обработчики с аннотацией @ExceptionHandler.

@RestControllerAdvice
public class GlobalExceptionHandler {

    // 1. Ловим конкретную ошибку (например, сущность не найдена)
    @ExceptionHandler(EntityNotFoundException.class)
    public ResponseEntity<ErrorResponse> handleNotFound(EntityNotFoundException ex) {
        return ResponseEntity
                .status(HttpStatus.NOT_FOUND)
                .body(new ErrorResponse(404, ex.getMessage(), LocalDateTime.now()));
    }

    // 2. Ловим ошибки валидации (если передали кривой JSON)
    @ExceptionHandler(MethodArgumentNotValidException.class)
    public ResponseEntity<ErrorResponse> handleValidation(MethodArgumentNotValidException ex) {
        String errors = ex.getBindingResult().getFieldErrors().stream()
                .map(e -> e.getField() + ": " + e.getDefaultMessage())
                .collect(Collectors.joining(", "));
        
        return ResponseEntity
                .status(HttpStatus.BAD_REQUEST)
                .body(new ErrorResponse(400, errors, LocalDateTime.now()));
    }

    // 3. Ловим всё остальное (Fallback)
    @ExceptionHandler(Exception.class)
    public ResponseEntity<ErrorResponse> handleAll(Exception ex) {
        return ResponseEntity
                .status(HttpStatus.INTERNAL_SERVER_ERROR)
                .body(new ErrorResponse(500, "Произошла внутренняя ошибка", LocalDateTime.now()));
    }
}

3. Бросаем исключения в Сервисе

Теперь в коде сервиса можно не бояться и просто бросать ошибки. Обработчик их поймает.

public User getUser(Long id) {
    return repo.findById(id)
        .orElseThrow(() -> new EntityNotFoundException("User with id " + id + " not found"));
}

⚡ Почему это круто?

1. Чистота кода: В контроллерах нет try-catch блоков. Только "счастливый путь" (happy path).
2. Единообразие: Весь API возвращает ошибки в одинаковом формате.
3. Безопасность: Вы контролируете, какой текст ошибки увидит пользователь, и скрываете системные детали.

🔥 Итог

🔴Не используйте try-catch в контроллерах.
🔴Создайте один класс с @RestControllerAdvice.
🔴Маппите Java-исключения (EntityNotFoundException) на HTTP-статусы (404 Not Found).

#SpringBoot #Java #ExceptionHandling #BestPractices

📲 Мы в MAX

👉@BookJava

🎛 Конфигурация Spring Boot: YAML, Профили и Секреты

Хардкодить настройки (порты, пароли, URL-ы) в Java-коде - это моветон. Если вам нужно поменять порт сервера, вы не должны перекомпилировать приложение.

Spring Boot следует принципу: "Код отдельно, настройки отдельно".

1️⃣ Properties vs YAML

По умолчанию Spring создает application.properties. Это старый формат (ключ=значение).
Весь мир переходит на YAML (.yaml или .yml). Он читабельнее и поддерживает иерархию.

Было (.properties):

spring.datasource.url=jdbc:postgresql://localhost/db
spring.datasource.username=admin
server.port=8080

Стало (.yaml):

server:
  port: 8080
spring:
  datasource:
    url: jdbc:postgresql://localhost/db
    username: admin

Меньше дублирования, глазам приятнее.

2️⃣ Как достать настройки в коде?

Способ А: Простой (@Value)
Подходит для точечных настроек.

@Value("${server.port}")
private int port;

Способ Б: Профессиональный (@ConfigurationProperties)
Если настроек много (например, настройки почты или API), лучше собрать их в отдельный класс. Это дает типизацию и проверку данных!

@ConfigurationProperties(prefix = "mail")
public record MailConfig(String host, int port, String username) {}

Теперь вы просто внедряете MailConfig в свои сервисы, как обычный бин.

3️⃣ Профили (Profiles) - Киллер-фича

На локальной машине у вас H2 база данных, а на продакшене - PostgreSQL. Как не менять конфиги вручную?
Используйте Профили.

Вы создаете несколько файлов рядом с основным application.yaml:

🔴application-dev.yaml (для разработки)
🔴application-prod.yaml (для боевого сервера)

В основном файле вы указываете, какой профиль активен по умолчанию:

spring:
  profiles:
    active: dev # По умолчанию грузим dev-настройки

А при запуске на сервере вы просто передаете флаг, и Spring подхватит нужный файл, перетерев дефолтные настройки:
java -jar app.jar -Dspring.profiles.active=prod

4️⃣ Секреты (Никаких паролей в Git!)

Самая страшная ошибка - закоммитить application-prod.yaml с паролем от боевой БД в репозиторий. ☠️

Правило: В файлах храним только дефолтные/безопасные значения. Реальные пароли передаем через Переменные Окружения (Environment Variables).

Spring Boot имеет строгий приоритет загрузки. Переменные окружения OS имеют более высокий приоритет, чем файлы.

🔴В файле: spring.datasource.password=secret
🔴В переменной ОС: SPRING_DATASOURCE_PASSWORD=SuperSecurePass123

Spring увидит переменную в системе и проигнорирует то, что написано в файле. Ваш секрет в безопасности.

🔥 Итог

1. Используйте YAML вместо properties.
2. Группируйте настройки через @ConfigurationProperties.
3. Разделяйте среды через Профили (dev, test, prod).
4. Никогда не храните боевые пароли в файлах. Используйте ENV vars.

#SpringBoot #Configuration #YAML #DevOps #BestPractices

📲 Мы в MAX

👉@BookJava