Comments 28
Отсюда вопрос: он стоит того? Не могу придумать почему бы мне не накидать пачку сервисов без какого либо фреймворка.
Победивший дракона сам становится драконом :)
А так посмотрите в сторону Vert.x или Quarkus. Легковестные, асинхронные фреймворки.
Последний умеет в native (GraalVM).
Не скажу, что они очень простые — асинхронная парадигма накладывает свой отпечаток. Но после них использовать спринг у меня нет никакого желания.
За наводку спасибо я гляну, но последний раз когда смотрел легковесный Spark мне мой отче, который всю жизнь пишет на яве задал очень простой вопрос: «а нафига он вообще нужен» и я знаете ли тоже не увидел, потому как простая маршрутизация на основе структуре проекты + jsp + само приложение и все работает.
Если у вас есть возможность справиться с нагрузкой в синхронном исполнении логики, то так и делайте.
Если же количество запросов велико и вы уже получаете отлупы по таймаутам, то асинхронка может вам помочь.
Также она позволяет экономить на пямяти и на физических ядрах.
Это всё, конечно, если в ваших обработчиках логики есть IO (доступ к БД, сетевые вызовы, работа с файлами и т.д.).
Простой пример. На DigitalOcean базовом тарифе мое простое приложение на SpringBoot 2 даже не могло стартовать пока не включил своп — ядро убивало процесс из-за активного потребления памяти.
Это же приложение на Vert.x стартовало в 20 раз быстрее и потребляло всего 80Мб (против 300Мб спринговых).
Конечно, можно до бесконечности тюнить спринг. Но мне проще просто его не успользовать.
Конечно, можно до бесконечности тюнить спринг. Но мне проще просто его не успользовать
Дак в том и вопрос, чего такого он делать то позволяет?
Ну серьезно, что у нас обычно есть? Десериализация с гидрацией, затем это пихаем в сервис где тыкаем ACL и прогоняем через проверки бизнес логики, дальеш суем в базу, отрабатываем от нее ответ и наружу, все.
По сути самое сложное тут как раз сериализация/де и обогащение объектов.
В спринге куча архитектурного легаси еще с времен, когда альтернатив не существовало, и в спринг пихали поддержку вообще всего.
Буквально для всего — первый релиз был в начале 2000х, когда Java сама по себе (все еще) рождалась в муках, и как раз в это время зарождался веб в его современном виде. Были наколенные поделки разной степени пахучести, J2EE в лице танков вроде WebSphere, на фоне которых спринг просто пушинка. Запрос был в основном со стороны энтерпрайз-заказчиков, которым уже сказали про "стабильную работу под невероятной нагрузкой", но подкрепление сказанного на практике либо сильно отставало от теории, либо жрало ресурсы серверов и деньги на поддержку.
Стоит.
Аргументы?
Java — Spring must have
Не аргумент. Меня интересует практическая сторона.
го знание сильно повышает востребованность на рынке труда и ЗП
Тоже не интересно.
Спринг сейчас ИМХО спрашивают в двух случаях — если надо что-то спринговое саппортить, и если заказчик больше ничего не знает. Если же таких ограничений нет — те же Vert.x + Dagger будут сильно проще в старте, поддержке и нагрузке на рантайм.
Будем почитать. Пробежался пока глазами по доке, пока не понял что сие за зверь)
У мну ситуевина примерно следующая: приложение реального времени, jsonRPC / REST, PostgreSQL, http / websockets, клиент с сервером обменивается объектами разной степени наполненности, блокировки на уровне приложения.
Все, что касается веба, скармливается в Vertx. БД реализуется отдельно, вместе с необходимыми блокировками — тут можно хоть поверх хибера все реализовать, хоть напрямую в JDBC (это сделано из-за большего, чем раньше, выбора хранилищ — SQL, NoSQL, Graph, FS...). Dagger — легковесный DI, чтоб все это хозяйство не болталось вразброд по проекту. Сериалайзеры соответственно берутся по вкусу.
ЗЫ Блокировки все таки на уровне приложения волнуют а не на уровне бд, тут немного другое.
Я к тому, что механизм транзакций хранилища не входит в комплект к вертексу (поскольку зачем он там нужен), и либо пишется отдельно, либо берется из ORM, или что там в комплекте к базе рекомендуется.
Для JSON можно взять https://github.com/FasterXML/jackson, по скорости и нетребовательности у меня на проекте претензий нет.
Во всех серьезных вакансиях по Java
В любую среднестатистическую галеру
Spring меня пугает до жути, во первых своей магией на изучение которой нужно потратить ну совсем неразумное количество времени, да и не так то это просто, во вторых каким то совершенно нереальных оверхедом.
На самом деле, не так всё страшно. Во-первых, для разработки проекта средней сложности понадобится очень мало «магических» классов Spring Boot, он сейчас как конструктор — на initializr выбираем, что нам понадобится, и все работает сразу на очень разумных умолчаниях, а что не нравится — то можно конфигить.
Изучать его тоже не нужно «неразумное количество времени», особенно если учесть экономию по сравнению с ручным написанием простейшего бойлерплейта.
Насчет оверхеда: он есть, да, но не «нереальный», поскольку большинство спринговой магии превращается в код на этапе компиляции, и не очень лапшистый, так что и этим можно пренебречь.
Изучать его тоже не нужно «неразумное количество времени», особенно если учесть экономию по сравнению с ручным написанием простейшего бойлерплейта
Как раз написание кода обычно занимает не так много времени.
он есть, да, но не «нереальный»,
Только hibernate Легко даст вам 100-200% к запросам.
для разработки проекта средней сложности понадобится очень мало «магических»
Да но знать что оно внутри делает очень хочу я, а документация прям не понравилась, а гугление сильно осложняют тонны фуфловых howto
Только hibernate Легко даст вам 100-200% к запросам.
Не уверен, что хоть кто-то бы использовал данный инструмент, если бы были такие показатели. Однозначно есть оверхэд, но не столь критичный, зато в связки со спринг дата, очень даже полезная вещь, и на раннем этапе разработки позволяют практически избавиться от запросов, которые есть в 99% процентов проектов(Crud, пагинация) + есть генерация запросов через сигнатуру метода(и это не магия, просто парсинг название метода согласно чётким правилам). А если просели в производительности, пишите native запросы и будет вам счастье.
Да но знать что оно внутри делает очень хочу я, а документация прям не понравилась, а гугление сильно осложняют тонны фуфловых howto
Что касается "фуфловых howto", то есть целый блок гайдов с примерами кода(+ссылки на исходники, чтобы самим запустить и поиграться) на многие темы(от "как запустить с бд и рестом" до построения микросервисов с каким-либо брокером сообщений) на официальной страницы фреймворка и мне совсем не понятно, что вам надо ещё, чтобы вам понравилось. Если внутренности интересны, то есть стрим Евгения Борисова(кого-же ещё), где с нуля пишут DI механизм спринга. У Спринг большая история и конечно скопилось кучу гайдов разной степени поршивости. Но в основном, для начального этапа опытному программисту не составим труда написать простое приложение, а уже потом находить интересные механизмы и изучать их более предметно, а бывает, что люди так и остаются на поверхностом знании и чувствуют себя отлично, многие энтерпрайзы так живут и ничего.
Не вижу явного недостатка у спринга в отличии от X и я уверен, что при текущем подходе, вы столкнетесь с проблемами на любом другом фреймворке или технологии, потому что всегда придется копаться, читать кучу полезных и не очень how-to, ломать голову как это реализовано внутри и потратить кучу времени на изучение, чтобы понять, что никакой магии не существует.
что никакой магии не существует.
Я очень невзлюбил аннотации явы, вот прям сильно. Особенно после того как наткнулся на аннотацию которая по описанию делала одно, а на самом деле была переписана ручками на совсем другое.
«как запустить с бд и рестом»
Хорошо подходит для копипаста новичками, плохо для осознания что там вообще происходит.
Если внутренности интересны, то есть стрим Евгения Борисова
А вот это интересно, спасибо
что при текущем подходе, вы столкнетесь с проблемами на любом другом фреймворке или технологи
Не всегда понятно зачем брать таких монстров, да они хороши для прототипов, но если мы пишем руками SQL запрос или скажем пользуем какойнить hasura.io то пол фреймворка уже отвалилось. А что нам по сути нужно? простейший роутер, сериализатор, пачка сервисов, все. Ну di контейнер в лучшем случае. Упрощенно конечно, но борьба с большим фреймворками — вот это часто проблема.
А технологии… скажем так я убежден что часто их переоценивают. Скажем тот же RabbitMQ сейчас любят сувать везде и по любому поводу, но если задуматься: мы выполняем сложную транзакцию в бд, пишем кучу данных, контроль констистентности и все дела, возможно даже serializable изоляций, а потом мы решаем взять и часть процесса вывести из под транзакции кинув в сервер очередей. Но, простите, почему не поставить маркер в той же бд? Причем на моих глазах кролика убивали не раз с полной потерей данных очереди. Моя не понимать этого
Не уверен, что хоть кто-то бы использовал данный инструмент, если бы были такие показатели.
Я вас умоляю, да половина веба работает на кешах. Битрикс вон без кеша вообще шевелится неспособен
Я очень невзлюбил аннотации явы, вот прям сильно. Особенно после того как наткнулся на аннотацию которая по описанию делала одно, а на самом деле была переписана ручками на совсем другое.
А есть пример? Просто очень интересно, что это за аннотация, которая делает не то, для чего она существует или её документация не соотвествует действительности.
Хорошо подходит для копипаста новичками, плохо для осознания что там вообще происходит.
Ну скажем так, по такому корпоративному монстру как Спринг десятки книг и как по мне — хорошая или как минимум неплохая документация. А в ней как раз то, что нужно для осознания того, как это работает. Само собой там не разъясняются все тонкости, ибо зачем нам как клиентам знать детали реализации, нам важен интерфейс, тем не менее исходники никто не закрывал. Те вещи что в гайдах — зачастую давольно простые и спокойно гуглятся, как мне кажется, при желании.
Дальше, я думаю, немного оффтоп. Вы спросили стоит ли изучать такого монстра как Спринг и на аргументы против(монстр, у которого оверхэд больше чем пользы), я постарался привести обратные аргументы. Экосистема Спринга огромная, солидное коммьюнити, он протестирован в бою сотнями больших компаний и не сильно, и изучать его не так страшно, как вам кажется.
Если честно, то меня смутил один факт, что программист, которому что-то интересно, пугается сложности изучить это, и, не изучив, пытается сказать, что на самом деле и изучать не стоит, оперируя домыслами. А были бы у вас факты, значит вы осилили изучить достаточно много, чтобы этого уже и не боятся.
А есть пример? Просто очень интересно, что это за аннотация, которая делает не то, для чего она существует или её документация не соотвествует действительности.
Ну чужой код я точно сюда не кину)
которому что-то интересно, пугается сложности изучить это
Не пугается что вы, но стоит ли оно того не может решить это да. У меня еще не на все вопросы есть идеальные ответы, есть чем занятся) А это на ближайшее будущее развлечение, буквально в ближайшие полгода-год надо проект снимать с php и отправлять на нормальный язык уже.
Я очень невзлюбил аннотации явы, вот прям сильно. Особенно после того как наткнулся на аннотацию которая по описанию делала одно, а на самом деле была переписана ручками на совсем другое.
Это уже не проблема аннотаций, а документации. Да и всегда можно пройтись дебагом даже в магии аннотаций (которая на самом деле, как правило, всего лишь проксирование), и в исходниках покопаться. А уж в Спринге с этим хорошо дело обстоит — и с документацией, и с качеством кода.
Не всегда понятно зачем брать таких монстров, да они хороши для прототипов, но если мы пишем руками SQL запрос...
Как раз Спринг не полновесный монстр и его вполне можно есть по очень небольшим частям — беря нужное и не затаскивая ненужное. Плюс, несмотря на обширную кодовую базу, количество кода, выполняемое в рантайме («путь» запроса) не столь велико. Стоит напомнить, что много и «легкого» и «тяжелого» энтерпрайза написано на Спринге и отлично себя чувствует. А если тормозит ORM, есть отличная легковесная обертка над JDBC в лице JdbcTemplate
А технологии… скажем так я убежден что часто их переоценивают.А точнее пихают их туда, где они являются пушкой по воробьям. Надо четко понимать, где
Я вас умоляю, да половина веба работает на кешах.Не все способно адекватно закешироваться. Универсальный рецепт — оптимизируем не все, а только узкие места.
Не уверен, что хоть кто-то бы использовал данный инструмент, если бы были такие показатели. Однозначно есть оверхэд, но не столь критичный, зато в связки со спринг дата, очень даже полезная вещь, и на раннем этапе разработки позволяют практически избавиться от запросов, которые есть в 99% процентов проектов(Crud, пагинация) + есть генерация запросов через сигнатуру метода(и это не магия, просто парсинг название метода согласно чётким правилам). А если просели в производительности, пишите native запросы и будет вам счастье.
попробуйте jooq + hikari разница оч серьезная
У меня вопрос: вы говорите «Если выбрать AspectJ и корректно его настроить, то при компиляции будет сгенерирован код так, что тело метода будет уже обернуто кодом, управляющим транзакцией». Я правильно понимаю, что в этом случае не будет проблем с вложенными транзакциями из самого популярного вопроса на собеседованиях, поскольку я так понимаю, что как таковых прокси при старте приложения создаваться не будет, а вплетение будет происходить на этапе компиляции?
И сразу второй вопрос: как по правильному решать проблему вложенных транзакций в спринге? Если честно я у себя делаю так как советовал Евгений Борисов в одном из своих puzzler-ов несколько лет тому назад (там с собственной аннотацией @SelfAutowired и написанием своего BeanPostProcessor, который делает инъекцию прокси объекта со всеми необходимыми обертками). Может с того времени что то поменялось?
Насчёт первого вопроса — он хорошо рассмотрен в статье https://habr.com/ru/post/347752/, но в целом вы правы — проблема уйдет, но нужно не забыть добавить aspectj как annotation processor (рабочий пример можно посмотреть https://habr.com/ru/post/347752/ ).
Насчёт второго вопроса — пока ничего нет, да и навряд ли будет))
@Transactional в Spring под капотом