Это первая часть из пяти вводных статей о GraphQL и Apollo. Я надеюсь, что к концу вы почувствуете себя комфортно с основополагающими концепциями GraphQL, а также с некоторыми практическими знаниями о создании сервера GraphQL. Если у вас есть отзывы, оставьте комментарий!
Что делать с GraphQL?
Сразу же важно понимать, что GraphQL, выпущенный Facebook, сам по себе не является библиотекой или даже инструментом. GraphQL — это спецификация, выпущенная Facebook, которая используется Facebook и другими организациями в качестве руководства для создания реализаций. Он послужил основным документом для моего понимания GraphQL, и его легко читать. Посмотрите здесь.
Поскольку GraphQL — это спецификация, вам нужно будет выбрать реализацию, которую вы будете использовать при создании своего сервера. На протяжении всей этой серии мы будем использовать стек Apollo, потому что я считаю, что это лучший способ быстро приступить к работе с уменьшенным шаблоном и хорошей документацией. Есть и другие, в том числе референсная реализация Facebook, а также express-graphql.
Концептуально GraphQL — это тонкий слой поверх вашего приложения, который управляет получением ваших данных для ваших клиентов. Он не взаимодействует напрямую с вашей базой данных; это не язык запросов, как SQL — это язык запросов. Вместо этого в GraphQL вы пишете схему, которая принимает запросы. Затем они передаются для разрешения функций, которые взаимодействуют с вашими хранилищами данных.
Мы рассмотрим каждую из этих концепций по отдельности, но пока достаточно представить GraphQL как тонкий слой, который находится между вашим приложением и вашими хранилищами данных и заменяет традиционные конечные точки REST одной конечной точкой /graphql
.
Почему GraphQL?
Так зачем тратить время на изучение GraphQL? Помимо простого любопытства, есть несколько реальных бизнес-кейсов для использования GraphQL.
- Значительно снижены сетевые запросы
- Ремонтопригодность
- Рабочий процесс, ориентированный на продукт
- Простая интеграция нескольких источников данных
В традиционных REST API вы создаете уникальную конечную точку URL для каждой функции CRUD и любых пользовательских операций, которые должно поддерживать ваше приложение. Так, например, если бы у вас было представление, отображающее пользователя и его последний твит, вам пришлось бы отправлять запросы к вашей конечной точке /users
, а также к вашей конечной точке /tweets
. В GraphQL вы отправляете один запрос к конечной точке /graphql
, и ваш сервер создает объект ответа, который содержит как информацию о вашем пользователе, так и его последний твит.
Поскольку теперь у нас есть только одна конечная точка, прошли времена API-интерфейсов управления версиями, прерывания клиентских запросов при изменении конечной точки или растущего количества избыточных или устаревших конечных точек, которые необходимо поддерживать (отсюда и повышенная ремонтопригодность).
В GraphQL клиент объявляет, какие данные он хочет вернуть, и в какой форме эти данные должны быть. Это значительно упрощает создание и итерацию дизайна клиента, поскольку вы точно знаете, какие данные вы собираетесь получить из запроса, ни больше, ни меньше.
Для меня настоящее волшебство GrapQL — это возможность связать воедино множество источников данных, некоторыми из которых я управляю, а к некоторым получаю доступ через сторонние API. Я могу легко интегрировать данные из API-интерфейсов Twitter, Facebook и любого другого источника данных с моими собственными сохраненными данными, чтобы повысить ценность моего приложения и моих пользователей.
Как использовать GraphQL?
Просто чтобы дать вам представление о том, как выглядит запрос и ответ GraphQL:
{ film(id: "ZmlsbXM6MQ==") { id title character(id: "bVHXMDBI&") { name } } }
Ответ, который дает нам этот запрос:
{ "data": { "film": { "id": "ZmlsbXM6MQ==", "title": "A New Hope" "character": { "name": "Luke", } } } }
Как видите, вы можете создавать простые вложенные запросы, которые будут возвращать данные, очень похожие на отправленный вами запрос.
Надеюсь, теперь вы а) заинтересованы в GraphQL и б) готовы приступить к написанию собственных запросов. Мы расскажем об этом во второй части.