Почему GQL встречает такое сопротивление? Объяснение приходит, когда смотришь на зависимость членов команды друг от друга.
Фронтендер зависит от бекендера, чего не скажешь об обратном. По этой причине фронтендер так или иначе вникает в проблемы бека, но не всегда бывает наоборот.
Если бекендер вложил массу времени и сил в изучение архитектурных подходов REST, а затем свел руки вместе, поднял над собой и сказал: «Я в домике», – то фронтендеру остается с грустным видом удалиться, волоча на шнурке какой-нибудь GraphQL.
Но если смотреть на сервис как на конечный продукт и понимать проблемы фронтенда (к слову, современный фронтенд вряд ли уступает по сложности бекенду), то GraphQL будет выглядеть незаменимым инструментом для решения многих проблем:
1. Уменьшение количества запросов и пейлоада, о чем говорилось в статье.
2. Обновление состояния приложения на сообщениях от сервера на основе subscriptions.
3. Оптимальное кеширование. Оба популярных клиентских фреймворка – Relay и Apoll реализуют его из коробки.
4. Проблема начального этапа разработки, когда отсутствие эндпоинтов вынуждает мокать данные, писать обертки в коде. Вместо этого фронтенд может воспользоваться BaaS-сервисами типа graph.cool и scaphold для быстрого и бесплатного прототипирования, а когда будет готов свой бекенд, – просто поменять адрес сервера.
5. Декларативность кода. Лично у меня давно возникает диссонанс от необходимости писать модуль fetch с retry, создавать словари для разных ресурсов и HTTP-методов. По сравнению с подходом того же Redux, это кажется громоздким, бессмысленным, ибо повторяется из проекта в проект, не соответствующем времени.
GraphQL не только язык. Как бывает с удачными подходами — они вдохновляют на создание целой экосистемы инструментов, решающих основную и сопутствующие проблемы. Такими инструментами являются упомянутые клиентские фреймворки Relay и Apollo. Да, их применение требует изменить многое на бекенде, и тут могут быть сложности.
Но сложность связана с новизной, с необходимостью бекен-разработчика изучать новые подходы, когда он столько сил потратил на изучение старых. Это понятно и оправдано. Но в конечном счете, общее дело делаем. И вы правда считаете REST вершиной эволюции? Уверены, что через 10 лет кто-то будет вспоминать про REST? Как бы не оказаться в хвосте очереди
UFO landed and left these words here
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Фронтендер зависит от бекендера, чего не скажешь об обратном. По этой причине фронтендер так или иначе вникает в проблемы бека, но не всегда бывает наоборот.
Если бекендер вложил массу времени и сил в изучение архитектурных подходов REST, а затем свел руки вместе, поднял над собой и сказал: «Я в домике», – то фронтендеру остается с грустным видом удалиться, волоча на шнурке какой-нибудь GraphQL.
Но если смотреть на сервис как на конечный продукт и понимать проблемы фронтенда (к слову, современный фронтенд вряд ли уступает по сложности бекенду), то GraphQL будет выглядеть незаменимым инструментом для решения многих проблем:
1. Уменьшение количества запросов и пейлоада, о чем говорилось в статье.
2. Обновление состояния приложения на сообщениях от сервера на основе subscriptions.
3. Оптимальное кеширование. Оба популярных клиентских фреймворка – Relay и Apoll реализуют его из коробки.
4. Проблема начального этапа разработки, когда отсутствие эндпоинтов вынуждает мокать данные, писать обертки в коде. Вместо этого фронтенд может воспользоваться BaaS-сервисами типа graph.cool и scaphold для быстрого и бесплатного прототипирования, а когда будет готов свой бекенд, – просто поменять адрес сервера.
5. Декларативность кода. Лично у меня давно возникает диссонанс от необходимости писать модуль fetch с retry, создавать словари для разных ресурсов и HTTP-методов. По сравнению с подходом того же Redux, это кажется громоздким, бессмысленным, ибо повторяется из проекта в проект, не соответствующем времени.
GraphQL не только язык. Как бывает с удачными подходами — они вдохновляют на создание целой экосистемы инструментов, решающих основную и сопутствующие проблемы. Такими инструментами являются упомянутые клиентские фреймворки Relay и Apollo. Да, их применение требует изменить многое на бекенде, и тут могут быть сложности.
Но сложность связана с новизной, с необходимостью бекен-разработчика изучать новые подходы, когда он столько сил потратил на изучение старых. Это понятно и оправдано. Но в конечном счете, общее дело делаем. И вы правда считаете REST вершиной эволюции? Уверены, что через 10 лет кто-то будет вспоминать про REST? Как бы не оказаться в хвосте очереди