День 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 может занять больше времени, но существует множество скаффолдеров, которые облегчают эту работу. И даже если поначалу это займет больше времени, это даст вам преимущество в долгосрочной перспективе.

Источник: https://www.freecodecamp.org/news/graphql-vs-rest-api/