Comments 8
Интересно, чем автору не угодил подход с использованием OpenAPI? Неужели настолько интереснее городить троллейбус из буханки, используя bit или что-то подобное? )
И предложение использовать BFF для решения проблемы - тоже, мягко говоря, достаточно странное: BFF - он, как бы, вообще не про это. Да и решением это трудно назвать: имели одну проблему - синхронизацию типов api фронта и бэка, получили две проблемы - синхронизацию типов api фронтенд-bff и bff-бэкенд.
Мне тоже такой подход кажется оверхедом. В микросервисах на NodeJS имхо намного проще пакет выпустить и поддерживать, чем тянуть стороннего провайдера.
С другой стороны - было интересно рассмотреть альтернативный способ, пусть и немного наркоманский :)
Альтернативой может быть graphql
Иначе клиентский код сильно пострадает при получении несовместимых данных
Если не доверять бекенду (как и пользовательскому вводу) - то не пострадает.
Затем вы можете обратиться к клиентам, чтобы они обновили код.
Этот шаг (шаг оповещения) присутствует всегда в том или ином виде, независимо от способов "шаринга типов/моделей". И также всегда присутствует последующий шаг - "поправить фронт согласно новой модели".
Если придерживаться принципа DRY
dry в теме статьи не работает, т.к. при обновлении типов\модели - общее количество телодвижений разработчиков меньше не становится.
Статья проблему не раскрывает. Вот у нас есть фронт, есть промежуточный бэк на ноде и есть ядро на Java. Следуя статье, пока у нас нода - все ок. Но как только в игру вступает что-то другое(наша Java) - уже нет. Выше в комментарии написали про openApi и это хорошее решение. Мы именно так и пошли.
Совместное использование типов TypeScript между Backend и Frontend