Оливер Найбро
Недавно новый пакет совершил революцию в создании GraphQL API в Laravel. Этот пакет делает настолько простой и легкой настройкой сервера GraphQL, что дает вам то самое ощущение, которое вы испытывали во время первой работы с Laravel, «Что это за волшебство!”. Этот пакет, конечно, Lighthouse.
В этой статье я расскажу, как настроить Lighthouse на простом примере блога. Я предполагаю, что вы уже знакомы с основами GraphQL. Пример позволит вам получать и создавать статьи с помощью GraphQL. Lighthouse использует подход к схеме. Вы определяете свой API, создавая схему GraphQL, а затем используете директивы для добавления привязок с помощью Laravel.
Рассрочка
Для начала просто добавьте пакет через composer и опубликуйте файл конфигурации. (Упаковка laravel-graphql-playground является клиентом браузера GraphQL, который является необязательным.)
$ composer require nuwave/lighthouse$ php artisan vendor:publish --provider="Nuwave\Lighthouse\Providers\LighthouseServiceProvider"$ composer require mll-lab/laravel-graphql-playground$ php artisan vendor:publish --provider="MLL\GraphQLPlayground\GraphQLPlaygroundServiceProvider"Создание схемы
Теперь интересно: при настройке этого пакета нам просто нужно создать следующий файл routes/graphql/schema.graphql. Этот файл содержит всю нашу схему для сервера graphql.
Для начала мы добавим простую конечную точку для получения всех сообщений в базе данных. Для этого нам сначала нужно создать наш тип статьи в файле схемы.
...type Article { id: ID! title: String! body: String! author: User!}Определение запроса схемы
Теперь у нас есть два типа, тип для статей и один для пользователей, чтобы мы могли получить автора публикации. Однако у нас до сих пор нет конечных точек для полов, поэтому давайте добавим их в файл схемы.
type Query { ... articles: [Article]! @paginate(type: "paginator" model: "Article")}Теперь происходит еще какая-нибудь магия. Мы добавляем специальную директиву под названием paginate. Эта директива добавляет странички для данной модели (в данном случае статьи). Мы также говорим, что он должен использовать тип paginator что приведет к созданию для нас типа, совместимого с разбиением страниц.
Чтобы просмотреть конечные точки, давайте откроем клиент GraphQL, который мы установили, перейдя в your-url.test/graphql-playground. На схеме мы видим, что новый тип называется ArticlePaginator прилагается. Конечная точка articles возвращает экземпляр ArticlePaginator.
Выполнение запроса
Давайте создадим простой запрос, чтобы получить 10 статей с их названием и именем автора.
query { articles(count: 10) { data { title author { name } } }}Когда мы запускаем этот запрос, он приводит к ошибке, которая говорит, что не удалось найти указанный класс Article. Это имеет смысл, потому что мы еще не создали модель. Это сообщение о настройке видно только потому, что мы не работаем в производственной среде.
Создание нашей модели и миграции
Давайте создадим наши модели и миграции. По умолчанию Lighthouse ищет модели внутри app/models. Чтобы облегчить, мы добавим здесь модель Статья. Нам не нужно перемещать модель пользователя, как в файле схемы, пространство имен для User было введено напрямую.
$ php artisan make:model Models\\Article -mЗатем обновите миграцию и модели:
Опрос статей
Теперь, когда наши модели и миграции настроены, давайте перенесем базу данных и проверим, она все еще не работает.
Теперь мы видим, что конечная точка работает, но у нас нет данных в базе данных. Мы добавим их вручную, затем рассмотрим, как это сделать с помощью GraphQL.
Прекрасно! Теперь мы можем получать статьи через GraphQL. Вместо этого добавим поддержку для получения статей от пользователя. Для этого мы должны изменить наш GraphQL user тип, чтобы иметь отношение к статьям.
...type User { id: ID! name: String! email: String! created_at: DateTime! updated_at: DateTime! articles: [Article] @hasMany(relation:"articles" type:"paginator")}
Поскольку это GraphQL, мы могли бы продолжать его связывать. Так что мы можем получить автора сейчас из статьи, а потом статьи от этого автора и так далее (хотя это было бы нелепо).
Создание мутатора
Теперь давайте добавим мутатор для создания новой статьи. Эта конечная точка также требует аутентификации. Конечно, мы должны быть пользователем системы, прежде чем мы сможем создать новую статью. Для этого мы будем использовать промежуточное программное обеспечение Laravel auth:api. Удалите все предыдущие мутации, поскольку они нам не нужны и добавьте следующее:
type Mutation @group(middleware: ["auth:api"]) { createArticle(title: String!, body: String!): Article @create(model: "Article") @inject(context: "user.id", name: "author_id")}Аутентификация мутатора
Чтобы использовать auth:api промежуточное программное обеспечение, нам нужно будет настроить a Guard. Для этого примера мы просто используем TokenGuard. Для использования защитного маркера нам нужно добавить поле к вызываемому пользователю. api_tokenтогда значением является ваш маркер.
Schema::create('users', function (Blueprint $table) { $table->increments('id'); $table->string('name'); $table->string('email')->unique(); $table->timestamp('email_verified_at')->nullable(); $table->string('password'); $table->string('api_token'); // The new API token field $table->rememberToken(); $table->timestamps();});Теперь мы вручную добавляем токен в базу данных и устанавливаем его secret (вы можете создать собственный пользовательский интерфейс для установки токена или использовать Laravel Passport). Затем мы добавляем этот маркер к нашему запросу, чтобы мы прошли аутентификацию.
Использование мутатора
Теперь у нас есть новая статья, и мы видим, что автор, сделавший ее, был нашим аутентифицированным пользователем. Итак, теперь у нас действительно простой API GraphQL, который работает, но с поддержкой получения наших статей и их создания!
Надеюсь, вам понравилась эта публикация и если вы хотите узнать больше, посетите документацию Lighthouse. Вы также можете найти созданный выше пример Github.