Как стать автором
Обновить
3
0

Пользователь

Отправить сообщение

Согласен, этот недостаток стоит иметь ввиду при выборе graphql.

Фреймворки и библиотеки маскируют умеют работать с этим недостатком, как на клиенте, так и на сервере.
Можно посмотреть эту https://github.com/gajus/graphql-deduplicator реализацию. Она сопровождается статьей на медиуме https://gajus.medium.com/reducing-graphql-response-size-by-a-lot-ff5ba9dcb60

C HARP не работал. Но здорово, что там эта проблема учтена.

Спасибо за комментарий! Заценил скриншот ;)

В статье старался прояснить, что затягивание любого из фреймворков влечет за собой изменения в архитектуре фронтенд приложения. А нашей целью было попробовать graphql, не меняя текущего флоу работы.

О том, как переезжали без боли с нашего решения на библиотеку или фреймворк и как отказались от redux, расскажем в следующей охэхэнной истории на Youtube.

Да, согласен, можно было избежать деструктивизации query, предложенный в статье сниппет решил оставить, чтобы статья была близка к видеоряду. Сейчас наш снипет выглядит так:


const extractOperationName = (query: RequestConfig['query']): string => {
  const def = query.definitions[0];
  if (def.kind === Kind.OPERATION_DEFINITION) {
    if (def.name) {
      return def.name.value;
    }
  }
  throw new HttpClientError('unknown operation name')
};

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность