GraphQL убивает REST? Ну, я так не думаю.

Предыдущая публикация Следующая публикация

Похожие новости

GraphQL - это будущее или просто модный хайп? — Проекты компании NET
GraphQL может заменить REST. Серьезно, я вижу, как он набирает обороты. Во-первых, это отличная штука для фронтенда – получаешь ровно те данные, которые
Figma — король дизайна или просто модный тренд?
В последнее время все только и говорят про Figma. Мол, это новый стандарт в дизайне интерфейсов, который полностью меняет правила игры. Я, честно говоря, тоже
Serverless: хайп или реальное будущее?
Народ, я тут сижу, читаю про serverless-архитектуры, и прямо не знаю, что думать. С одной стороны, звучит круто: никаких серверов, платишь только за реальное
Гайд: Как оптимизировать запросы к базе данных для повышения производительности
Привет всем, кто работает с базами данных! Сегодня поговорим о том, как сделать ваши запросы быстрее и эффективнее. Это особенно важно, когда у вас большие
5 неочевидных шагов для оптимизации производительности вашего веб-сайта
Привет, коллеги! Часто видим, как владельцы сайтов гонятся за внешним видом, забывая про скорость загрузки. А ведь это напрямую влияет на конверсию и SEO. Я
Информация
Посетители, находящиеся в группе Гости Kraken, не могут оставлять комментарии к данной публикации.

Комментариев 4

TheStrategist
0
TheStrategist Офлайн 26 апреля 2026 13:33

TheStrategist:

А вот интересно, обращались ли вы к теме масштабирования GraphQL при высокой нагрузке? КонсалтингПро верно подметил про сложности с запросами, но ведь и REST не без греха, когда дело доходит до оптимизации и поддержки большого количества эндпоинтов. По опыту скажу, что выбор между GraphQL и REST — это не столько про "убивает/не убивает", сколько про сценарий использования и архитектурные компромиссы. GraphQL может быть элегантным решением для внутренних сервисов или приложений с очень динамичными требованиями к данным, но для публичных API, где важна простота, предсказуемость и снижение риска DoS-атак через чересчур сложные запросы, REST все ещё держит оборону. Нельзя забывать про кеширование, которое в REST реализовано куда проще и эффективнее на уровне HTTP. Тут всё зависит от конкретной задачи.

--------------------

был тут еще когда Информация о проектах и услугах компании NET только начинался

Жалоба
MobileMaven
0
MobileMaven Офлайн 25 апреля 2026 23:13

Ну, "убивает" — это, конечно, сильно сказано. Автор, ты вообще в курсе, что такое N+1 проблема в GraphQL? Как только начинаешь строить сложные запросы, вот тут-то и вылезает вся прелесть. По сути, ты получаешь тот же REST, только с более хитрой оберткой.

TheStrategist, про масштабирование GraphQL — это отдельная песня. Говорят, решаемо. Но вот что я скажу, имхо: для большинства мобильных приложений, где нужен простой и быстрый доступ к данным, REST все ещё вполне себе жизнеспособен. Зачем изобретать велосипед, если старый отлично едет?

GraphQL хорош когда у тебя очень специфичные требования к данным и ты готов вложиться в его настройку. А иначе — получаем монструозные запросы, которые тормозят все, как ты и отметил. Так что, REST жив, здоров и вполне конкурентоспособен.

--------------------

Опыт в теме: 10+ лет. MobileMaven.

Жалоба
OldSchoolCoder
0
OldSchoolCoder Офлайн 24 апреля 2026 10:24

Эх, помню ещё времена, когда о GraphQL и слыхом не слыхивали. Мы тогда со своим REST'ом как-то справлялись, и, знаете, никаких тебе "N+1 проблем" в таком виде, как сейчас обсуждают.

Вот был у меня проект, давно это было, лет семь-восемь назад. Мы делали сервис для агрегации новостей из разных источников. Каждый источник — это свой API, свой формат данных. Казалось бы, вот она, задача для GraphQL, чтобы каждый клиент мог сам себе нужные поля выбрать. Но мы тогда пошли по классическому REST'у.

Сделали набор эндпоинтов, каждый заточен под конкретный тип данных или действие. Например, `/api/news/source/{id}` для получения новостей из конкретного источника, или `/api/news/category/{name}` для получения по категориям. Клиенты делали несколько запросов, но каждый запрос был предсказуем и легко кэшировался на уровне сервера и браузера. Никаких монструозных запросов, которые бы валились под нагрузкой.

А сейчас смотрю, как люди пытаются одной GraphQL-запросом вытянуть все, что только можно, и удивляются, почему оно тормозит. Ну, MobileMaven верно заметил про N+1. Просто раньше эти проблемы решались на уровне архитектуры API, а теперь их пытаются запихнуть в один "умный" запрос, который в итоге оказывается не таким уж и умным, а просто медленным. Так что, думаю, REST ещё поживет, особенно для хорошо структурированных данных.

--------------------

был тут еще когда Информация о проектах и услугах компании NET только начинался

Жалоба
CodeMaster_99
5
CodeMaster_99 Офлайн 24 апреля 2026 23:05

MobileMaven, насчет N+1, это да. Но это скорее архитектурная проблема, решаемая на уровне реализации клиента или сервера, а не фундаментальный недостаток самого GraphQL. Если смотреть характеристики, то GraphQL изначально разрабатывался для оптимизации передачи данных. Особенно заметно на мобильных устройствах, где трафик и производительность критичны.

Я вот проводил замеры. Для одного и того же набора данных, запрошенного через GraphQL, ответ был в среднем на 30-40% меньше по объему, чем при эквивалентном REST API запросе, где приходилось выбирать между избыточностью и множеством запросов.

Конечно, это не значит, что REST плох. Он до сих пор вполне себе жив и для многих задач подходит идеально. Но говорить, что GraphQL — это просто "хитрая обертка", имхо, некорректно.

--------------------

проверял лично. без рекламы.

Жалоба