Время от времени появляются какие-то статьи типа GraphQL: от восторга до разочарования. Т.к. активно использую GraphQL и не собираюсь отказываться, то хочу разъяснить свою позицию.
Если говорить про саму статью, то одна из основных проблем – использование JavaScript/TypeScript на сервере. В частности, получается не преимущество от типизации, а наоборот мучения. Более подробно тему выбора платформы разбираю в заметке Выбор среди платформ разработки серверных приложений. Далее про GraphQL.
GraphQL хорош именно свободой UI-разработчиков (веб и мобильных) менять UI с меньшей зависимостью от серверных программистов. И это нужно не только в “больших” проектах (как указывает большинство комментаторов), но и в малых – там бывает даже сложнее найти время программистов. Все остальные преимущества (типа меньшего кол-ва запросов или трафика) мало важны для стартапов.
GraphQL на бекэнде в реализации не сложнее обычного HTTP-запроса. Да, нужно реализовывать на уровне query собственную пагенацию, кеширование и т.п. (если нужно), но это же и в HTTP нужно делать. Если нужно, чтобы reverse-proxy кешировал ответ, то нужно либо его настроить, либо воспользоваться HTTP. Если нужно, чтобы браузер кешировал ответ, то нужно воспользоваться HTTP.
Первая реализация на клиенте немного сложнее, т.к. нужно написать запрос на GraphQL и сгенерировать реализацию. Тем не менее, как раз мобильные и веб разработчики за GraphQL. Почему же? Потому что потом обязательно будет нужно делать изменения, а с GraphQL это заметно легче.
GraphQL не является какой-то серебряной пулей. Более того, он не может заменить обычные HTTP-запросы. Тем не менее он полезен.
Несколько принципов работы с GraphQL:
- GraphQL – это не замена HTTP. Используйте там, где это дает преимущества (запросы данных). Не используйте там, где не дает. Очень банально, но часто хотят полностью заменить обычный HTTP. Примеры где не нужно использовать graphql:
- загрузка файлов на сервер
- скачивание файлов (особенно картинок)
- интеграционные api (сервер-сервер)
- Лучше не использовать различные сторонние дополнительные инструменты, сервисы и библиотеки – в целом, оно просто не надо (KISS). Это Federation, Stitching, gateways и т.п. Возможно, когда-то нужно будет этим заняться, но тогда проект будет таких размеров, что этим будут заниматься специально обученные люди.
- Использовать мутации в graphql или нет – вопрос стиля (и качества интеграции http-спецификации на сервере и клиентах) – кому-то будет удобнее http, кому-то graphql, но каких-то особых преимуществ graphql здесь не дает.
- Поставьте расширение для Chrome GraphQL Network Inspector, чтобы удобно смотреть запросы GraphQL.
- Поставьте GraphQL плагин для Idea, чтобы удобнее работать в редакторе.
- Не так принципиально используется Code First или Spec First подходы, как важно, чтобы была автоматическая генерация. Например, в Spring Data по умолчанию предлагают якобы Spec First, но генерации кода не происходит – это проблема (нужно 2 раза писать – спеку и код, а потом уже при старте оно совместится или нет). При этом есть вариант SQPR (Code First), но он не поддерживает корутины и вообще в каком-то зачаточном состоянии (тут Quarkus выглядит все еще лучше Spring).
- Code First обычно получше: схема описывается на основном языке. Плюс, стадии генерации кода нет – быстрее сборка.
- Авторизация через заголовки: в самой спецификации нет ограничений, но аутентификацию можем провести через заголовки запроса как обычно (будь то cookie или x-api-key), а уже зная пользователя затем делать авторизацию – опять же ничего нового относительно http.
- Пагинация делается через параметры запроса – ничего нового относительно http.
- Понятие ошибок есть в GraphQL. От проекта к проекту зависит какие ошибки на какой уровень выносить: http, GraphQL, ответ запроса.
- Если в итоге какой-то запрос тормозит, то подключаются серверные разработчики и пишут новый специализированный запрос (в терминах GraphQL). Или полностью новый, или часть запроса оптимизируют. Да, магии нет, просто рутина.
В итоге GraphQL – отличный инструмент для быстрого и независимого (по клиентам) развития проекта. При этом он дополняет имеющийся инструментарий, а не заменяет что-то.