День 1177. #ЗаметкиНаПолях
GraphQL или REST API. Что Использовать? Окончание
Начало
Теперь предположим, что нам нужно отобразить в списке имена пользователей и их «опыт» на текущем месте работы. В REST, учитывая, что «опыт» - это таблица с внешним ключом user_id, есть три возможных варианта:
1) Создать структуру со всеми внешними связями таблицы users и получать все данные в неё. Но это приведёт к очень дорогостоящим запросам и возвращает много данных из всех внешних таблиц, которые в большинстве случаев не требуются.
2) Делать несколько запросов на сервер:
GET /users
GET users/1/experience
Это пример неполной выборки, так как у одной конечной точки недостаточно данных. Но множественные сетевые вызовы замедляют процесс и влияют на работу пользователя. Кроме того, в случае списка неполная выборка усугубляется тем, что нам нужно сделать запрос опыта для каждого пользователя в списке, и мы сталкиваемся с проблемой n+1 запроса.
GET /users
GET users/1/experience
GET users/2/experience
…
GET users/n/experience
3) Создать специальный контроллер, который возвращает структуру данных, соответствующую требованиям клиента на данный момент времени.
GET /user-experience
Это и делается в большинстве реальных случаев в REST API.
С другой стороны, простой запрос GraphQL будет без проблем работать без каких-либо дополнительных изменений на стороне сервера. Запрос будет выглядеть примерно так:
{
users{
name
experience{
organization
title
duration
}
}
}
Да, можно использовать REST, создавать контроллеры (методы) под требования клиента. Но есть большой недостаток. Мы сформировали тесную связь клиентского представления с внутренними контроллерами API, поэтому потребуется больше усилий, чтобы обрабатывать запросы клиентов. Пользовательский контроллер возвращает данные в зависимости от того, что хочет отобразить представление, поэтому, когда требования изменятся, придётся менять как представление, так и контроллер.
Например, по прошествии времени в списке потребовалось выводить не опыт, а последнюю транзакцию пользователя. С REST нужно будет внести соответствующие изменения в представление, но также придётся изменить и контроллер (добавить метод), и путь. То есть изменение требований клиента сильно влияет на то, что должно быть возвращено сервером.
С GraphQL нам не нужно будет вносить какие-либо изменения на стороне сервера. Изменение внешнего запроса будет минимальным:
{
users{
name
transactions{
amount
type
}
}
}
Никакого рефакторинга серверного API, развертывания и тестирования — это означает экономию времени и усилий!
Итого
GraphQL имеет ряд преимуществ перед REST во многих областях. Первоначальная настройка GraphQL может занять больше времени, но существует множество скаффолдеров, которые облегчают эту работу. И даже если поначалу это займет больше времени, это даст вам преимущество в долгосрочной перспективе.
Источник: www.freecodecamp.org/news/gr…rest-api
