большие монолиты\просто еще никто не написал\не нужно ?
чем шире абстракция, тем лучше она течет (с) Зачем /* очень обобщенный */ фреймворк, если есть кубики из которых можно построить что угодно и под конкретный бизнес кейс?
Так рассуждая, можно и ОС выкинуть
С первым утверждением согласен. По второй части есть два основных аргумента (мой опыт, понятное дело, YMMV) 1. Первую версию продукта прроще и быстрее делать на монолитном обобщенном фреймворке. 2. Часто наблюдаю ситуацию, когда половину времени разработки занимает выбор очередного ”кубика” и поиск специалистов которые умеют с ним работать.
1. Если вы про стадию PoC/MVP - можно и язык другой выбрать, например; 2. А какова цель разработки в этом случае? Попробовать или писать уже конкретный продукт по тз/спеке?
1. Можно, но это пет-проект, мне на Го интересно. Особенно после того как оценил размер финального докер контейнера и того что не нужно больше париться с зависимостями. 2. Первое, но я хотел избежать микросервисов.
Если это пет проджект, то цель - научиться чему-то, верно? Поэтому “половину времени разработки занимает выбор очередного ”кубика” и поиск специалистов которые умеют с ним работать” - время, которое вы инвестируете в себя (не очень понятно зачем тогда искать специалистов, можно познать пару новых кубиков, хоть и поверхностно).
В чем проблема размера докера ?
пару мегабайт против пары сотен мегабайт.
А проблема в чем если докер кэширует на уровне слоев ?
В том что слоев обычно штук 10-15 и они не независимые, в том что загрузка в ECR занимает много времени при плохом соединении, в зависимостях и т.п.
Обсуждают сегодня