В статье старался прояснить, что затягивание любого из фреймворков влечет за собой изменения в архитектуре фронтенд приложения. А нашей целью было попробовать 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')
};
Согласен, этот недостаток стоит иметь ввиду при выборе 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
, предложенный в статье сниппет решил оставить, чтобы статья была близка к видеоряду. Сейчас наш снипет выглядит так: