🔍 Просто о сложном: Spring Boot

Spring Boot — это не «новый фреймворк», а надстройка над Spring, которая убирает рутину и ускоряет разработку.

В обычном Spring нужно было вручную конфигурировать всё: от DataSource до DispatcherServlet. В Boot это делается автоматически через автоконфигурацию.

🔹 Как работает автоконфигурация

Spring Boot сканирует зависимости и classpath, а затем подключает нужные бины:

— Если у вас есть spring-boot-starter-data-jpa, Boot автоматически создаст EntityManagerFactory, DataSource, транзакционный менеджер.

— Если добавлен spring-boot-starter-web, он поднимет встроенный Tomcat/Jetty и зарегистрирует контроллеры. И так далее.

Магия кроется в аннотации @EnableAutoConfiguration (включается через @SpringBootApplication). Она загружает META-INF/spring.factories → список классов-конфигов → каждый проверяет условия @ConditionalOnClass, @ConditionalOnMissingBean и решает: активироваться или нет.

💡 Почему это работает так гладко

Потому что в Boot сотни готовых конфигураций «на все случаи жизни».

Фактически, это огромная библиотека «если увидишь X — настрой Y».

👀 Подводный слой магии

— Черный ящик

Легко забыть, что именно сконфигурировал Boot. Иногда приходится «копать» в автоконфигурацию, чтобы понять, какой бин реально используется.

— Избыточные зависимости

Подключив Starter, можно случайно притащить половину экосистемы Spring. Это увеличивает время старта и усложняет дебаг.

— Конфликт настроек

Собственная конфигурация может пересечься с автоконфигурацией.

⚡️ Хорошая практика

— Не доверяйте «чёрному ящику»: при старте приложения смотрите Spring Boot Actuator и логи автоконфигурации.

— Знайте про --debug при старте: он показывает, какие автоконфигурации включены или отключены.

— В продакшене лучше контролировать, какие именно стартеры вы тянете. Иногда spring-boot-starter-web приносит в проект в три раза больше, чем реально нужно.

🎯 Итог

Spring Boot — это ускоритель, но не магия. Его сила в автоконфигурациях, а слабость в том, что легко потерять контроль.

Понимание того, как работает @EnableAutoConfiguration и условия @Conditional, отличает разработчика, который «просто пишет на Boot», от того, кто реально управляет приложением.

🐸 Библиотека джависта

#CoreJava

🔥 Spring Security: как работает @PreAuthorize и зачем он нужен

В продакшн-коде часто возникает задача ограничить доступ к методам сервиса или контроллера. Делать это вручную — значит плодить дублирование и путать бизнес-логику с проверками. Для этого в Spring Security есть аннотация @PreAuthorize.

🔵 Как это работает

1. Аннотация вешается на метод (контроллер или сервис).

2. При вызове метода Spring Security перехватывает обращение и проверяет условие, указанное в аннотации.

3. Условие описывается на языке SpEL (Spring Expression Language), где доступно:

▪️ authentication — текущий объект аутентификации;
▪️ principal — данные текущего пользователя;
▪️ #id, #dto и т.д. — аргументы метода, к которым можно обратиться напрямую.

Пример:

@PreAuthorize("hasRole('ADMIN')")
public void deleteUser(Long id) { ... }

→ метод вызовется только для пользователей с ролью ADMIN.

🔵 Что можно писать внутри

— Проверка ролей и прав

hasRole('USER'), hasAnyRole('ADMIN','MODERATOR')

hasAuthority('SCOPE_read') (актуально при работе с OAuth2)

— Собственные условия

@PreAuthorize("#id == authentication.principal.id")
public UserProfile getProfile(Long id) { ... }

→ Здесь доступ только к своему профилю.

— Комбинации условий

Логика пишется прямо в SpEL:

@PreAuthorize("hasRole('ADMIN') or @securityService.isOwner(#docId)")
public Document update(Long docId) { ... }

— Сервисы внутри выражений

В выражение можно подключать свои бины:

@PreAuthorize("@reviewSecurity.isOwner(#id, authentication)")
public Review update(Long id) { ... }

→ бин reviewSecurity должен быть в контексте Spring и возвращать true/false.

🔵 Зачем это нужно

— Не надо вручную писать проверки в каждом методе.

— Авторизация централизована и читается прямо на уровне API.

— Условия можно вынести в отдельный сервис, чтобы не захламлять аннотацию.

👉 В итоге @PreAuthorize — это не только про роли, а про гибкий DSL проверки доступа, который можно расширять под проект: от банальной проверки ролей до бизнес-логики уровня "пользователь может редактировать только свои документы, если они ещё не опубликованы".

🐸 Библиотека джависта

#Enterprise

🐸 Библиотека джависта

#DevLife