Почему GraphQL ломает серверы и нервы разработчиков
GraphQL позиционируют как замену REST: гибкость, меньше запросов, получаем и запрашиваем именно те данные, которые нужно. Но когда доходит дело до реализации в реальном приложении, разработчики сталкиваются с множеством сложностей, особенно на backend части. От N+1 запросов до проблем с безопасностью и версионированием. GraphQL легко превращается в источник головной боли.
Что такое graphql
GraphQL предоставляет клиентскому приложению получать в одном запросе все необходимые данные, даже если они лежат в разных источниках.
Его используют во многих приложениях социальных сетей. А также GitHub, Shopify, Pinterest. То есть в приложениях, где требуется работа со сложными графами данных. Он популярен в веб- и мобильной разработке, потому что дает большую гибкость при реализации front-части.
А вот со стороны серверной части реализация GraphQL сопряжена с множеством сложностей.
Сложности с реализацией на сервере
Для реализации GraphQL на сервере потребуется подключить много дополнительных библиотек - Apollo Server или GraphQL Java или другие какие-то, а это дополнительная сложность с разработкой и поддержкой. В некоторых случаях дополнительные библиотеки требуются и для построения схемы, резолверов, валидации запросов.
Если у вас используется архитектура с Gateway перед сервисами, то нужно дополнительно подключать и/или реализовывать функционал для поддержки GraphQL.
Потребуется дополнительная логика для загрузки данных. В отличие от REST/GRPC, где логика прямолинейна, при реализации GraphQL потребуются Resolver'ы для загрузки каждого поля. К Resolver'ам прибавляются DataLoader'ы для решения проблемы N+1 запросов.
Безопасность данных и нагрузка на сервер
Самые неприятные моменты, которые возникают при использовании GraphQL, связаны с самой графой структурой запросов:
- Неосторожное проектирование API может привести к тому, что сервер начинает страдать от N+1 запросов и запросы становятся очень глубокими. Это дает дополнительную нагрузку на сервер и базу данных.
- Запросы могут быть очень глубокими и тяжелыми, из-за этого можно положить сервер. Чтобы избежать этого, требуется внедрять искусственные ограничения на максимальную глубину запроса и лимит по полям.
- В системах с чувствительными к уровню привилегий пользователя данными очень сложно реализовать контроль доступа пользователя к данным, появляются уязвимости. В REST контроль доступа пользователей можно реализовать на уровне URL эндпоинтов и ролей, что значительно проще и безопаснее.
Проблемы, которые возникают из-за реализации самого GraphQL
Есть еще ряд ограничений, которые возникают из-за технической реализации GraphQL. Практически всегда GraphQL реализован через POST запрос на один endpoint, и это накладывает дополнительные сложности:
- REST легко кэшировать на уровне HTTP/CDN. В то же время для кэширования GraphQL требуется добавить дополнительные библиотеки и/или компоненты инфраструктуры.
- Из-за реализации через POST/HTTP очень трудно мониторить. Чтобы понять, какая часть тормозит, требуется разбирать конкретные запросы. Более того, похожие запросы (а иногда они отличаются только запросом 1-2 полей) могут работать по-разному, и не всегда с первого взгляда можно определить, что идет не так.
- Поддерживать версионирование очень сложно. В REST для новой версии можно сделать новый URL и отключить старый, когда он уже не будет использоваться. GraphQL построен вокруг философии эволюции схемы, и внедрять новые или выкидывать старые становится очень сложно.
Вывод
GraphQL - отличный инструмент, когда ваше приложение строится вокруг сложных графовых структур данных - социальные сети, карты и объекты на них. Но в большинстве приложений он добавляет избыточную сложность в реализации и поддержке. Конечно, современные фреймворки, такие как Apollo Server или Spring for GraphQL, уже решают эти сложности «из коробки», но в то же время ограничивают гибкость решения.
Хорошо спроектированный REST/GRPC и использование паттерна Backend For Frontend решают 90% всех проблем.
Мой канал в telegram