Почему вы должны использовать Code First GraphQL Development (NexusJS)

Если вы не знакомы с построением сервера GraphQL, для этого требуются две вещи: преобразователи и определения типов. Проще говоря, преобразователи - это функции, которые выполняют ваши вызовы API, а в определениях типов вы определяете, что входит (аргументы) и что возвращается вашими преобразователями, а затем они объединяются для создания вашей схемы GraphQL.

Стандартный способ создания этих двух вещей - записать определения типов, например, сказать, что у меня есть один запрос, который вернет всех моих пользователей, которые являются объектами с именем пользователя (string), id (Int) и одной мутацией в изменить имя пользователя пользователя.

Написание определений типов в GraphQL выглядит так

Это называется разработкой Schema-First. Затем вы должны написать один преобразователь / функцию на Javascript или Python и т. Д., Чтобы возвращать ваших пользователей из БД, а другой - для обновления пользователя.

Что в этом плохого?

Ничего, когда проект только начинается, и я по-прежнему предпочитаю сначала схему, а не разработку с помощью REST API. Сначала все находится в schema.graphql, но по мере расширения проекта вы разделяете этот файл на части. Затем по мере разработки вы меняете то, что возвращает запрос. Это означает, что нужно найти часть определений вашего типа, которая соответствует функции, с которой вы ошиблись, изменить ее в схеме GraphQL и затем протестировать преобразователь, чтобы убедиться, что тип GraphQL совпадает с тем, что возвращается, что становится… утомительным.

Разделение определений типов требует, чтобы вы снова слили файлы вместе, чтобы создать рабочую схему, и в экосистеме GraphQL есть более чем несколько различных способов сделать это. Вдобавок ко всему, когда вы создаете ошибку, Typescript не особенно полезен для выявления ошибок в коде GraphQL (который, опять же, находится в любом количестве файлов).

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

{
    Queries{
        ReadUsers(){
        }
        ...All your other queries
    }
    Mutations{
        UpdateUser{
        }
        ... All your other mutations
    }
}

Опять же, в экосистеме GraphQL есть способы сделать это, но, по моему опыту, это быстро запуталось.

Альтернатива - сначала код

Большинство проблем, о которых я упоминал выше, возникает из-за создания схемы с двумя языками и их синхронизации. Основной пакет для TS / JS - Nexus. С Nexus вы не пишете никакого GraphQL-кода, все делается на Typescript.

Это дает множество преимуществ:

Вы пишете информацию об определении типа и преобразователь в одной и той же функции. Когда вам нужно изменить запрос или изменение, все будет в одном месте.
Типы применяются принудительно, но их можно легко изменить. Nexus имеет уникальную настройку разработки, которая позволяет определениям типов, которые вы пишете, обеспечивать безопасность типов в преобразователе. Когда вы меняете определения типов, безопасность типов обновляется сразу после сохранения (при перезапуске ts-node-dev).
Ошибки есть в Машинописи. 95% ошибок типов обнаруживаются с помощью IntelliSense of VSCode из-за использования безопасности типов Typescript, и даже когда Nexus выводит что-то на ваш терминал, он дает вам местоположение и удобочитаемое сообщение об ошибке.
Никакого слияния или сшивания схемы не требуется, просто поместите все в схему Nexus, и она сделает всю работу за вас.

Код Nexus

Для настройки перейдите на nexusjs.org. Я просто собираюсь показать, как в сравнении выглядит приведенный выше пример с простым пользователем и запросом / изменением.

В приведенном выше коде показана интеграция информации об определении типа с функцией разрешения запроса / мутации. Nexus максимально использует машинописный текст, и есть много преимуществ, которые дает автозаполнение и сгенерированный IntelliSense, которые вы можете увидеть только при написании кода.

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

Мне показалось очень странным уходить от написания кода GraphQL и определений типов, но как только я переключился, я обнаружил, что моя разработка стала быстрее и приятнее. Я опасался попробовать сначала код, в основном потому, что я использовал генератор кода GraphQL, но Nexus предоставляет все те же преимущества GQL Code Gen без инструмента CLI. Забегая вперед, я не вижу себя отдельно управляющим кодом GraphQL.

Спасибо за прочтение. 👍

Почему вы должны использовать Code First GraphQL Development (NexusJS)