Выбрали GraphQL на старте, через год хотим обратно на REST. Кто проходил?

[elena_msk]

Год назад на хайпе взяли GraphQL для всего. Сейчас имеем N+1 в резолверах, невозможность нормально кешировать на CDN и фронт который всё равно запрашивает одни и те же три эндпоинта. Думаем откатиться. Скажите что мы не одни такие.

[german_kernel]

Не одни. Главная ложь про GraphQL это 'клиент берёт только нужные поля'. На практике у тебя 5 фрагментов которые всё равно тянут пол-схемы, плюс ты теряешь http-кеширование напрочь.

[reactdns550]

N+1 это не вина GraphQL а вина того что вы не поставили dataloader. С батчингом и кешем на уровне резолвера проблема решается за день.

[pixelgo7055]

Dataloader поставили, стало лучше, но это ещё один слой который надо понимать и дебажить. Сложность не исчезла, она переехала.

[yegor4466]

Вот это ключевое. GraphQL не убирает сложность, он перекладывает её с фронта на бэк и на инфру. Если у тебя один фронт и один бэк — ты просто добавил геморроя без выгоды.

[neonapi460]

А мы наоборот довольны. У нас 4 клиента — веб, ios, android и партнёрское api. Без GraphQL это был бы зоопарк из 30 REST-эндпоинтов под каждый экран. Тут он реально на своём месте.

[kirill_backend]

lena_codes вот именно, GraphQL оправдан когда много разных клиентов с разными потребностями в данных. У стартового founder судя по всему один веб-фронт, отсюда и боль.

[luka_lab]

У нас как раз монорепо и ts везде. tRPC реально выглядит как то что нам надо было с самого начала. Но партнёрам наружу мы tRPC ведь не отдадим?

[pavel5675]

Наружу для партнёров — обычный REST с openapi-схемой, это стандарт который понимают все. tRPC только для своего фронта. Гибрид это норма, в проде почти всегда несколько стилей api живут рядом.

[gleb_dns92]

По цифрам добавлю: у нас простой запрос через GraphQL в среднем 1800мс против 900мс на REST из-за оверхеда резолверов и парсинга. Для перф-критичных ручек мы их вынесли обратно на чистый REST.