GraphQL и REST — это две парадигмы, используемые при создании API для веб-приложений.
REST — набор уникальных идентификаторов (URL), которые приложения используют для запроса и отправки данных.
GraphQL — язык запросов, который позволяет клиентским приложениям точно задавать данные, которые им нужны, из одного эндпоинта.
Это связанные технологии, они используются в основном для одних и тех же вещей (а могут и сосуществовать), но при этом они весьма разные.
Звучит немного пресно, да? Давайте объясним их различия более интересным способом, который может помочь вам лучше понять GraphQL, а, возможно, и просто позабавит.
Вы пришли на вечеринку, чтобы позаниматься нетворкингом, поэтому вам нужна информация о людях вокруг вас. Рядом есть еще пять гостей.
Их именные наклейки следующие:
Ричи Рест (Richy REST)
Друг Ричи Реста (Friend of Richy REST)
Работодатель Ричи Реста (Employer of Richy REST)
Джорджия ГрафКьюЭль (Georgia GraphQL)
Будучи активным и общительным тусовщиком, вы подходите прямо к Ричи Ресту и говорите: «Привет, я Адам Эпликэйшн, а ты кто?» Ответ Ричи Реста таков:
Про себя вы подумали «Ого, слишком много информации сразу». Пытаясь избежать неловкого молчания, вы вспоминаете, что Ричи Рест упоминал, что он работает, и спрашиваете: «Где ты работаешь?»
Удивительно, но Ричи Рест понятия не имеет, где он работает. Может быть, Работодатель Ричи Реста в курсе?
Вы задаете тот же вопрос Работодателю Ричи Реста, который с удовольствием отвечает на ваш вопрос:
К этому моменту вы уже измотаны. Вы уже даже не хотите знакомиться с другом Ричи Реста! Это может занять вечность, растратить всю вашу энергию, и у вас к тому же у вас уже нет времени.
Тем не менее, Джорджия ГрафКьюЭль стоит совсем рядом, и вы решаете поболтать с ней.
«Привет, как тебя зовут?»
«Откуда ты и сколько тебе лет?»
«Сколько у тебя хобби и друзей и как зовут твоих друзей?»
Джорджия ГрафКьюЭль невероятна, четко формулирует мысли, лаконична и точна. Вы совершенно точно хотите обменяться с ней визитками и работать вместе над будущими проектами.
Этот рассказ включает в себя опыт разработчиков по работе с GraphQL и REST. GraphQL позволяет разработчикам формулировать то, что они хотят, с помощью аккуратного запроса и в ответ получать только то, что они указали. Эти запросы являются динамическими, поэтому требуется только один эндпоинт. REST наоборот имеет предопределенные ответы и требует, чтобы приложения использовали несколько эндпоинтов для полного запроса к данным.
Для дальнейшего раскрытия понятий, представленных в метафоре вечеринки, обратимся конкретно к двум ограничениям, которые часто возникают при использовании REST.
1. Несколько обращений при получении связанных ресурсов
Управление данными мобильных и веб-приложений часто требует связанных ресурсов и наборов данных. Таким образом, получение данных с использованием REST API может повлечь за собой многочисленные запросы к многочисленным эндпоинтам. Например, запрос Post и связанного с ней Author может быть совершен двумя запросами к разным эндпоинтам:
Многократные обращения к API влияют на производительность приложения. Это еще более важно для устройств с низкой пропускной способностью (например, смарт-часы, IoT, старые мобильные устройства и т.д.).
2. Over-fetching и under-fetching
Избыточное (Over-fetching) / недостаточное (under-fetching) извлечение данных неизбежно при использовании RESTful API. Используя приведенный выше пример, эндпоинт domainName.com/posts/:id извлекает данные для определенной записи. Каждая запись состоит из атрибутов, таких как id, body, title, publishingDate, authorId, и другие. В REST ответ предварительно определен и всегда возвращается один и тот же объект данных.
В ситуациях, когда требуются только заголовок и текст записи, происходит чрезмерное извлечение данных (over-fetching), поскольку по сети отправляется больше данных, чем фактически используется.
Когда требуется вся публикация вместе со связанными данными об ее авторе, происходит недостаточная выборка (under-fetching) — поскольку по сети отправляется меньше данных, чем фактически используется. Недостаточное извлечение(under-fetching) данных приводит к увеличению количества API-запросов и, как следствие чрезмерному использованию интернет-ресурсов.
GraphQL представляет уникальный подход, который дает огромную гибкость клиентским приложениям. С GraphQL запрос отправляется к вашему API, и возвращается именно то, что вам нужно — ни больше, ни меньше — в одном запросе. Результаты запроса возвращаются в той же форме, что и сам запрос, гарантируя, что структура ответа всегда предсказуема. Эти факторы позволяют приложениям работать быстрее и быть более стабильными, поскольку они контролируют данные, которые получают, а не сервер.
Теперь вы, вероятно, думаете, что работать с GraphQL так же легко, как нарезать теплое масло самурайским мечом. Это может быть верно для фронтенд разработчиков. Однако когда дело доходит до настройки серверной части, кто-то должен сделать самую сложную работу. Наша подруга Джорджия ГрафКьюЭль приложила немало усилий, чтобы стать классным профессионалом.
Создание GraphQL API на стороне сервера требует времени, усилий и опыта. Тем не менее те, кто готов к испытаниям, в состоянии с этим справиться. Есть много разных способов сделать это, например:
Самостоятельно: если вы действительно хотите сделать все самостоятельно, попробуйте построить API GraphQL с помощью пакетов. Используете Rails? Попробуйте graphql-ruby. Любите Node.js? Попробуйте express-graphql.
С помощью: если гибкая настройка хостинга является для вас приоритетной, то что-то вроде Graph.cool может помочь вам приступить к проекту GraphQL.
Мгновенно: Устали писать шаблон CRUD и хотите быстро начать работу? 8base предоставляет мгновенный API GraphQL и серверный бэкенд, который можно расширять.
Для веб-сервисов REST стал значительным шагом вперед, позволив легко создавать API для доступа к необходимым ресурсам. Тем не менее, его дизайн не учитывал текущего распространения мобильных устройств, с различными ограничениями на объем загрузки данных и требованиями. Это упущение привело к росту популярности GraphQL, которое Facebook сделал open source в 2015 году, прежде всего за счет гибкости, которую он дает фронтенд разработчикам. Работа с GraphQL — это фантастический опыт как для отдельных разработчиков, так и для команд.
Перевод выполнен в компании 8base
8base – это готовый к использованию GraphQL backend-as-a-service, который постепенно превращается в полноценную low code платформу разработки. Наша цель – дать возможность разработчикам, обладающим навыками front-end или мобильной разработки, создавать масштабируемые бизнес-приложения.
Подробнее 8base.com.
REST — набор уникальных идентификаторов (URL), которые приложения используют для запроса и отправки данных.
GraphQL — язык запросов, который позволяет клиентским приложениям точно задавать данные, которые им нужны, из одного эндпоинта.
Это связанные технологии, они используются в основном для одних и тех же вещей (а могут и сосуществовать), но при этом они весьма разные.
Звучит немного пресно, да? Давайте объясним их различия более интересным способом, который может помочь вам лучше понять GraphQL, а, возможно, и просто позабавит.
Вы на коктейльной вечеринке
Вы пришли на вечеринку, чтобы позаниматься нетворкингом, поэтому вам нужна информация о людях вокруг вас. Рядом есть еще пять гостей.
Их именные наклейки следующие:
Ричи Рест (Richy REST)
Друг Ричи Реста (Friend of Richy REST)
Работодатель Ричи Реста (Employer of Richy REST)
Джорджия ГрафКьюЭль (Georgia GraphQL)
Будучи активным и общительным тусовщиком, вы подходите прямо к Ричи Ресту и говорите: «Привет, я Адам Эпликэйшн, а ты кто?» Ответ Ричи Реста таков:
{
name: "Richy REST",
age: 33,
married: false,
hometown: "Circuits-ville",
employed: true
// ... 20 other things about Richy REST
}Про себя вы подумали «Ого, слишком много информации сразу». Пытаясь избежать неловкого молчания, вы вспоминаете, что Ричи Рест упоминал, что он работает, и спрашиваете: «Где ты работаешь?»
Удивительно, но Ричи Рест понятия не имеет, где он работает. Может быть, Работодатель Ричи Реста в курсе?
Вы задаете тот же вопрос Работодателю Ричи Реста, который с удовольствием отвечает на ваш вопрос:
{
company: "Mega Corp",
employee_count: 11230,
head_quarters: "1 Main Avenue, Big City, 10001, PL"
year_founded: 2005,
revenue: 100000000,
// ... 20 other things about Richy REST Employer
}К этому моменту вы уже измотаны. Вы уже даже не хотите знакомиться с другом Ричи Реста! Это может занять вечность, растратить всю вашу энергию, и у вас к тому же у вас уже нет времени.
Тем не менее, Джорджия ГрафКьюЭль стоит совсем рядом, и вы решаете поболтать с ней.
«Привет, как тебя зовут?»
{
name: "Georgia GraphQL"
}«Откуда ты и сколько тебе лет?»
{
hometown: "Pleasant-Ville",
age: 28
}«Сколько у тебя хобби и друзей и как зовут твоих друзей?»
{
hobbies_count: 12,
friends_count: 50,
friends: [
{ name: "Steve" },
{ name: "Anjalla" },
// ...etc
]
}Джорджия ГрафКьюЭль невероятна, четко формулирует мысли, лаконична и точна. Вы совершенно точно хотите обменяться с ней визитками и работать вместе над будущими проектами.
Этот рассказ включает в себя опыт разработчиков по работе с GraphQL и REST. GraphQL позволяет разработчикам формулировать то, что они хотят, с помощью аккуратного запроса и в ответ получать только то, что они указали. Эти запросы являются динамическими, поэтому требуется только один эндпоинт. REST наоборот имеет предопределенные ответы и требует, чтобы приложения использовали несколько эндпоинтов для полного запроса к данным.
Закончим с метафорами. Перейдем к делу
Для дальнейшего раскрытия понятий, представленных в метафоре вечеринки, обратимся конкретно к двум ограничениям, которые часто возникают при использовании REST.
1. Несколько обращений при получении связанных ресурсов
Управление данными мобильных и веб-приложений часто требует связанных ресурсов и наборов данных. Таким образом, получение данных с использованием REST API может повлечь за собой многочисленные запросы к многочисленным эндпоинтам. Например, запрос Post и связанного с ней Author может быть совершен двумя запросами к разным эндпоинтам:
someServer.com/authors/:id
someServer.com/posts/:idМногократные обращения к API влияют на производительность приложения. Это еще более важно для устройств с низкой пропускной способностью (например, смарт-часы, IoT, старые мобильные устройства и т.д.).
2. Over-fetching и under-fetching
Избыточное (Over-fetching) / недостаточное (under-fetching) извлечение данных неизбежно при использовании RESTful API. Используя приведенный выше пример, эндпоинт domainName.com/posts/:id извлекает данные для определенной записи. Каждая запись состоит из атрибутов, таких как id, body, title, publishingDate, authorId, и другие. В REST ответ предварительно определен и всегда возвращается один и тот же объект данных.
В ситуациях, когда требуются только заголовок и текст записи, происходит чрезмерное извлечение данных (over-fetching), поскольку по сети отправляется больше данных, чем фактически используется.
Когда требуется вся публикация вместе со связанными данными об ее авторе, происходит недостаточная выборка (under-fetching) — поскольку по сети отправляется меньше данных, чем фактически используется. Недостаточное извлечение(under-fetching) данных приводит к увеличению количества API-запросов и, как следствие чрезмерному использованию интернет-ресурсов.
Клиентские запросы с GraphQL
GraphQL представляет уникальный подход, который дает огромную гибкость клиентским приложениям. С GraphQL запрос отправляется к вашему API, и возвращается именно то, что вам нужно — ни больше, ни меньше — в одном запросе. Результаты запроса возвращаются в той же форме, что и сам запрос, гарантируя, что структура ответа всегда предсказуема. Эти факторы позволяют приложениям работать быстрее и быть более стабильными, поскольку они контролируют данные, которые получают, а не сервер.
«Результаты возвращаются в той же форме, что и запросы»
/* Query */
{
myFriends(first: 2) {
items {
name
age
}
}
}/* Response */
{
"data": {
"items": [
{ "name": "Steve", "age": 27 },
{ "name": "Kelly", "age": 31 }
]
}
}Проверка в реальных условиях
Теперь вы, вероятно, думаете, что работать с GraphQL так же легко, как нарезать теплое масло самурайским мечом. Это может быть верно для фронтенд разработчиков. Однако когда дело доходит до настройки серверной части, кто-то должен сделать самую сложную работу. Наша подруга Джорджия ГрафКьюЭль приложила немало усилий, чтобы стать классным профессионалом.
Создание GraphQL API на стороне сервера требует времени, усилий и опыта. Тем не менее те, кто готов к испытаниям, в состоянии с этим справиться. Есть много разных способов сделать это, например:
Самостоятельно: если вы действительно хотите сделать все самостоятельно, попробуйте построить API GraphQL с помощью пакетов. Используете Rails? Попробуйте graphql-ruby. Любите Node.js? Попробуйте express-graphql.
С помощью: если гибкая настройка хостинга является для вас приоритетной, то что-то вроде Graph.cool может помочь вам приступить к проекту GraphQL.
Мгновенно: Устали писать шаблон CRUD и хотите быстро начать работу? 8base предоставляет мгновенный API GraphQL и серверный бэкенд, который можно расширять.
В завершение
Для веб-сервисов REST стал значительным шагом вперед, позволив легко создавать API для доступа к необходимым ресурсам. Тем не менее, его дизайн не учитывал текущего распространения мобильных устройств, с различными ограничениями на объем загрузки данных и требованиями. Это упущение привело к росту популярности GraphQL, которое Facebook сделал open source в 2015 году, прежде всего за счет гибкости, которую он дает фронтенд разработчикам. Работа с GraphQL — это фантастический опыт как для отдельных разработчиков, так и для команд.
Перевод выполнен в компании 8base
8base – это готовый к использованию GraphQL backend-as-a-service, который постепенно превращается в полноценную low code платформу разработки. Наша цель – дать возможность разработчикам, обладающим навыками front-end или мобильной разработки, создавать масштабируемые бизнес-приложения.
Подробнее 8base.com.
