Рекомендации по управлению сгенерированной схемой graphql в приложениях Typescript

avatar
Charklewis
9 августа 2021 в 01:44
129
1
0

У меня возникли проблемы с выработкой наилучшей стратегии управления сгенерированными файлами graphql. Проблема, с которой я столкнулся, заключается в том, что у нас есть конвейер разработки, который использует докер для создания двух контейнеров, причем один контейнер создает схему на основе первого.

Эти два контейнера представляют собой базу данных Hasura и экспресс-сервер (в Typescript).

Экспресс-сервер использует базу данных hasura для создания схемы и с помощью этого типа проверяет запросы/мутации.

Для управления сгенерированной схемой я пробовал следующие решения.

  1. Когда экспресс-сервер встроен в докер, у него есть функция повтора, чтобы продолжить выборку схемы из базы данных hasura. Разработчики быстро сказали мне, что это ужасная идея иметь зависимости между двумя контейнерами (хотя я действительно не понимаю, почему, когда у них есть законная зависимость друг от друга).
  2. Скомпилируйте машинописный текст на экспресс-сервере без схемы graphql, игнорируя возникающие при этом ошибки. Код машинописного текста скомпилирован в javascript, и он используется во время выполнения, поэтому проверка типов — это только инструмент, используемый для статического тестирования. Это работает, когда Javascript компилируется правильно. Однако ошибки докера, поскольку компилятор машинописного текста выдает ошибку. Я не знаю, как заставить это замолчать.
  3. Отправьте сгенерированную схему на GitHub. Насколько я понимаю, когда вы загружаете сгенерированные файлы, это красный флаг, и его следует избегать. Я могу предвидеть, что это вызовет головную боль, когда вы захотите локально работать со схемами, которые немного отличаются (например, невыпущенные), а также управлять потенциальными конфликтами слияния.

Мне подсказывает, что решение 1 верное. Мои знания о докере очень ограничены, поэтому есть ли правильный способ реализовать это с помощью докера? Или одно из других решений лучше подходит? На данный момент команда реализовала решение 3.

Любые подсказки помощи очень ценятся!

Источник

Ответы (1)

avatar
Greg Ferreri
9 августа 2021 в 15:15
1

Я бы выбрал вариант №3. Отправка сгенерированного кода в исходный репозиторий не всегда рекомендуется, и иногда это правильный курс действий. Рассмотрим, например, файлы блокировки зависимостей (package-lock.json, yarn.lock).

Сгенерированная схема представляет собой моментальный снимок во время разработки, который является контрактом, ожидаемым вашим приложением. Я бы не хотел, чтобы это генерировалось во время CI, потому что это должно быть известно при разработке клиентского кода вашего приложения, который в любом случае зависит от схемы. Обновление схемы должно быть сознательным решением, принимаемым при разработке приложения, а не случайным образом во время конвейера CI/CD.