google cloud run - очень крутая штука, работает как обычный запускальщик docker, но кладет приложение спать не останавливая его, если нет запросов, поэтому cold start бывает быстрым. выходит бесплатно если мало пользуются
https://fly.io/ - тоже изначально бесплатный, как хероку, но типа запускается близко к кастомерам

Я чот сначала даже и не понял что это спам....

никто не видел исследование на тему стоимость open-source vs серивис? суть такая, что даже если продукт open source зачастую чтобы его развернуть и поддерживать надо приложить очень много усилий.

Ну это слишком от проекта зависит, нет смысла такое даже исследовать.

Корректнее будет on-premise vs SaaS

О плюсах последнего обычно у конкретного сервиса преимущества и расписаны

Тут у нас небольшой спор на тему валидаций и где каким место (контроллер/сервис) я сторонник супер тонких контроллеров которые умеют только сериализацию запросов и ответов и дергать методы сервисов. Так сложилось, для меня контроллер один из возможных источников поступления запросов наравне с другими контроллерами, командной строкой и межсервисными вызовами в конце концов. В итоге валидация корректности входящих данных в сервсисе + базе (то есть к примеру я не проверяю наличие того же юзера перед тем как попытаться вставить запись в базу с его id, база это сделает за меня, а я сэкономлю на зависимостях и лишних запросах к базе для таких проверок). Есть тут куда ткнуть пальцем или даже дать по рукам?)

а в чем спор?

а какая по сути разница, если валидация это отдельный инструментарий? где удобно там и вызываешь, может даже и в контроллере и в сервисе, по ситуации

в контроллере можно валидировать что пришло извне, в сервисе уже целостность данных итп

Я бы делал так, чтобы код как можно раньше начинал работать с валидными данными. Но если  речь заходит про производительность то уже делал бы в каждом отдельном кейсе так как быстрее всего будет работать.

Мы используем для сборки бека на скале и деплоймента в кубер, ещё экспериментально админка на ангуляре и сервис на расте. Уже года два как, вполне устраивает. Из минусов - иногда тяжело с документацией (особенно какие-то специфичные рулы), интеграция с идеей для скалы немного отстаёт, для раста вообще не поддерживается

+1 , тоже считаю что чем меньше времени невалидные данные будут в системе - тем лучше. Базовые вещи, которые можно проверять stateless - должны быть прям на входе - собрал данные в модельку - провалидируй что почта нормальная, пароли достаточной сложности, всякие строки не содержат гадостей и т.д. Провалидировал - передавай модельку следующему слою, если там надо чтобы данные соответствовали тому что лежит базе - уже пора сходить и проверить например, что пользователь с таким адресом уже есть в системе, у него там нужные права и все такое. Передаем в бизнес логику уже валидного принципала с ролью или набором прав. Ну и так далее, каждый уровень наслаивает свои проверки и делает передаваемые данные лучше и чище.
Тут всегда можно "увлечься" и засунуть коннект к бд в валидацию модели, но для этого есть другое правило - слой не должен расширять зону своей ответственности ради дополнительных валидаций, он должен только проверять ту целостность, которая нужна для его собственной корректной работы, а не для  корректности получателя данных...

Для меня проверять well-formed email перед вставкой в базу - дико, а то что пользователь с такой почтой еще не существует в таблице - самое то

+1 к пред. сообщению
В целом можно даже юзать validation pattern, который описывает все необходимые проверки данных, но при этом каждый слой вызывает нужны проверки в соответствующем слое

Neural Networks Emulate Any Guitar Pedal for $120 (Score: 150+ in 6 hours)

Link: https://readhacker.news/s/4MGV7
Comments: https://readhacker.news/c/4MGV7

вот это классно на самом деле 🙂 хоть я и не музыкант, но наслышан о задаче 🙂

полностью поддерживаю данный развернутый ответ

С моей точки зрения валидацию все равно придётся дублировать на UI и на сервере (если речь идёт о веб или мобильном приложении). В таком случае валидацию на сервере можно смело переносить в сервис или dao слой. Потому что северная валидация нужна как защита от ошибок разработчиков и мамкиных хакеров.

Если речь про java+spring то можно при невалидных данных кидать нужный тип исключения, и формировать 400 ошибку средствами Спринга. Тогда откуда бы не прошла ошибка валидации, мы все равно сможем отдать адекватную 400ку. В других фреймворках скорее всего есть похожие схемы.

а что за validation pattern?