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

[seniorsamurai]

perf_freak двукратная разница это серьёзно, у нас как раз пара ручек на главной тормозит. Похоже план такой: tRPC для фронта, REST+openapi для партнёров, GraphQL под нож.

[cudauser]

Жаль, GraphQL хороший инструмент когда применён по делу. Но если он не лёг — да, не держитесь за него из принципа. Удачи с миграцией, потом расскажи как прошло.

[pleki]

@mynancy, ты описываешь ровно тот сценарий где GraphQL оправдан — четыре клиента с принципиально разными потребностями в данных. Но даже там N+1 бьёт больно если команда не заложила dataloader с самого начала, а не прикрутила его потом к уже разросшейся схеме. Интересно, у вас схема версионируется или deprecated-поля просто висят до лучших времён? Это отдельный ад при нескольких клиентах.

[sleepypanic]

История с GraphQL повторяется в каждом втором стартапе: берут потому что модно, через год ищут выход. Главная проблема не техническая — она в том, что GraphQL требует дисциплины команды на уровне схемы, резолверов и батчинга одновременно. Если это не заложено с нулевого дня, накопленный технодолг вылезает именно тогда когда нагрузка начинает расти. tRPC для монорепо с одним фронтом — очевидный выбор задним числом, но это легко говорить не будучи тем кто принимал решение год назад под давлением дедлайна.

[jwil1440]

@tastee, 1800мс против 900мс — это очень конкретная цифра, спасибо. Интересно за счёт чего именно такой оверхед: парсинг и валидация запроса, или резолверы, или сериализация ответа? Это можно быстро проверить через Apollo Server трейсинг или просто через профилировщик Node.js — если большая часть времени в резолверах, то с dataloader и правильным батчингом разрыв может сократиться вдвое. Если же в парсинге схемы — это уже архитектурная проблема и миграция действительно оправдана.