Я часто видел, что Retrofit используется в android приложениях, но гораздо реже на бэкенде. А на бэкенде, мне кажется, в основном используется Feign. Он и со Spring Cloud интегрирован, что дает клиентскую балансировку и ещё немало фич для взаимодействия сервисов. И мы сделали выбор как раз в его сторону.
Я очень невзлюбил аннотации явы, вот прям сильно. Особенно после того как наткнулся на аннотацию которая по описанию делала одно, а на самом деле была переписана ручками на совсем другое.
А есть пример? Просто очень интересно, что это за аннотация, которая делает не то, для чего она существует или её документация не соотвествует действительности.
Хорошо подходит для копипаста новичками, плохо для осознания что там вообще происходит.
Ну скажем так, по такому корпоративному монстру как Спринг десятки книг и как по мне — хорошая или как минимум неплохая документация. А в ней как раз то, что нужно для осознания того, как это работает. Само собой там не разъясняются все тонкости, ибо зачем нам как клиентам знать детали реализации, нам важен интерфейс, тем не менее исходники никто не закрывал. Те вещи что в гайдах — зачастую давольно простые и спокойно гуглятся, как мне кажется, при желании.
Дальше, я думаю, немного оффтоп. Вы спросили стоит ли изучать такого монстра как Спринг и на аргументы против(монстр, у которого оверхэд больше чем пользы), я постарался привести обратные аргументы. Экосистема Спринга огромная, солидное коммьюнити, он протестирован в бою сотнями больших компаний и не сильно, и изучать его не так страшно, как вам кажется.
Если честно, то меня смутил один факт, что программист, которому что-то интересно, пугается сложности изучить это, и, не изучив, пытается сказать, что на самом деле и изучать не стоит, оперируя домыслами. А были бы у вас факты, значит вы осилили изучить достаточно много, чтобы этого уже и не боятся.
Только hibernate Легко даст вам 100-200% к запросам.
Не уверен, что хоть кто-то бы использовал данный инструмент, если бы были такие показатели. Однозначно есть оверхэд, но не столь критичный, зато в связки со спринг дата, очень даже полезная вещь, и на раннем этапе разработки позволяют практически избавиться от запросов, которые есть в 99% процентов проектов(Crud, пагинация) + есть генерация запросов через сигнатуру метода(и это не магия, просто парсинг название метода согласно чётким правилам). А если просели в производительности, пишите native запросы и будет вам счастье.
Да но знать что оно внутри делает очень хочу я, а документация прям не понравилась, а гугление сильно осложняют тонны фуфловых howto
Что касается "фуфловых howto", то есть целый блок гайдов с примерами кода(+ссылки на исходники, чтобы самим запустить и поиграться) на многие темы(от "как запустить с бд и рестом" до построения микросервисов с каким-либо брокером сообщений) на официальной страницы фреймворка и мне совсем не понятно, что вам надо ещё, чтобы вам понравилось. Если внутренности интересны, то есть стрим Евгения Борисова(кого-же ещё), где с нуля пишут DI механизм спринга. У Спринг большая история и конечно скопилось кучу гайдов разной степени поршивости. Но в основном, для начального этапа опытному программисту не составим труда написать простое приложение, а уже потом находить интересные механизмы и изучать их более предметно, а бывает, что люди так и остаются на поверхностом знании и чувствуют себя отлично, многие энтерпрайзы так живут и ничего.
Не вижу явного недостатка у спринга в отличии от X и я уверен, что при текущем подходе, вы столкнетесь с проблемами на любом другом фреймворке или технологии, потому что всегда придется копаться, читать кучу полезных и не очень how-to, ломать голову как это реализовано внутри и потратить кучу времени на изучение, чтобы понять, что никакой магии не существует.
Да, можете дописать что угодно, это обычный статический класс. Тут так же как и с любым паттерном программирования, т.е это скорее «набросок» того как можно решать такие проблемы, нежели готовая «картина».
Ну справедливости ради, ещё бы дать определение что такое «прозрачный и очевидный код». Здесь скорее зависит от программиста, совокупность его профессиональных навыков и опыта, исходя из этого, любой код становится очевиднее или нет. В любом случае вы можете и не использовать аннотации. Станет ли тогда код более читаемым? Не уверен.
… во вторых магия аннотация меня лично просто убивает.
На самом деле, даже для не особо подготовленных спецов по java, это давно уже не магия. Очень много докладов и материалов на эту тематику (например Евгения Борисова, есть стрим где он, в формате лайфкодинга, создавал спринг «на коленке»), которые вдоль и поперек говорят об этой «магии». Было бы желание разобраться.
Я часто видел, что Retrofit используется в android приложениях, но гораздо реже на бэкенде. А на бэкенде, мне кажется, в основном используется Feign. Он и со Spring Cloud интегрирован, что дает клиентскую балансировку и ещё немало фич для взаимодействия сервисов. И мы сделали выбор как раз в его сторону.
А есть пример? Просто очень интересно, что это за аннотация, которая делает не то, для чего она существует или её документация не соотвествует действительности.
Ну скажем так, по такому корпоративному монстру как Спринг десятки книг и как по мне — хорошая или как минимум неплохая документация. А в ней как раз то, что нужно для осознания того, как это работает. Само собой там не разъясняются все тонкости, ибо зачем нам как клиентам знать детали реализации, нам важен интерфейс, тем не менее исходники никто не закрывал. Те вещи что в гайдах — зачастую давольно простые и спокойно гуглятся, как мне кажется, при желании.
Дальше, я думаю, немного оффтоп. Вы спросили стоит ли изучать такого монстра как Спринг и на аргументы против(монстр, у которого оверхэд больше чем пользы), я постарался привести обратные аргументы. Экосистема Спринга огромная, солидное коммьюнити, он протестирован в бою сотнями больших компаний и не сильно, и изучать его не так страшно, как вам кажется.
Если честно, то меня смутил один факт, что программист, которому что-то интересно, пугается сложности изучить это, и, не изучив, пытается сказать, что на самом деле и изучать не стоит, оперируя домыслами. А были бы у вас факты, значит вы осилили изучить достаточно много, чтобы этого уже и не боятся.
Не уверен, что хоть кто-то бы использовал данный инструмент, если бы были такие показатели. Однозначно есть оверхэд, но не столь критичный, зато в связки со спринг дата, очень даже полезная вещь, и на раннем этапе разработки позволяют практически избавиться от запросов, которые есть в 99% процентов проектов(Crud, пагинация) + есть генерация запросов через сигнатуру метода(и это не магия, просто парсинг название метода согласно чётким правилам). А если просели в производительности, пишите native запросы и будет вам счастье.
Что касается "фуфловых howto", то есть целый блок гайдов с примерами кода(+ссылки на исходники, чтобы самим запустить и поиграться) на многие темы(от "как запустить с бд и рестом" до построения микросервисов с каким-либо брокером сообщений) на официальной страницы фреймворка и мне совсем не понятно, что вам надо ещё, чтобы вам понравилось. Если внутренности интересны, то есть стрим Евгения Борисова(кого-же ещё), где с нуля пишут DI механизм спринга. У Спринг большая история и конечно скопилось кучу гайдов разной степени поршивости. Но в основном, для начального этапа опытному программисту не составим труда написать простое приложение, а уже потом находить интересные механизмы и изучать их более предметно, а бывает, что люди так и остаются на поверхностом знании и чувствуют себя отлично, многие энтерпрайзы так живут и ничего.
Не вижу явного недостатка у спринга в отличии от X и я уверен, что при текущем подходе, вы столкнетесь с проблемами на любом другом фреймворке или технологии, потому что всегда придется копаться, читать кучу полезных и не очень how-to, ломать голову как это реализовано внутри и потратить кучу времени на изучение, чтобы понять, что никакой магии не существует.
Да, можете дописать что угодно, это обычный статический класс. Тут так же как и с любым паттерном программирования, т.е это скорее «набросок» того как можно решать такие проблемы, нежели готовая «картина».
На самом деле, даже для не особо подготовленных спецов по java, это давно уже не магия. Очень много докладов и материалов на эту тематику (например Евгения Борисова, есть стрим где он, в формате лайфкодинга, создавал спринг «на коленке»), которые вдоль и поперек говорят об этой «магии». Было бы желание разобраться.