Здравствуйте, Константин Б., Вы писали:

I>>1 АПИ для фронта меняется не просто часто, а непрерывно — каждая фича или фикс требует чего нибудь особенного. На согласовании далеко не уедешь. Ждать бакендов, пока они раздуплятся и понаделывают роуты, неэффективно.

КБ>Из этого описания складывается впечатление что у вас бакэндеры — это то ли отдельное подразделение, то ли вообще на оутсорсе.
КБ>Они не в курсе текущих требований, заняты чем-то постороним, им кто-то другой выставляет приоритеты и т.д.

Почему ты решил, что я пишу о том, как именно у нас? Можно подробнее?

Как правило, на больших проектах людей слишком много, что бы всех кидать на каждый чендж реквест на фронте.

Более того, бакенд может состоять из нескольких сервисов, со своим собственным релизным циклом, в силу естественных причин. Опять же, специфика больших проектов.

КБ>Если бэкэндеров не держать в курсе дела и не обсуждать с ними проект

Это называется управление изменениями. Тем сложнее, чем больше людей и горизонтальных связей между ними. Количество людей уменьшить не получится, а вот горизонтальные связи порезать можно.

Соответсвенно, нужно решать не пингованием всех подряд "эй, народ, на фронте кнопку подвинуть не могут!!!", а выбором архитектуры, которая даст возможность людям работать автономно, по возможности, убирая горизонтальные зависимости

Всякие "согласования" это старый подход. Новый подход — consumer driven API. для этого часть бакенда должна изначально проектироваться таким образом, что бы позволять частые изменения без конских трудозатрат, и по возможности, проверку всего АПИ простыми тестами и компилятором.
Это работает гораздо лучше "согласований", сваггееров и прочих вещей.

Здравствуйте, Константин Б., Вы писали:

I>>1 АПИ для фронта меняется не просто часто, а непрерывно — каждая фича или фикс требует чего нибудь особенного. На согласовании далеко не уедешь. Ждать бакендов, пока они раздуплятся и понаделывают роуты, неэффективно.

КБ>Из этого описания складывается впечатление что у вас бакэндеры — это то ли отдельное подразделение, то ли вообще на оутсорсе.
КБ>Они не в курсе текущих требований, заняты чем-то постороним, им кто-то другой выставляет приоритеты и т.д.

Почему ты решил, что я пишу о том, как именно у нас? Можно подробнее?

Как правило, на больших проектах людей слишком много, что бы всех кидать на каждый чендж реквест на фронте.

Более того, бакенд может состоять из нескольких сервисов, со своим собственным релизным циклом, в силу естественных причин. Опять же, специфика больших проектов.

КБ>Если бэкэндеров не держать в курсе дела и не обсуждать с ними проект

Это называется управление изменениями. Тем сложнее, чем больше людей и горизонтальных связей между ними. Количество людей уменьшить не получится, а вот горизонтальные связи порезать можно.

Соответсвенно, нужно решать не пингованием всех подряд "эй, народ, на фронте кнопку подвинуть не могут!!!", а выбором архитектуры, которая даст возможность людям работать автономно, по возможности, убирая горизонтальные зависимости

Всякие "согласования" это старый подход. Новый подход — consumer driven API. для этого часть бакенда должна изначально проектироваться таким образом, что бы позволять частые изменения без конских трудозатрат, и по возможности, проверку всего АПИ простыми тестами и компилятором.
Это работает гораздо лучше "согласований", сваггеров и прочих вещей.