В общем, вы должны избегать удаления полей без предупреждения, чтобы избежать точного сценария, который вы описываете.
По мере развития вашей схемы, нередки случаи, когда некоторые поля больше не нужны.Например, вместо того, чтобы вносить радикальные изменения в определенное поле (переход от обнуляемого к ненулевому типу возврата, добавление обязательных аргументов и т. Д.), Мы можем выбрать добавление другого поля и рекомендовать клиентам переходить на использование этого поля.вместо.В таких сценариях мы хотим в конечном итоге удалить исходное поле.Самый безопасный способ сделать это - сначала осудить поле.Используя SDL, мы можем сделать это с помощью директивы:
fieldA: String @deprecated(reason: "Use fieldB instead!")
Через некоторое время вы можете полностью удалить это поле.Сколько времени вы ждете, чтобы удалить поле, зависит от вашей команды и ожиданий, которые вы связали с обработкой устаревших полей.Например, может оказаться полезным установить крайний срок, к которому все клиенты, как ожидается, прекратили использовать любые устаревшие поля.Это работает хорошо, если у ваших клиентских команд есть пропускная способность для обработки такого технического долга.
Преобразователь устаревшего поля можно изменить, чтобы он возвращал нулевое значение (если само поле обнуляемо) или некоторые минимальные фиктивные данные.Это предотвращает ненужные вызовы API или базы данных, в то же время гарантируя, что клиентские запросы не приведут к ошибке.
В контексте вашего вопроса это означает, что вам, вероятно, следует избегать отката к предыдущему выпуску и вместо этого следоватьописанный выше процесс для полей, которые вы хотите удалить.
В качестве альтернативы, вы можете рассмотреть возможность создания версий.GraphQL, как правило, уклоняется от концепции управления версиями.Как объясняет официальный сайт:
Почему большинство API-версий?Когда существует ограниченный контроль над данными, возвращаемыми из конечной точки API, любое изменение может считаться критическим изменением, а для критических изменений требуется новая версия.Если для добавления новых функций в API требуется новая версия, возникает необходимость в компромиссе между частым выпуском и наличием множества инкрементных версий по сравнению с понятностью и удобством обслуживания API.
В отличие от этого, GraphQL возвращает только те данные, которые были запрошены явно.Таким образом, новые возможности могут быть добавлены через новые типы и новые поля в этих типах, не создавая принципиальных изменений.Это привело к общепринятой практике - всегда избегать внесения изменений и обслуживать API без версий.
Имея это в виду, также возможно реализовать реализацию версий с помощью GraphQL, обслуживая различные схемы с разных конечных точек.Хотя идти по этому пути дорого и обычно не нужно, это может быть правильным решением для вас и вашей команды, особенно если вы ожидаете, что в будущем придется сделать аналогичные откаты.