Comments 28
"Минус Спринга в том, что многие пользуются им только на базовом уровне и стреляют себе в ногу время от времени" - вместо Спринга можно вставить любую технологию без потери смысла.
Реальный минус сегодня, который заложен в самые основы фреймворка, - это жор памяти и ощутимо долгое время старта на больших проектах. С этим бороться реально тяжело. Все остальные "минусы" характерны для любого сколь-нибудь развитого промышленного инструмента.
это жор памяти
(пусть частичное, но решение - thin jar) : https://dzone.com/articles/spring-boot-thin-jar-builder-for-running-java-micr
ощутимо долгое время старта на больших проектах
Spring Native и component index помогают:
https://stackoverflow.com/questions/47254907/how-can-i-create-a-spring-5-component-index
https://docs.spring.io/spring-native/docs/current/reference/htmlsingle/
https://spring.io/blog/2022/09/26/native-support-in-spring-boot-3-0-0-m5
В ближайшее время вряд ли что-то* сможет «подвинуть»
автор так увлёкся сносками (которые, лично мне, безумно мешали читать статью), что забыл написать сноску к выводу
Хотелось бы все-таки понять - Spring плохой или некоторые разработчики в вакууме, с которыми довелось встретиться приглашенному эксперту, не умеют использовать Spring? Из заголовка статьи следует первое, из содержания - второе.
Spring плохой или
spring магический и мало кто заглядывает под капот. на этой благодатной почве зреют как каргокульты (антипаттерны), так и вера в чудо и прочая ересь ))
На мой не искушенный взгляд, спринг - обширный фреймворк с привкусом энтерпрайза. Он интересный внутри, имеет свои шероховатости, решает многие проблемы и создает некоторые - всё как в среднем по больнице ))
Ну пардон — если кто-то не заглядывает, разве это вина инструмента? Вот я много раз заглядывал, и могу сказать, что это как правило нифига не сложно — исходники спринга конечно не тривиальные, но и ничего непостижимого там тоже нет. А если там и есть такие части — то они чаще всего нам с вами не понадобятся.
Ну то есть, и эта вот «магия», и то что не все умеют пользоваться — это же явно претензия не к продукту. То есть, если дело в квалификации, то лучше не станет, если спринг заменить чем-то другим.
Spring не хороший и не плохой - это просто инструмент который можно применять как в подходящих для этого условиях, так и наоборот - в совсем не подходящих
На мой взгляд Spring не слижком подходит для реализации модной и молодежной микросервисной архитектры. Но тут смотря с чем сравнивать.
Если к примеру сравнивать с таким фреймворком как quarkus то последний определенно выигрывает и именно по причине того, что изначально ориентирован именно на микросервисную архитектуру (и реализует почти всеcь функционал предлагаемый Spring Boot и в частности все то что мы именуем Opinionated Defaults Configuration). А вот если реализовывать stand alone приложение, или к примеру командно-строчную утилиту, я бы выбрал Spring Boot. Ну по крайней мере у меня сейчас такое мнение
Согласен. Сам для микросервисов начинаю с Javalin, но интервьюеры кривились почему-то.
для микросервисов начинаю с Javalin, но интервьюеры кривились почему-то
Возможно отому, что микросервисы это не только, а довольно часто даже не столько RESTFul интерфейс, но и интеграция с другими библиотеками и фреймворками - т.е. именно то, что предлагают Spring Boot и Quarkus
Но конечно есть и другие точки зрения (и они имеют полное право на свое существование). В частности эти другие точки зрения включают и чмнение о малоценности такого рода интеграции. Еще одна точка зрения говорит о малоценности компиляуии байт-кода в нативные коды - она имеет разные формулировки в.ч. и такую "зачем писать на java чтобы потому компилировать в нативный код - не проще сразу писать на golang?" Я га всякий случай пожчекну - это не мои точки зрения, но я признаю, что они имеют под собой рациональную основу и имеют право на существование (но с моей персональной точки зрения спорны.) При этом я уточняю, что мне в моей работе досточно часто приходится обходиться и без Spring Framework/Quarkus (в том смысле что мне приходится интегрировать другие библиотеки и фреймворки самостоятеьно), равно как и писать код на golang (конкретно микросервисов - для иных целей использовать не приходилось)
а почему спринг плох для микросервисной архитектуры ?
Прекращение доступа к Maven Central несколько усложнит ситуацию, но полностью сделать это невозможно, так как сразу появится достаточное количество сервисов-посредников, альтернативных репо, которые все равно будут выкачивать зависимости из того же Maven Central, только косвенно. Кроме того, уже сейчас существует достаточно много альтернативных репо разных корпораций и разработчиков, фактически уже обновляемых из него. Вероятно, поэтому даже пытаться закрыть не будут - скорее всего.
Главная проблема спринга в том, что он просто не нужен, он не решает никаких проблем. Первый раз я познакомился с ним в 2008 году, с тех пор поучаствовал во многих проектах в которых спринг был и в которых нет, так вот я не могу сказать, что хоть как-то ощущал потребность в спринге в проектах где он отсутствовал.
Достаточно часто необходимо организовать аутентификацию внешнего сервиса в нашем (логин/пароль, сертификат или токен). Для этого, в большинстве случаев, достаточно одного фильтра, который организует всю необходимую функциональность (без завязки на Spring Security), но «Spring-разработчики» упорно следуют шаблону*: если нужна безопасность - подключаем Spring Security, работа с БД — Spring Data JPA, микросервисы – Spring Cloud.
Суть примеров ясно, но я бы поостерёгся упоминать Spring Security в этом примере. Придумывать свои решения в области безопасности, просто чтобы не пользоваться решением из фреймворком (которое скорее всего протестировано, проревьюено специалистами в области безопасности и т.д.) может быть чревато. Тем более что тот же Spring Security автоматом применяет средства защиты от некоторых уязвимостей (например, в StrictHttpFirewall)
Статья ни о чем :-( Удивлён, что набрала плюсы, а не минусы. У меня, к сожалению, нет права ставить минус (или плюс).
Альтернативы в виде jee или самопис имеют похожие или даже точно такие же проблемы.
Проблема со SpringSecurity не раскрыта - обойтись фильтром можно только в случае сверхпрмитивного приложения/SOA (в моей практике половина сервисов требовала хотя бы пару ролей reader/writer, иногда admin для сброса кешей или получения какой-нибудь статистики). Можно написать свой аналог с кучей кода, но зачем?
Можно написать свой аналог с кучей кода, но зачем?
ну не всегда этого кода куча. Однако достаточно часто приходится паботать с внешним провайдером услуг аутентификации/авторизации. в этом случае может быть как раз примитивный фильтр. Только не подуматье, что я фанат такого решения. Но если мне за это платят - почему нет?
Общаясь с разными разработчиками, я заметил интересную тенденцию мнений по поводу спринга: чем лучше человек в нем разбирается, тем больше он его ненавидит.
Спринг из коробки предлагает много нужных вещей, которых не надо идти искать, рыская по всей экосистеме. С другой стороны, посредственный, а иногда отвратительный дизайн (привет Spring Securituy), куча неявных соглашений, @заклинания, кейсы, прибитые гвоздями без возможности модификации -- убивают все удовольствие от разработки. Впрочем, в этом заключается участь всех индустриальных стандартов. Шедевры не находят массового пользователя.
Мне показалось или статья написана чтобы прорекламировать курс?
К алтернативным web-framworks можно добавить: sparkjava.com и vertx.io
sparkjava - очень лаконичен
vertx - тоже лаконичен + асинхронен
"Самый частый негативный пример – генерация большого отчёта аккуратно заставляет все остальные функции сервиса «подождать», т. е. остальные запросы клиентов «подвисают»."
Смотря какая ситуация, зачастую это ошибка архитектуры, для решения проблем с блокировками БД существует паттерн Database per service.
Странно что в инфографике не видно обычного человеческого Java EE/Jakarta EE. Quarkus к этому разделу, в принципе, тоже относится, хотя их Arc ближе к новой CDI Lite чем к полноценному варианту. Но есть дохрена живых мелких вариантов типа Helidon MP, OpenLibery, WildFly/JBoss EAP, TomEE не говоря уже более тяжёлые заходы типа стеклорыбы, сферы и т.п.
Spring. Экспертное мнение о плюсах и минусах самого популярного Java-фреймворка