Прощай, GraphQL: почему через 6 лет энтузиазм угас
Разработчик делится опытом разочарования в GraphQL после 6 лет использования и объясняет, почему REST снова в фаворе.
Помните времена, когда GraphQL казался серебряной пулей для API? Ещё бы: один эндпоинт, никакого оверфетчинга, клиент сам решает, что ему нужно. Но вот незадача — после 6 лет активной эксплуатации некоторые разработчики начинают замечать, что патроны в этой пуле не такие уж и серебряные.
Что пошло не так?
Автор статьи, проработав с GraphQL полдесятилетия, выделяет несколько ключевых проблем:
- Сложность кэширования. В REST кэширование на уровне HTTP — это база. В GraphQL же каждый запрос уникален, и кэш приходится выстраивать вручную на клиенте. Это боль. - Производительность. N+1 проблема — классика жанра. DataLoader помогает, но не всегда. Когда у тебя десятки вложенных запросов, база данных начинает плакать. - Сложность инструментов. GraphQL требует генерации типов, схемы, резолверов. Чем больше команда, тем больше хаоса. А попробуй объяснить новичку, что такое `__typename` и зачем он нужен. - Избыточность для простых проектов. Если у вас CRUD с тремя сущностями, GraphQL — это как из пушки по воробьям. REST справится быстрее и проще.
REST — не идеален, но предсказуем
Автор не призывает всех срочно мигрировать обратно на REST. Но отмечает, что для большинства внутренних сервисов и небольших проектов REST остаётся более прагматичным выбором. GraphQL хорош для сложных, клиенто-ориентированных приложений с кучей разнородных клиентов (мобила, веб, IoT). Но если у вас один веб-клиент — зачем огород городить?
Комментарий студии METABYTE: Выбор между REST и GraphQL — это не религиозная война, а инженерное решение. Если ваш проект похож на конструктор Lego (много мелких деталей) — GraphQL может быть кстати. Но если вы просто хотите быстро собрать API для типового приложения — REST с OpenAPI часто оказывается тем самым молотком, который не ищет гвоздей там, где их нет.