Pull to refresh

Comments 8

Интересно, чем автору не угодил подход с использованием OpenAPI? Неужели настолько интереснее городить троллейбус из буханки, используя bit или что-то подобное? )

И предложение использовать BFF для решения проблемы - тоже, мягко говоря, достаточно странное: BFF - он, как бы, вообще не про это. Да и решением это трудно назвать: имели одну проблему - синхронизацию типов api фронта и бэка, получили две проблемы - синхронизацию типов api фронтенд-bff и bff-бэкенд.

Мне тоже такой подход кажется оверхедом. В микросервисах на NodeJS имхо намного проще пакет выпустить и поддерживать, чем тянуть стороннего провайдера.

С другой стороны - было интересно рассмотреть альтернативный способ, пусть и немного наркоманский :)

Альтернативой может быть graphql

Не во все проекты его можно воткнуть, но да

Иначе клиентский код сильно пострадает при получении несовместимых данных

Если не доверять бекенду (как и пользовательскому вводу) - то не пострадает.

Затем вы можете обратиться к клиентам, чтобы они обновили код.

Этот шаг (шаг оповещения) присутствует всегда в том или ином виде, независимо от способов "шаринга типов/моделей". И также всегда присутствует последующий шаг - "поправить фронт согласно новой модели".

Если придерживаться принципа DRY

dry в теме статьи не работает, т.к. при обновлении типов\модели - общее количество телодвижений разработчиков меньше не становится.

Имхо, проблема синхронизации типов идеального решения не имеет, всегда есть какие-то сайд-эффекты

Статья проблему не раскрывает. Вот у нас есть фронт, есть промежуточный бэк на ноде и есть ядро на Java. Следуя статье, пока у нас нода - все ок. Но как только в игру вступает что-то другое(наша Java) - уже нет. Выше в комментарии написали про openApi и это хорошее решение. Мы именно так и пошли.

Мне тоже OpenAPI пока больше всего нравится.

Sign up to leave a comment.

Articles