Откат обновления схемы Graphql
Мы перемещаем некоторые из наших API-интерфейсов в graphql и хотели бы знать, как обрабатывать откат развернутого пакета (схемы) и передовой практики к тому же.
Чтобы быть более конкретным, скажем, у нас есть схема S с 3 полями, а затем мы добавили 4-е поле «A». Сейчас по какой-то причине мы не можем продвигаться вперед с этим пакетом и полем «А». Итак, мы должны выполнить откат пакета, чтобы теперь в схеме не было поля «A».
Теперь какой-то потребитель может запросить в этом поле «А», и он может получить сообщение об ошибке. Конечно, мы могли бы попросить наших клиентов обновить, но есть временной промежуток, в течение которого мы могли бы не выполнить запрос.
Как мы справляемся с этим сценарием, особенно с срочным откатом через несколько часов или день?
Ответы 2
Вы ничего не можете сделать с GraphQL. Поскольку вам нужно, чтобы поле присутствовало в системе типов GraphQL. Могут быть доступны библиотеки, которые позволят вам указать, будет ли поле должен присутствовать в запросе или нет. Но нет возможности разрешить несуществующее поле в запросе.
Но вы можете выбрать стратегию развертывания Цвет морской волны. В этой стратегии обе версии работают одновременно.
Допустим: Зеленый - это версия с полем А, а Синий - это версия без поля A. Поэтому, когда ваши клиенты обновляются, они начинают запрашивать версию Синий. И как только все ваши клиенты будут обновлены, выключите Зеленый (с полем А).
В общем, вам следует избегать удаления полей без предупреждения, чтобы избежать точного сценария, который вы описываете.
По мере развития вашей схемы нередки случаи, когда некоторые поля больше не нужны. Например, вместо того, чтобы вносить радикальное изменение в конкретное поле (переход от типа возвращаемого значения, допускающего значение NULL, к типу возврата, не допускающему значение NULL, добавление требуемых аргументов и т. д.), Мы можем добавить еще одно поле и побудить клиентов перейти к его использованию. вместо. В таких сценариях мы хотим в конечном итоге удалить исходное поле. Самый безопасный способ сделать это - сначала отказаться от поля. Используя SDL, мы можем сделать это с помощью директивы:
fieldA: String @deprecated(reason: "Use fieldB instead!")
По прошествии определенного времени вы можете полностью удалить поле. Как долго вы ждете, чтобы удалить поле, зависит от вашей команды и ожиданий, о которых вы сообщили об обработке устаревших полей. Например, вам может быть полезно установить крайний срок, к которому ожидается, что все клиенты прекратят использовать какие-либо устаревшие поля. Это работает хорошо, пока ваши клиентские команды имеют пропускную способность, чтобы справиться с таким техническим долгом.
Преобразователь устаревшего поля можно изменить, чтобы он возвращал нулевое значение (если само поле допускает значение NULL) или некоторые минимальные фиктивные данные. Это предотвращает ненужные вызовы API или базы данных, но при этом гарантирует, что клиентские запросы не приводят к ошибке.
В контексте вашего вопроса это означает, что вам, вероятно, следует избегать отката к предыдущей версии и вместо этого следовать процессу, описанному выше для полей, которые вы хотите удалить.
В качестве альтернативы вы можете рассмотреть возможность управления версиями. GraphQL обычно избегает концепции управления версиями. Как поясняет официальный сайт:
Why do most APIs version? When there's limited control over the data that's returned from an API endpoint, any change can be considered a breaking change, and breaking changes require a new version. If adding new features to an API requires a new version, then a tradeoff emerges between releasing often and having many incremental versions versus the understandability and maintainability of the API.
In contrast, GraphQL only returns the data that's explicitly requested, so new capabilities can be added via new types and new fields on those types without creating a breaking change. This has led to a common practice of always avoiding breaking changes and serving a versionless API.
Имея это в виду, также возможно реализовать управление версиями с помощью GraphQL, обслуживая разные схемы с разных конечных точек. Хотя идти этим путем дорого и обычно не нужно, это может быть правильным решением для вас и вашей команды, особенно если вы ожидаете, что в будущем вам придется делать аналогичные откаты.
Даже с REST вы можете столкнуться с теми же проблемами. Например, добавление параметров запроса в конечную точку и последующий откат также приведет к увеличению количества клиентских запросов, если у вас настроена проверка запросов.
Если у вас настроена среда разработки и / или промежуточная среда, интеграционное тестирование должно выявить любые серьезные проблемы. Говоря по опыту, когда у нас что-то ужасно шло не так на бэкэнде, это почти всегда обнаруживалось в среде разработки, когда клиентские группы начали интегрировать изменения схемы в свои приложения. Если какие-либо ошибки попадали в рабочую среду, они оказывали довольно незначительное влияние и, конечно же, не требовали отката к более раннему выпуску.
Я разделяю это, потому что, если вам нужно делать откаты в производственной среде, это может указывать на некоторые недостатки во всем рабочем процессе разработки / контроля качества.
Я тоже интересовался этим заявлением об отсутствии версий. Устаревание - хороший метод, но он все равно не меняет факта, если у вас старые клиенты и вы хотите что-то обновить или удалить. Мое определение безверсии должно включать старых и новых клиентов, я просто не понимаю, как это возможно без особой осторожности с изменениями.
Спасибо за предложение. Я ознакомился с лучшими практиками по исключению полей, и ваш ответ также дает хорошую информацию, но меня больше беспокоят некоторые аварийные откаты. Допустим, мы развернулись, и через несколько часов мы понимаем, что что-то пошло не так, и теперь мы откатываемся. В остальном мы просто игнорируем запрошенные поля, которых нет в модели запроса, что может быть не лучшим способом, но все же поддерживает наш API и бизнес. В случае Graphql мы закончим с ошибками, которые станут кошмаром для непрерывности бизнеса.