Так я ж всеми руками за! Сам топлю за разделение сборок, отделение фронта от бэка и так далее. единственное разногласие — я допускаю существование папки static внутри собранного jar, внутри которой лежит отдельно собранная статика. То есть различие в основном уже за пределами разработки, это ближе к девопсу.
Если уж от чего избавляться, то для начала от war, вот уж что устарело и нафиг не нужно :D А где держать статику — вопрос дискуссионный. Если нужно максимальное место для маневра, то статика инкапсулированная в jar сильно поможет — раскатка новой версии ограничивается раскаткой одного бинаря. При статике на nginx неизбежно возникают грабли вида «сервер с nginx упал, ой, не упал, а не доступен, да, мы выложили новую версию фронта, ой, простите выложили не туда, ой, простите, не новую версию, а ту, которая три версии назад...», и так далее. Но если этот момент не важен, то можно статику и отдельно раздавать, никаких проблем.
И как описанное мной может им помешать? :) В один момент времени такой «и жнец и швец» может выполнять только одну роль, которую при описанном мной flow выполнять легко и приятно, а главное относительно легко и относительно приятно понимать, что же там такое понаписано и как работает. Я довольно долго варился в соку проекта, где как раз практиковалось АДСКОЕ смешение технологий с их взаимным протикновением, и мало того, что подчас было невозможно понять, как оно работает, так оно еще и не расширябельно было просто никак. Как вспомню xslt-преобразования на уровне БД — глаз дергается… Взаимное проникновение таких разных вещей, как js и java отзовется не меньшей болью на поддержке и развитии, я думаю.
Может я чего не понимаю, но. В моем текущем проекте мы как раз пилим ангуляровский фронт (не сильно проще react) и spring-boot бэк. Фронт пилят фронтэндщики, верстальщики и прочие дизайнеры, а бэк — джависты. Одним совершенно не интересна кухня других, и ни один джавист не захочет видеть в своем проекте непонятные куски, которые туда натащат js-ники, и наоборот. Собственно договорились о высокоуровневом формате взаимодействия бэка и фронта — json сообщения по websocket, если интересно — и все, друг-другу не мешаем. Все пишется в естественной для них среде — у джавистов junit, у js-ников Karma и прочие npm, а вместе все встречается только на сборке — отдельными шагами собираем фронт и бэк, бэк прямо в свой jar получает инъекцию фронтовой статики, после чего все автоматически раскатывается на сервер, и запускается практически через java -jar. По-моему это отлично, когда фронт в разработке максимально изолирован от бэка. А вы обратно хотите :)
Эй, читатель! Помоги выбрать веб-фреймворк? Требования: модный, молодежный, популярный, качественный фреймворк, и чтобы им кто-то действительно пользовался в проде
На стэк я захожу несколько раз в день, если разбираюсь с незнакомой мне технологией, на гитхаб… ну, пару раз, качнуть реп с примерами. На стэке всяко чаще получаюсь.
Не претендую на правоту, но «более сложные варианты валидации», наверное, все же лучше реализовывать махровой императивщиной, а не магическими аннотациями — чем сложнее будет маршрут валидации, тем сложнее будет понять, что, как и в каком порядке проверяется. Плюс это будет дебажится, что позволит найти ответ на рано или поздно возникнувший вопрос «а почему конкретно в этом случае не работает?»
И кстати, OSGI ее таки решает. В моей практике (3.5 года немаленького проекта) я не могу вспомнить симптомов jar hell на ровном месте.
Уверен, вы найдете тут массу народа, который и без всякого OSGi в не маленьких проектах jar-hell не встречает :) Потому что бороться с ним и его симптомами можно многими средствами, от усиленного контроля того, что используется в проекте и до распиливания проекта на микросервисы.
О том, что OSGi проблему не решает четко сказано в том самом докладе о котором речь идет в сабже, если мне не изменяет склероз, то примерно такими словами: «проблему не решает, просто переносит ее на другой уровень». Возможно докладчик не прав, тут сказать ничего не могу.
Ок, и? Вы сами только что сказали, что jar-hell в одном из случаев возникает из-за транзитивных зависимостей — и эту проблему jigsaw не решает. Точно так же jigsaw не решает проблему «черте где взятых либ», но тут претензий никаких нет, к этому он никакого отношения не имеет и решать, соответственно, не должен. Но транзитивные зависимости — это то, с чем приходится жить ежедневно.
А что мешает собрать «вот это все» где-то отдельно, после чего уже полученный итог положить туда, где у вас в проекте статика хранится?
Spring Boot :) Простите.
Для этого придумали lombok и аннотацию Data
Уверен, вы найдете тут массу народа, который и без всякого OSGi в не маленьких проектах jar-hell не встречает :) Потому что бороться с ним и его симптомами можно многими средствами, от усиленного контроля того, что используется в проекте и до распиливания проекта на микросервисы.
О том, что OSGi проблему не решает четко сказано в том самом докладе о котором речь идет в сабже, если мне не изменяет склероз, то примерно такими словами: «проблему не решает, просто переносит ее на другой уровень». Возможно докладчик не прав, тут сказать ничего не могу.