REST против GraphQL - узнайте, в чем различия и когда их использовать.
вступление
Это всего лишь быстрое сравнение GraphQL и REST, которое поможет вам определить, когда использовать. Я не рекомендую вам использовать одно вместо другого, у каждого из них есть свои плюсы и минусы. Вместо этого мы рассмотрим их в этой статье, чтобы помочь вам выбрать лучший вариант для вашего следующего большого проекта.
Я также делаю это простым для новичков, так как мне сначала было трудно понять GQL. Надеюсь, это поможет и вам, ребята.
GraphQL
GraphQL приобрел большую популярность в последние годы, новички могут быть не так знакомы с ним. В первый год обучения веб-разработке я не видел и не касался ничего, связанного с GQL.
GraphQL - это язык запросов для API. Он может предоставить вам полное и понятное описание всех данных в вашем API. Он предоставляет клиенту (интерфейсу) веб-сайта возможность запрашивать данные, которые им требуются, и только эти данные. Это уникальная особенность GQL: вы не загромождаете данные, возвращаемые вашим API, вы получаете ТОЛЬКО то, что вам нужно.
Одно из заблуждений из-за его именования состоит в том, что GQL имеет какое-то отношение к базам данных или замене SQL. Могу вас заверить, что это не так.
Он был создан внутри Facebook в 2012 году, а затем был открыт в 2015 году.
Многие крупные компании уже внедрили GQL в свой технологический стек, например:
Подход GraphQL
Так как же работает GQL? Вместо традиционного подхода REST все рассматривается как граф и взаимосвязано. Как следует из названия, это язык запросов для графиков.
Простой запрос с использованием GQL:
query {
book {
name
pages
}
}
Вот что возвращается:
{
"book": {
"name": "GQL for dummies",
"pages": 451
}
}
Что ты заметил? Когда вы пишете запрос, вы просто пишете точный объект JSON, который хотите вернуть, конечно, без значений.
Как упоминалось ранее, вы получаете то, о чем просите.
ОТДЫХАТЬ
REST - это традиционный способ, который существует намного дольше, чем GQL. Основная идея REST - ресурсы. Каждый ресурс определяется конечной точкой URL. Доступны четыре основные операции:
- GET- получить данные
- POST- Отправка данных на хранение
- PUT- Отправить данные на обновление
- DELETE- обычно отправляется с идентификатором для удаления некоторых данных.
Клиентская сторона обычно отправляет один из вышеуказанных запросов вместе с любыми необходимыми данными в конечную точку URL, где она затем обрабатывает запросы или обновление базы данных.
Несколько типичных примеров конечных точек URL:
(GET) app.com/api/books -- All books (GET) app.com/api/books/:id -- Just one book by ID (POST) app.com/api/books -- Store new book with the data given (DELETE) app.com/api/books/:id -- Delete a book by ID
Что вы здесь заметили? В отличие от GQL, мы не определяем, какие данные нам нужны. Вместо этого мы определяем, какие данные нам нужны на стороне сервера, и получаем их, когда вызываем конечную точку.
GraphQL Плюсы
- Получение данных с помощью одной конечной точки API
- Нет избыточной и недостаточной выборки данных
- Разработчики Frontend лучше понимают доступные данные
- Имеет проверку и проверку типа из коробки
- Может использоваться с TypeScript (Отлично)
- Среда для проверки ваших запросов и мутаций
- Отличная автоматически сгенерированная документация
- Может обеспечить последовательность при разработке
- Схемы со строгой типизацией
GraphQL Минусы
- Сервер не контролирует, какие данные запрашиваются, клиент может запрашивать объект со слишком большим количеством вложенных полей.
- Проблема с производительностью, вызванная предыдущим мошенничеством
- Излишек для небольших приложений
- Настройка занимает некоторое время по сравнению с REST
- Высокая кривая обучения
REST Плюсы
- Использует стандартные операции HTTP
- Меньше времени на настройку по сравнению с GQL
- Тонны ресурсов, на которых можно учиться
- Нетрудно найти решение любой проблемы, с которой вы столкнетесь (скорее всего, у кого-то это было раньше)
- Зрелый и проверенный на протяжении многих десятилетий
- Может обрабатывать несколько форматов данных (простой текст, HTML, JSON)
- Возвращать кешированные ответы быстрее
ОТДЫХ Минусы
- Склонен к избыточной или неполной выборке данных
- Может иметь много разных конечных точек
- Для больших команд самостоятельная подробная документация почти ОБЯЗАТЕЛЬНА.
- Может потребоваться выполнить несколько вызовов API только для одной страницы данных.
- Front-end разработчики не могут контролировать, какие данные они получают, им нужно общаться с back-end командой.
Сходства
- Ресурсы можно указывать по идентификаторам
- Получено через HTTP-запрос с URL-адресом
- Оба просто вызывают функции на сервере.
- Может положиться на фреймворки, чтобы немного облегчить жизнь
- Возвращает данные JSON
- Оба могут различать запрос
- GQL через запрос, мутации
- REST через GET / POST / PUT / DELETE
Различия
В REST форма и размер ресурсов определяются на стороне сервера. В GQL сервер объявляет все доступные данные, а клиентская сторона может запрашивать только то, что им нужно.
С помощью REST вы указываете операцию, изменяя команду HTTP (GET, POST, PUT, DELETE). В GQL вы переключаетесь между запросом и мутацией.
Comparison Query === GET Mutation === POST, PUT, DELETE
В REST каждый запрос к конечной точке будет вызывать одну функцию обработчика маршрутизатора. В GQL один запрос может вызывать несколько преобразователей для создания данных, которые необходимо вернуть.
Хорошее объяснение обработчика маршрута здесь.
Документы для резолверов здесь.
Когда следует использовать GraphQL?
GQL хорошо работает для приложений на таких устройствах, как мобильные телефоны, умные часы и устройства IoT, где важно использование полосы пропускания. Но это не значит, что он не подходит и для веб-приложений.
Приложения, в которых есть много вложенных данных, которые необходимо получить за один вызов, например сообщения в блогах со всеми пользователями, которым понравилась публикация, все комментарии, а также все ответы на эти комментарии. Здесь GQL показывает свой потенциал.
Еще одна веская причина - это когда вашему приложению необходимо получить данные из нескольких хранилищ.
Если вы хотите, чтобы команда внешнего интерфейса имела больше гибкости при выборе данных, которые им нужны, а какие нет.
Очень удобно для быстрого прототипирования, поскольку ваш пользовательский интерфейс постоянно меняется, например, требует больше или меньше данных, вам не нужно постоянно менять код на стороне сервера.
Когда не использовать GraphQL
Если вы разрабатываете небольшое и простое приложение, GraphQL может оказаться излишним. В конце концов, это просто добавит сложности из-за таких вещей, как типы, схемы, запросы, мутации и преобразователи.
Не имеет смысла поддерживать все эти вещи для небольшого приложения.
Если ваше приложение включает в себя загрузку большого количества файлов, возможно, GQL не для вас, поскольку он не поддерживает его. Большая часть реализации предоставляется разработчику. Есть несколько библиотек, которые могут вам помочь, или вам может даже потребоваться отдельный сервер для обработки этого.
Когда следует использовать REST?
Если вы ищете проверенное и проверенное решение, вам, скорее всего, захочется использовать REST. Поскольку архитектурный стиль в значительной степени рассматривается как традиционный стандарт для разработки API, у вас не будет никаких проблем из-за очень большого количества доступных вам ресурсов.
REST может поддерживать различные форматы данных без лишних усилий. Поэтому, если вашему приложению требуется загрузка нескольких типов данных, REST может быть для вас оптимальным выбором.
Если вы хотите улучшить обработку ошибок, то REST - это то, что вам нужно. Обработка ошибок с помощью REST довольно проста, в отличие от GQL, где она была немного усложнена. REST вернет различный статус HTTP (200, 201, 400, 404, 500…). Однако GQL возвращает 200 OK даже в случае ошибок.
Если данные, которые обрабатывает ваше приложение, довольно просты и не сильно вложены или связаны. REST может быть вашим другом, вы можете меньше беспокоиться о избыточной или неполной выборке данных.
Я считаю, что REST - даже лучший выбор для новичков. Когда я начал изучать веб-разработку чуть больше года назад, я начал с REST, и он многому меня научил. Я не касался GQL до начала этого года и рад, что изучил его до GQL. Я чувствовал себя более уверенно, войдя в GQL, имея некоторое представление о сети и традиционной архитектуре REST.
Когда не использовать REST
Как я уже упоминал несколько раз ранее, если данные сильно связаны / вложены и высока вероятность избыточной или недостаточной выборки, вам следует перейти на GraphQL.
Возможно, вы работаете над проектом с большой командой, состоящей из внешних и внутренних разработчиков. И если цель состоит в том, чтобы добиться быстрого прогресса с обеих сторон, REST может сдерживать вашу команду. Интерфейсная группа может постоянно изменять пользовательский интерфейс, требуя каждый раз больше или меньше данных. Команда back-end должна будет постоянно обновлять, какие данные возвращает каждый маршрут.
Это вызовет много обменов информацией, команда внешнего интерфейса будет запрашивать изменения в возвращаемых данных или не знать, какие данные им доступны, а группе поддержки придется вносить изменения, что означает, что у них будет меньше времени, чтобы сосредоточиться на других. серверные задачи.
Заключение
Теперь что касается заключения, ты должен сам принять это решение, мой друг. Мы рассмотрели плюсы и минусы, когда и когда не использовать каждый.
Сначала начните с перечисления требований к вашему заявлению, крайнего срока, размера команды и целей. Затем еще раз просмотрите эту статью (проведите дополнительное исследование) и примите решение (вместе со своей командой, если вы в одной из них) для наилучшего варианта.
GraphQL - это не замена REST, это просто еще один инструмент, который помогает нам разобраться с делом.
дальнейшее чтение
- Документы GraphQL - https://graphql.org/
- REST API - https://www.redhat.com/en/topics/api/what-is-a-rest-api
- GQL (видео) - https://youtu.be/eIQh02xuVw4
- ОТДЫХ (видео) - https://www.youtube.com/watch?v=-MTSQjw5DrM
Больше контента на plainenglish.io
