позвольте мне просто избавиться от этого, я люблю graphql, он щелкнул для меня, как только я прочитал первое сообщение в блоге об этом.

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

в конце концов у меня появилась возможность использовать graphql в проекте, и это было все, на что я надеялся, используя apollo на клиенте, было очень ясно, какие данные нужны каждому компоненту с первого взгляда, мне больше не пришлось копаться в внутренней документации api, чтобы узнать, кем я был или не собираюсь возвращаться.

Если бы все всегда было радуги и бабочек (крик Адаму Левину), хотя я бы, вероятно, не писал этот пост в блоге. когда над проектом работают несколько разработчиков, иногда бывает невозможно отслеживать все. очень легко изменить схему на сервере, не убедившись, что изменение схемы не вызовет ошибок ни в одном из запросов на клиенте. Я думаю, что кто-то однажды сказал что-то о том, что люди совершают ошибки, и это делает вас человеком или что-то в этом роде, я не знаю, graphql предотвращает многие из этих ошибок, но не может действительно предотвратить ситуацию, описанную выше.

моя коллега Кэтрин Томпсон и я изучали, как мы можем предотвратить описанные выше ситуации, и придумали некоторые решения, которые, на мой взгляд, достаточно интересны, чтобы поделиться ими с более широким сообществом, поскольку они определенно помогли нам безопасно и непрерывно развертывать наши приложения.

корень проблемы прост, когда мы развертываем (или когда мы фиксируем, или в 1:19 ночи воскресенья, когда что-то просто разъедает нас, потому что это кажется не совсем правильным, и у нас, вероятно, есть другие проблемы, но прямо сейчас мы просто думаем о схеме graphql, так что отойдите от нас, хорошо), мы хотим знать, что каждый запрос в нашем клиентском приложении может быть корректно разрешен для нашей схемы сервера. с этой целью мы создали набор пакетов, которые могут либо рекурсивно проходить по вложенным каталогам запросов graphql в файлах .graphql, либо по каталогам, содержащим файлы javascript, со встроенными запросами, написанными с использованием библиотеки graphql-tag (он сначала извлечет эти запросы используя небольшую служебную библиотеку, которую мы написали - gql-extract - чтобы сначала проанализировать запросы из помеченных строк шаблона), а затем автоматически сгенерировать тесты для этих запросов по предоставленной схеме приложения.

мы предоставляем этот инструмент в пакете, который позволяет использовать его как javascript api или как интерфейс командной строки, и вы можете найти его здесь: graphql-test-generator.

мы лично используем это на этапе предварительного тестирования для создания тестов, которые затем немедленно запускаются на этапе тестирования npm. это дает нам удобство развертывания, зная, что все запросы, которые потенциально может выполнить наше приложение, безопасны по схеме. вот отрывок из файла package.json, иллюстрирующий наше использование:

{
  "pretest": "gqlTestExtraction -e ./src -o ./test -s    ../server/schema",    
  "test": "npm run lint && tape test/*.js"
}

и вот пример сгенерированных тестов:

const { parse } = require("graphql/language");
const { validate } = require("graphql/validation");
const schema = require("../../tests/schema");
const query = `
    query getUserId {
        user {
            id
        }
    }
`;
const queryAST = parse(query);
const errors = validate(schema, queryAST);
const isValid = !errors.length;
const test = require("tape");
test("getUserId query adheres to application schema", assert => {
 assert.ok(isValid, "getUserId contains no schema errors");
 assert.end();
});;

по умолчанию создается тест с использованием ленточной библиотеки, но вы можете использовать необязательный параметр, чтобы указать на вашу собственную функцию генерации тестов, пример которой можно найти здесь - https://github.com/socialtables/graphql- test-generator / blob / master / tests / test-for-failure.js - в котором мы проверяем, что запрос недействителен, чтобы попытаться предоставить некоторые доказательства того, что библиотека избегает ложных срабатываний. в будущем, если есть интерес, мы можем предоставить значения по умолчанию для нескольких фреймворков вместо того, чтобы заставлять заведомо неуклюжий интерфейс для создания пользовательского теста.

graphql и apollo оказались чрезвычайно продуктивными для нас как компании (и меня как отдельного лица), и я надеюсь, что эти инструменты могут предложить такую ​​же помощь другим, как и моей команде.

в библиотеке определенно есть некоторые недостатки и крайние случаи, поэтому я буду очень признателен, если вы отправите какие-либо проблемы, которые нашли здесь: https://github.com/socialtables/graphql-test-generator/issues