Как понять суть spring

Спринг - это не комбайн, это очень легковесный механизм для создания комбайнов )))

Там в ядре всего несколько основных вещей, которые надо понять, и все остальное понимание придет автоматически

Если захочешь пойти по этому пути - задайся вопросом, как работают его корные механизмы. Благодаря чему в @Autowired поле что-то появляется? Кто и почему запускает @PostConstruct? В каком порядке отрабатывают аннотации?

Spring - это очень глубокая вещь, которая позволяет делать удивительные вещи.

Удивительным, мать его, образом 8)

Меня тут на днях спросили как в DSL, который используется для генерации запросов по именам методов репозиториев, добавить своё ключевое слово. Это очень глубоко, кстати.

Ента же ява: леса ентерпрайз едишен, секурити енаблед подпорка сустем, ноу даунтайм 'ребут да факин аппликеишн сервер' патчинг систем и, вообще, робаст энд продактив 'ну наконец запохало'.

Spring - это очень глубокая вещь, которая позволяет делать удивительные вещи. Ее стоит изучать, и в результате - ты сможешь делать крутые вещи и получать за это огромные бабки

Психическое здоровье дороже...

Spring - это очень глубокая вещь, которая позволяет делать удивительные вещи. Ее стоит изучать, и в результате - ты сможешь делать крутые вещи и получать за это огромные бабки

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

Я тоже об этом думал. Но это очень сложно, потому что всё остльное еще хуже.

А по микросервисам что? Если не брать во внимание расходы на передачу/(де)сериализацию? Нашел кусок говна, сел переписал за вечер.

Причем спринг и микросервисы?) Микросервисы на то и микросервисы, что можно их на чем угодно делать

Я делал микросервисы на Spring Cloud Netflix (Eureka, Hystrix итп). Но чтобы тебе эти вещи понадобились, до этого нужно дойти. Советвую что-нибудь почитать по теме вначале

А по микросервисам что?

тотже спринг унутри, зачастую. Плюс гимор оркестрации и дикие накладные расходы (когда оказывается, что микросервис должен дёргать другой микросервис, лол).

тотже спринг унутри, зачастую.

Ну да. Но он как бы «одноразовый». Можно просто взять, выкинуть и переписать за вечер.

Плюс гимор оркестрации и дикие накладные расходы

Ну это - да, продумывать надо.

Можно просто взять, выкинуть и переписать за вечер.

Ну-ну. За 4 человекогода. И то, если крыша не уедет.

Кого, спринг? Я имею ввиду микросервис на спринге.

А микросервис ты перепишешь на что? На свой DI фреймворк?

Да хоть еще раз на спринг. Какая разница?

Вот именно, какя разница будет? Зачем переписывать?

Был старый нерабочий/не понятный говнокод от ушедшего сотрудника, стал новый, рабочий/понятный, от работающего.

Кто мешает также сделать без микросвервисов?

Никто. Но если не будет собираться один большой проект, это будет печальнее, чем один микросервис.