Разве «Выбросили исключение, затем либо наш, либо дефолтный фильтр подберет и подставит ххх код ответа, полезную нагрузку» не будет намного лучше, чем нагружать бизнес логику самостоятельным пробрасыванием данных и требуемого кода ответа с последующим проставлением в объекте ответа?
Привет, схема может быть спорной, пытался максимально сжать, но их в интернете есть, так что можно посмотреть там.
По контрактам был хороший опыт при замене проектов с ормки какой-нибудь на чистые запросы с маппингом, буквально очень удобно. Про логику пользователей не понял, но и сама суть использования репозитория - в получении данных, создании запроса и т.д.
Про третий пункт - ну пример жеж, смысл в описании флоу функции, плюс мнение на реализацию у каждой команды будет свое.
Отличная статья, но не могу себе не позволить шутку: «Не могу читать монолитные статьи, когда переход на микросервисные».
А так, довольно хорошо описаны случаи, когда надо и нет, и по этой теме можно провести ретроспективу: опять просто хайп, который лавиной затянул многие умы разработчиков, как обычно, в общем.
Лично я нашел имбалансный юзкейс для жс бэкенда: мега io и cpu задачи выкинуть куда-нибудь через Кафку или грпс на гошные инстансы, чтоб не словить случаем блок по загрузке на монолите.
Согласен, кашу можно наварить как угодно, но, в случаях использования контрактов можно получить ситуацию, когда человек, захотев прямо сразу менять контракт, может задуматься, что может отсеять плохие решения.
А так, использовать или нет контракты - зависит от команды, как привыкли, или из-за чего проблемы возникают.
Привет, у меня следующее мнение: если мы сидим на стеке того же неста, то придется поддерживать только модули ручного кода, привязывать/отвязывать реализации на либерах, но именно с самим нестом я не видел серьезных изменений к подходу к работе в несте годами, так что некоторые проекты можно понять и что-то изменить с меньшей болью.
Новичкам возможно и не стоит заморачиваться помимо не использования new String(…), а потом вместе с теми же скрытыми классами узнать, когда будет интересно.
Очень жалко серию, от всех четырёх игр получил удовольствие, но самые крутые в плане наратива и сюжета - очень интересная первая часть, и invisible war с её абсолютно реалистичным отношением к главному герою и концовкам.
Но локации MD - самые лучшие, до каждого дома, куда можно зайти, на каждой стене с историей, это действительно круто.
На самом деле, нужно хотя бы знать базу от Тьюринга (царство ему небесное уже как более полувека), иначе можно поддаться на эту всю психологическую уловку для масс.
Разве «Выбросили исключение, затем либо наш, либо дефолтный фильтр подберет и подставит ххх код ответа, полезную нагрузку» не будет намного лучше, чем нагружать бизнес логику самостоятельным пробрасыванием данных и требуемого кода ответа с последующим проставлением в объекте ответа?
Спасибо за разбор, в следующих статья буду более осмысленные примеры делать, проба пера, как говорится)
Годовому фронтендеру уметь работу в кубернетесе 🙈
Привет, схема может быть спорной, пытался максимально сжать, но их в интернете есть, так что можно посмотреть там.
По контрактам был хороший опыт при замене проектов с ормки какой-нибудь на чистые запросы с маппингом, буквально очень удобно. Про логику пользователей не понял, но и сама суть использования репозитория - в получении данных, создании запроса и т.д.
Про третий пункт - ну пример жеж, смысл в описании флоу функции, плюс мнение на реализацию у каждой команды будет свое.
Про исключения не понял проблемы 😞.
Интересно узнать про соотношение, спасибо за рекомендацию)
Отличная статья, но не могу себе не позволить шутку: «Не могу читать монолитные статьи, когда переход на микросервисные».
А так, довольно хорошо описаны случаи, когда надо и нет, и по этой теме можно провести ретроспективу: опять просто хайп, который лавиной затянул многие умы разработчиков, как обычно, в общем.
Лично я нашел имбалансный юзкейс для жс бэкенда: мега io и cpu задачи выкинуть куда-нибудь через Кафку или грпс на гошные инстансы, чтоб не словить случаем блок по загрузке на монолите.
Плюс, если есть БА(прямо как йети) в команде - при некоторых случаях изучения работы кода, контракты помогут.
Согласен, кашу можно наварить как угодно, но, в случаях использования контрактов можно получить ситуацию, когда человек, захотев прямо сразу менять контракт, может задуматься, что может отсеять плохие решения.
А так, использовать или нет контракты - зависит от команды, как привыкли, или из-за чего проблемы возникают.
Привет, у меня следующее мнение: если мы сидим на стеке того же неста, то придется поддерживать только модули ручного кода, привязывать/отвязывать реализации на либерах, но именно с самим нестом я не видел серьезных изменений к подходу к работе в несте годами, так что некоторые проекты можно понять и что-то изменить с меньшей болью.
Отличная статья, хочется увидеть более реальные примеры, а то так на ум ничего не приходит…
Новичкам возможно и не стоит заморачиваться помимо не использования new String(…), а потом вместе с теми же скрытыми классами узнать, когда будет интересно.
Ну вообще не стоит создавать инстансы строк через new, а то можно на тех же проверках типов полететь.
Нашел на мдне ссылочку полезную, где прямо написано, что строка - строковый объект, так что неудивительно, что будут похожие оптимизации.
Строки как объекты
Очень жалко серию, от всех четырёх игр получил удовольствие, но самые крутые в плане наратива и сюжета - очень интересная первая часть, и invisible war с её абсолютно реалистичным отношением к главному герою и концовкам.
Но локации MD - самые лучшие, до каждого дома, куда можно зайти, на каждой стене с историей, это действительно круто.
На самом деле, нужно хотя бы знать базу от Тьюринга (царство ему небесное уже как более полувека), иначе можно поддаться на эту всю психологическую уловку для масс.