Иль>Я бы напротив не стал бы с нуля связываться со Spring Boot. По личному опыту любое нестандартное требование приводит к необходимости ковыряться в исходниках самого спринга. И в этом даже людям с опытом можно увязнуть надолго.
как раз в этом и преимущество популярного инструмента — на любую нестандартную задачу будут сотни и тысячи гвайдов и топиков стековерфлова. всякие орм + рест с простенькой секьюрити вполне докой и гвайдами покрывается.
Здравствуйте, Gt_, Вы писали:
Иль>>Я бы напротив не стал бы с нуля связываться со Spring Boot. По личному опыту любое нестандартное требование приводит к необходимости ковыряться в исходниках самого спринга. И в этом даже людям с опытом можно увязнуть надолго.
Gt_>как раз в этом и преимущество популярного инструмента — на любое нестандартную задачу будут сотни и тысячи гвайдов и топиков стековерфлова. всякие орм + рест с простенькой секьюрити вполне докой и гвайдами покрывается.
Вообще, все обсуждаемые в теме проблемы (миграции БД и их откаты, деплой и его откат и т.д.) имеют в джава энтерпрайзе стандартные типовые надежные и достаточно простые решения, отработанные годами бизнесом, который на этой самой джава энтепрайзе сидит (уже третий десяток лет пошёл). ТС может нанять на месяц джависта и девопсера с корпоративным опытом, они всё под ключ наладят на типовой инфраструктуре, типовыми стандартными инструментами и подходами, напишут инструкцию по сопровождению, и бинго, профит.
Здравствуйте, Иль, Вы писали:
Иль>Я бы напротив не стал бы с нуля связываться со Spring Boot. По личному опыту любое нестандартное требование приводит к необходимости ковыряться в исходниках самого спринга. И в этом даже людям с опытом можно увязнуть надолго.
А какие альтернативы? Спринг бут это 90% жава "рынка". Библиотек, конечно, миллион, но по буту хотя бы есть ответы на все возможные вопросы.
Не, если есть много времени и желания заниматься интересным, я бы даже на com.sun.net.httpserver-е сделал веб-сервер, работающий с базой через JDBC, с кучкой своих велосипедов и итоговым размером жарки в пару сотен килобайтов. Которую потом вполне реально можно в полноценный бинарник преобразовать размеров мегабайтов в 15. Но... Так не делают.
Иль>Gradle + shadow даст JAR со всеми зависимостями, который можно запускать как java — jar myjar.jar . По моему проще некуда.
Ну речь же о том, чтобы сделать веб-сервер, работающий с базой, а не чтобы запустить jar. Исполняемую жарку можно сделать тремя консольными командами примерно, без всяких грэдлов, но цель же не в этом. Это всё технические мелочи. Какая вообще разница, как её запускать. Честно признаться никогда не понимал этой моды. Всё равно скрипт пишут в том или ином виде. Одним параметром больше.
vsb>Ну речь же о том, чтобы сделать веб-сервер, работающий с базой, а не чтобы запустить jar. Исполняемую жарку можно сделать тремя консольными командами примерно, без всяких грэдлов, но цель же не в этом. Это всё технические мелочи. Какая вообще разница, как её запускать. Честно признаться никогда не понимал этой моды. Всё равно скрипт пишут в том или ином виде. Одним параметром больше.
тут же шаравара. не будешь же ты писать скрипт который поставит жаву нужной тебе версии, поломав клиенту весь остальной софт. так что тут достаточно важно как запускать и чего делать если апгрейд скрипты базы выполнились с ошибкой.
Иль>>Я бы напротив не стал бы с нуля связываться со Spring Boot. По личному опыту любое нестандартное требование приводит к необходимости ковыряться в исходниках самого спринга. И в этом даже людям с опытом можно увязнуть надолго.
Gt_>как раз в этом и преимущество популярного инструмента — на любую нестандартную задачу будут сотни и тысячи гвайдов и топиков стековерфлова. всякие орм + рест с простенькой секьюрити вполне докой и гвайдами покрывается.
Парадоксальным образом именно в этом проблема и кроется. Версий спринга — множество. Причём значительные отличия зачастую присутствуют даже в минорных версиях. При этом понять для какой версии и какой конфигурации написано то или иное руководство или дан тот или иной ответ — решительно невозможно.
Я, помнится, мучился примерно день методом тыка пытаясь подобрать решение какой-то проблемы (ЕМНИП я пытался реализовать полноценное логгирование для какой-то RPC-библиотеки). Но у меня так ничего и не получилось. Отчаявшись я полез в исходники, через какое-то время нашёл нужный вид параметра в настройках и методы которые потребовалось переопределить — и всё в итоге заработало как надо. Но я решил проверить — было ли какое-то руководство с упоминанием этого параметра и этого метода. Так вот нет, не было!
С того времени я особо на руководства не надеюсь. Да, какие-то базовые вещи типа @Service @Scope или @Autowired там описаны внятно и с версиями не меняются. Но что-то более или менее специфичное — напрочь отсутствует.
Здравствуйте, Gt_, Вы писали:
vsb>>Ну речь же о том, чтобы сделать веб-сервер, работающий с базой, а не чтобы запустить jar. Исполняемую жарку можно сделать тремя консольными командами примерно, без всяких грэдлов, но цель же не в этом. Это всё технические мелочи. Какая вообще разница, как её запускать. Честно признаться никогда не понимал этой моды. Всё равно скрипт пишут в том или ином виде. Одним параметром больше.
Gt_>тут же шаравара. не будешь же ты писать скрипт который поставит жаву нужной тебе версии, поломав клиенту весь остальной софт. так что тут достаточно важно как запускать и чего делать если апгрейд скрипты базы выполнились с ошибкой.
Жаву не нужно ставить. Жава прекрасно работает из папки, никому не мешая. Просто распространяешь jre рядом со своей программой и всё. Есть и другие способы, к примеру jlink выдергивает из JRE нужные для твоей программы куски, но это уже сложней.
vsb>А какие альтернативы? Спринг бут это 90% жава "рынка". Библиотек, конечно, миллион, но по буту хотя бы есть ответы на все возможные вопросы.
Есть ответы на базовые и/или стандартные вопросы. Есть ответы на некоторые нестандартные вопросы. Но тут уже надо чтобы совпала версия спринга, по которой отвечали и той, которую используешь. А ответов на большинство нестандартных вопросов нет.
vsb>Не, если есть много времени и желания заниматься интересным, я бы даже на com.sun.net.httpserver-е сделал веб-сервер, работающий с базой через JDBC, с кучкой своих велосипедов и итоговым размером жарки в пару сотен килобайтов. Которую потом вполне реально можно в полноценный бинарник преобразовать размеров мегабайтов в 15. Но... Так не делают.
ИМХО спринг часто ошибочно воспринимают как такое самостоятельное универсальное решение. В реальности же помимо самых базовых вещей — (spring core кажется оно называется) — типа позднего связывания через Reflection (что, кстати, не так уж и сложно сделать и без спринга при желании) и т. п. — спринг просто объединяет кучу сторонних библиотек. Но что мешает использовать те же самые библиотеки без спринга? Т. е. не подтягивая кучу ненужных зависимостей через Spring Boot?
Например Srping data прикольная вещь для больших проектов. Но иногда она не нужна. А надо, допустим, исполнить запрос к БД хотя бы через тот же spring jdbc. Так вот spring boot отдельно spring jdbc не подтягивает, а только в комплекте с чем-то монструозным.
vsb>Ну речь же о том, чтобы сделать веб-сервер, работающий с базой, а не чтобы запустить jar. Исполняемую жарку можно сделать тремя консольными командами примерно, без всяких грэдлов, но цель же не в этом. Это всё технические мелочи. Какая вообще разница, как её запускать. Честно признаться никогда не понимал этой моды. Всё равно скрипт пишут в том или ином виде. Одним параметром больше.
Можно, конечно. Но зависимости (а без них что-то писать это уж совсем хардкор) придётся класть рядом. Не всегда это удобно. ИМХО проще переупаковать все зависимости в один jar и его уже класть куда надо, контролировать его версию и запускать простейшей командой.
Здравствуйте, Иль, Вы писали:
vsb>>А какие альтернативы? Спринг бут это 90% жава "рынка". Библиотек, конечно, миллион, но по буту хотя бы есть ответы на все возможные вопросы.
Иль>Есть ответы на базовые и/или стандартные вопросы. Есть ответы на некоторые нестандартные вопросы. Но тут уже надо чтобы совпала версия спринга, по которой отвечали и той, которую используешь. А ответов на большинство нестандартных вопросов нет.
Мой опыт другой, я на все свои вопросы обычно ответы нахожу очень быстро. Редко бывает, что не нахожу. Обычно если хочу очень странного. Порой это признак того, что делаю что-то не так.
Иль>ИМХО спринг часто ошибочно воспринимают как такое самостоятельное универсальное решение. В реальности же помимо самых базовых вещей — (spring core кажется оно называется) — типа позднего связывания через Reflection (что, кстати, не так уж и сложно сделать и без спринга при желании) и т. п. — спринг просто объединяет кучу сторонних библиотек. Но что мешает использовать те же самые библиотеки без спринга? Т. е. не подтягивая кучу ненужных зависимостей через Spring Boot?
Какие библиотеки? Spring MVC/Spring WebFlux это вполне себе самостоятельная библиотека для роутинга. Или взять встраиваемый томкат. Я его пытался без спринга встраивать как-то раз. У меня ещё была стадия непринятия бута. Потом залез в исходники этого самого бута, оценил, сколько они там "клея" написали для того, чтобы этот самый встраиваемый томкат у них заработал, и это было одной из вех моего "принятия" бута.
Иль>Например Srping data прикольная вещь для больших проектов. Но иногда она не нужна. А надо, допустим, исполнить запрос к БД хотя бы через тот же spring jdbc. Так вот spring boot отдельно spring jdbc не подтягивает, а только в комплекте с чем-то монструозным.
Не очень понял, о чём речь. Просто добавляешь spring-jdbc в зависимости и всё, не?
У спринг бута есть два функционала.
Первый функционал это автоконфигурирование спринга. Я раньше писал без бута. Ничего страшного в этом нет, но настройка компонентов требует времени и усилий. Если пишешь огромный монолит на 100 человеколет, то нормально. А если пишешь микросервисы, по 10 штук в год, то эти усилия уже будут занимать измеримый процент, поэтому тут бут себя оправдывает.
Второй функционал это уникальный функционал. К примеру тот же упомянутый встроенный томкат. Там довольно много кода написано. Думаю, и другой функционал есть подобного рода. Хотя можно и без встроенного томката обойтись или таки самому написать что нужно.
При этом ничего не мешает тебе использовать спринг бут там, где ты хочешь и не использовать его там, где ты не хочешь. Как в примере со spring-jdbc. Просто добавь зависимость, сконфигурируй датасорс руками, jdbctemplate-ы и тд. И всё. Бут этому никак не помешает. Или подключай бут со spring data и просто игнорируй его. Он особо кушать не просит. А spring-jdbc в зависимостях уже по-любому будет и сконфигурирован будет автоматом.
Иль>Я, помнится, мучился примерно день методом тыка пытаясь подобрать решение какой-то проблемы (ЕМНИП я пытался реализовать полноценное логгирование для какой-то RPC-библиотеки). Но у меня так ничего и не получилось. Отчаявшись я полез в исходники, через какое-то время нашёл нужный вид параметра в настройках и методы которые потребовалось переопределить — и всё в итоге заработало как надо. Но я решил проверить — было ли какое-то руководство с упоминанием этого параметра и этого метода. Так вот нет, не было!
сопрягать вещи бывает сложно, но это не стандартная задача и уж всяко сопрягать со спрингом много проще, чем с твоими поделками без спринга. понадобиться у него столь же абсурдная задача как нахлобучивать левые логерры, ну наймет спеца. а с велоспедом от Вани никто ни за какие деньги не будет подписываться помочь.
Иль>ИМХО спринг часто ошибочно воспринимают как такое самостоятельное универсальное решение. В реальности же помимо самых базовых вещей — (spring core кажется оно называется) — типа позднего связывания через Reflection (что, кстати, не так уж и сложно сделать и без спринга при желании) и т. п. — спринг просто объединяет кучу сторонних библиотек. Но что мешает использовать те же самые библиотеки без спринга? Т. е. не подтягивая кучу ненужных зависимостей через Spring Boot?
обычно мешает опыт. кто и за какие деньги будет разбираться, что ты там натворил рефлекшеном ?
Иль>Например Srping data прикольная вещь для больших проектов. Но иногда она не нужна. А надо, допустим, исполнить запрос к БД хотя бы через тот же spring jdbc. Так вот spring boot отдельно spring jdbc не подтягивает, а только в комплекте с чем-то монструозным.
расскажи нам чего такого тащит spring-boot-starter-jdbc ?
Коллеги, вы столько всего написали про Джаву, что респект вам и уважение. Но знаний это не добавило )))
Есть желающие в СПб провести небольшой ликбез по этому поводу, можно даже за деньги. Ну, или, за что-нибудь другое, если деньгами не комильфо?
Здравствуйте, sfsoft, Вы писали:
S>Кто что скажет по этому поводу? Есть идеи как лучше сделать и что выбрать?
Может на Go? Будет все ваше приложение — один большой статически слинкованный исполняемый файл. Соответственно, при обновлении он, один, и меняется целиком.
Pzz>Может на Go? Будет все ваше приложение — один большой статически слинкованный исполняемый файл. Соответственно, при обновлении он, один, и меняется целиком.
Здравствуйте, sharez, Вы писали:
Pzz>>Может на Go? Будет все ваше приложение — один большой статически слинкованный исполняемый файл. Соответственно, при обновлении он, один, и меняется целиком.
S>Так и на Java так же.
Но зато, хоть это и вкусовщина, Go — гораздо более приятный язык.
S>Коллеги, вы столько всего написали про Джаву, что респект вам и уважение. Но знаний это не добавило ))) S>Есть желающие в СПб провести небольшой ликбез по этому поводу, можно даже за деньги. Ну, или, за что-нибудь другое, если деньгами не комильфо?
с моей локации на территорию РФ наверно проблематично теперь заехать. лучше распиши в жава топике верхний уровень. верно ли я понял, что серверную часть клиент ставит, что нужны апдейты с базой данных, соответственно что-то изобрести с откатом апдейта. что за база на сервере сейчас ? если чего хитрое, чего в простых гайдах можно и не найти ?
Здравствуйте, Pzz, Вы писали:
Pzz>Но зато, хоть это и вкусовщина, Go — гораздо более приятный язык.
Вообще пофиг на вкус.
Главный вопрос, где программистов искать.
По PHP я могу пойти в ближайшую ночлежку и у меня будет очередь.
По Java я найду людей по объявлению на городском форуме.
А по Go я вообще их в живом виде не видел, наверное в интернете обитают, но вид довольно редкий.
Здравствуйте, vsb, Вы писали:
vsb>Какие библиотеки? Spring MVC/Spring WebFlux это вполне себе самостоятельная библиотека для роутинга. Или взять встраиваемый томкат. Я его пытался без спринга встраивать как-то раз. У меня ещё была стадия непринятия бута. Потом залез в исходники этого самого бута, оценил, сколько они там "клея" написали для того, чтобы этот самый встраиваемый томкат у них заработал, и это было одной из вех моего "принятия" бута.
У меня итог был другой. Я не принял бут, а понял, что "взять встраиваемый томкат" — плохая идея. Есть более вменяемые сервера, которые клеить не надо, две строчки кода и оно работает.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Gt_, Вы писали:
Gt_>лучше распиши в жава топике верхний уровень. верно ли я понял, что серверную часть клиент ставит, что нужны апдейты с базой данных, соответственно что-то изобрести с откатом апдейта. что за база на сервере сейчас ? если чего хитрое, чего в простых гайдах можно и не найти ?
Пока здесь напишу, CTRL+C, CTRL-V можно быстро сделать
СУБД: Firebird
Сервер приложений — это свой веб-сервер, отрабатывающий JSON-RPC запросы от клиентов. Естественно многопоточный, с пулом соединений с СУБД, есть собственная реализации очереди, для долгоиграющих запросов, а также генератор отчётов (а данном случае FastReport, довольно старый, именно он и "течёт" время от времени). Отчётов около 150 и их перевод на тот же birt — долгая затея... Всё это написано на Delphi (используется самая последняя версия, есть подписка на неё). Работает шустро, никто не жалуется.
По установке у пользователей. Чаще всего никаких админов у наших пользователей нет. Да и с компьютером многие из них на "вы". Поэтому работает это всё следующим образом: наш инсталлятор копирует нужные файлы, устанавливает сервис Firebird и создает необходимые ярлыки. Т.е. запустить инсталлятор и нажать несколько раз Далее юзеры могут в большинстве своём.
По обновлениям. При запуске клиентского ПО появляется плашка, что доступна новая версия. Пользователи на своем сервере (хотя обычно это такая же рабочая машина) открывают окно сервера приложений и там жмут кнопку Обновить. Программа скачивает с нашего сайта апдейт в архиве, распаковывает его, затем создает копию рабочей БД и накатывает скрипты обновления. Если всё прошло успешно у текущего exe меняем расширение на bak, а на его место записываем новый exe. И рестартим приложение. Если произошла ошибка во время накатывания скриптов (например, юзеры сунули руки в метаданные БД и что-то сломали), то программа удаляет нерабочую копию БД и восстанавливает рабочую копию из созданной ранее. Как-то вот так всё работает.
Update: сервер приложений сам регистрируется при запуске в Планировщике Windows, поэтому при перезапуске компа он сам запускается. Прав Администратора нигде не требуется, всё работает с правами обычного юзера.
