Frontend и backend разработка: JavaScript, TypeScript, React, Next.js, Vue, Node.js, PHP, REST и GraphQL API, вёрстка HTML/CSS и современные веб-приложения.
Год назад на хайпе взяли GraphQL для всего. Сейчас имеем N+1 в резолверах, невозможность нормально кешировать на CDN и фронт который всё равно запрашивает одни и те же три эндпоинта. Думаем откатиться. Скажите что мы не одни такие.
✔ Лучший ответ сформирован автоматически — sleepypanic
История с GraphQL повторяется в каждом втором стартапе: берут потому что модно, через год ищут выход. Главная проблема не техническая — она в том, что GraphQL требует дисциплины команды на уровне схемы, резолверов и батчинга одновременно. Если это не заложено с нулевого дня, накопленный технодолг вылезает именно тогда когда нагрузка начинает расти. tRPC для монорепо с одним фронтом — очевидный…
Не одни. Главная ложь про GraphQL это 'клиент берёт только нужные поля'. На практике у тебя 5 фрагментов которые всё равно тянут пол-схемы, плюс ты теряешь http-кеширование напрочь.
Вот это ключевое. GraphQL не убирает сложность, он перекладывает её с фронта на бэк и на инфру. Если у тебя один фронт и один бэк — ты просто добавил геморроя без выгоды.
А мы наоборот довольны. У нас 4 клиента — веб, ios, android и партнёрское api. Без GraphQL это был бы зоопарк из 30 REST-эндпоинтов под каждый экран. Тут он реально на своём месте.
lena_codes вот именно, GraphQL оправдан когда много разных клиентов с разными потребностями в данных. У стартового founder судя по всему один веб-фронт, отсюда и боль.
Наружу для партнёров — обычный REST с openapi-схемой, это стандарт который понимают все. tRPC только для своего фронта. Гибрид это норма, в проде почти всегда несколько стилей api живут рядом.
По цифрам добавлю: у нас простой запрос через GraphQL в среднем 1800мс против 900мс на REST из-за оверхеда резолверов и парсинга. Для перф-критичных ручек мы их вынесли обратно на чистый REST.
