Не могу сказать, что утверждение "Новее = безопаснее" - верно) В новых версиях иногда, бывает, даже добавляется уязвимостей, тут следует держать баланс между "keep it fresh" и "работает - не трогай", тем более, что довольно редко проект поддерживается вечно. Зачастую устаревшие версии как раз появляются либо в давно забытых легаси, к которым решили вернуться, либо, как вариант, если на конечных стадиях разработки выходят какие-то мажорные обновления из-за которых могут возникнуть проблемы. Сдвигать срок заказчики/инвесторы из-за "ваших этих обновлений" не будут, конечно же, а потом уже как бы "было поздно раньше начинать" обновление действительно превратится в переписывание половины проекта.
Но я даже не об этом всем говорил, скорее о том, что эта статья подходит под что-то вроде "предостережения для новичка", потому, думаю, для начинающих было бы неплохо привести какой-то чек-лист когда обновляться можно и нужно, а когда лучше повременить, особенно если получится с примерами из личного опыта. То есть я хотел сказать, что обновляться бездумно - смэрть. А так, конечно, ничего совершенно не имею против регулярных обновлений, если получается
Совет "Не забывайте обновлять зависимости проекта и используемое ПО" весьма неоднозначный - !!!тем более!!! его автоматизация. Вот буквально на днях в проекте решил так, за-между-прочим обновить спринг, причем там минорные версии, по итогу задача изначально которая была на час, едва не растянулась на весь вечер, потому что эта обнова мне весь мозг вы..несла, из-за обновления зависимостей своего спринга там начали конфликтовать (как я помню) UserType гибернейта с JsonType расширения для всё того же гибернейта и оно кидало ClassCastException и хоть ты кричи) Потому лучше не сильно автоматизировать сие, т.к. пайпа умрет в самый не подходящий момент, а как в моем случае, пайпа бы даже не умерла, т.к. сборка-то проходит, ошибка уже при старте в рантайме, вот это был бы сюрприз)
Тоже самое можно сказать и про ПО на машинке. Если обновится какая-нибудь .dll аля open-ssh, то легко могут отпасть какие-то еще не успевшие обновиться либы (такое тоже иногда случается). Как пример - ruby 2.7 отказывается хоть стреляй работать с новым libssl, при этом обновлять весь проект с 2.7 на актуальную (3.x вроде??), как понимаете, не всегда есть время и бюджет.
В общем и целом совет полезный, но, обновлять нужно понимая что делаешь, иметь запас времени на случай если обнова начнет делать мозг и, самое главное, иметь "План Б-бекап" на случай если уж прям совсем тупик, чтобы откатиться быстро назад без потерь
Вебхук ускоряет, конечно, взаимодействие, так как лонг-пуллинг всё же подразумевает либо однопоточку, либо ручками разбиение на потоки (честно не подробно смотрел код), в то время как хук всё же действует по принципу 1 апдейт - 1 запрос, но учитывая параметры машинки (1 проц 1 ОЗУ) ваше приложение просто не выживет если врубить хуки - с десяток-2 одновременных запросов и пользователи будут ждать ответ до пенсии) Тут нужно машинку тогда подороже брать и, возможно, с обычного спринга на реактивный перейти, думаю тут реактивность как раз зашла бы
Из критики - возможно, конечно, дело привычки, но gradle куда симпатичнее maven (и новее). Да и вместо application.properties лучше .yml использовать, тоже более современный и читаемый формат)
Для конфига бота также можно использовать @@ConfigurationProperties аннотацию и указать "путь" к нему внутри yml, чтобы не писать кучу @@Value
Не могу сказать, что утверждение "Новее = безопаснее" - верно) В новых версиях иногда, бывает, даже добавляется уязвимостей, тут следует держать баланс между "keep it fresh" и "работает - не трогай", тем более, что довольно редко проект поддерживается вечно. Зачастую устаревшие версии как раз появляются либо в давно забытых легаси, к которым решили вернуться, либо, как вариант, если на конечных стадиях разработки выходят какие-то мажорные обновления из-за которых могут возникнуть проблемы. Сдвигать срок заказчики/инвесторы из-за "ваших этих обновлений" не будут, конечно же, а потом уже как бы "было поздно раньше начинать" обновление действительно превратится в переписывание половины проекта.
Но я даже не об этом всем говорил, скорее о том, что эта статья подходит под что-то вроде "предостережения для новичка", потому, думаю, для начинающих было бы неплохо привести какой-то чек-лист когда обновляться можно и нужно, а когда лучше повременить, особенно если получится с примерами из личного опыта. То есть я хотел сказать, что обновляться бездумно - смэрть. А так, конечно, ничего совершенно не имею против регулярных обновлений, если получается
Совет "Не забывайте обновлять зависимости проекта и используемое ПО" весьма неоднозначный - !!!тем более!!! его автоматизация. Вот буквально на днях в проекте решил так, за-между-прочим обновить спринг, причем там минорные версии, по итогу задача изначально которая была на час, едва не растянулась на весь вечер, потому что эта обнова мне весь мозг вы..несла, из-за обновления зависимостей своего спринга там начали конфликтовать (как я помню) UserType гибернейта с JsonType расширения для всё того же гибернейта и оно кидало ClassCastException и хоть ты кричи) Потому лучше не сильно автоматизировать сие, т.к. пайпа умрет в самый не подходящий момент, а как в моем случае, пайпа бы даже не умерла, т.к. сборка-то проходит, ошибка уже при старте в рантайме, вот это был бы сюрприз)
Тоже самое можно сказать и про ПО на машинке. Если обновится какая-нибудь .dll аля open-ssh, то легко могут отпасть какие-то еще не успевшие обновиться либы (такое тоже иногда случается). Как пример - ruby 2.7 отказывается хоть стреляй работать с новым libssl, при этом обновлять весь проект с 2.7 на актуальную (3.x вроде??), как понимаете, не всегда есть время и бюджет.
В общем и целом совет полезный, но, обновлять нужно понимая что делаешь, иметь запас времени на случай если обнова начнет делать мозг и, самое главное, иметь "План Б-бекап" на случай если уж прям совсем тупик, чтобы откатиться быстро назад без потерь
Вебхук ускоряет, конечно, взаимодействие, так как лонг-пуллинг всё же подразумевает либо однопоточку, либо ручками разбиение на потоки (честно не подробно смотрел код), в то время как хук всё же действует по принципу 1 апдейт - 1 запрос, но учитывая параметры машинки (1 проц 1 ОЗУ) ваше приложение просто не выживет если врубить хуки - с десяток-2 одновременных запросов и пользователи будут ждать ответ до пенсии) Тут нужно машинку тогда подороже брать и, возможно, с обычного спринга на реактивный перейти, думаю тут реактивность как раз зашла бы
Из критики - возможно, конечно, дело привычки, но gradle куда симпатичнее maven (и новее). Да и вместо application.properties лучше .yml использовать, тоже более современный и читаемый формат)
Для конфига бота также можно использовать @@ConfigurationProperties аннотацию и указать "путь" к нему внутри yml, чтобы не писать кучу @@Value