В нашем продукте несколько REST-микросервисов, и каждый ведёт свою область — профили, каталог, заказы, платежи. Проблема в том, что фронтенд и приложение вынуждены дёргать по несколько эндпоинтов ради одного экрана, и это бьёт по скорости и по коду. Хотим получить GraphQL-шлюз, который встанет впереди сервисов, соберёт из них одну общую схему и даст клиенту забирать нужные поля одним обращением. Важно: сервисы переписывать не нужно, ваша прослойка только агрегирует и объединяет уже готовые REST-API.
Главное в проекте — грамотная схема и резолверы. Хотим увидеть продуманную систему типов с внятным неймингом; резолверы должны ходить в REST-эндпоинты, склеивать связанные сущности и подтягивать ссылки между сервисами без проблемы N+1, поэтому пакетная загрузка и data loader на каждый запрос считаем обязательными. Дальше — кеш ответов с разумным сбросом и безопасность: прокидывать токен клиента, валидировать его на шлюзе и ограничивать доступ на уровне отдельных полей и типов. Отдельно просим корректно переживать частичные отказы, чтобы один тормозящий сервис не обрушивал весь ответ целиком.
Сразу оговоримся по границам: нам не нужен ни имитатор API, ни приёмник вебхуков — задача именно в рабочем агрегирующем слое GraphQL поверх живых REST-сервисов. Итог должен запускаться локально, иметь документацию и тесты. В отклике опишите предпочитаемый стек (Node с Apollo, федеративный роутер или своё решение) и обоснуйте выбор. Ориентир по срокам — около трёх недель, с толковым специалистом готовы обсуждать.
— Общая схема GraphQL над 4+ REST-сервисами
— Резолверы со склейкой, федерацией и data loader
— Кеширование ответов и понятный механизм сброса
— Проброс токена и контроль доступа по полям и типам
— Тесты, документация и локальный docker-compose
Главное в проекте — грамотная схема и резолверы. Хотим увидеть продуманную систему типов с внятным неймингом; резолверы должны ходить в REST-эндпоинты, склеивать связанные сущности и подтягивать ссылки между сервисами без проблемы N+1, поэтому пакетная загрузка и data loader на каждый запрос считаем обязательными. Дальше — кеш ответов с разумным сбросом и безопасность: прокидывать токен клиента, валидировать его на шлюзе и ограничивать доступ на уровне отдельных полей и типов. Отдельно просим корректно переживать частичные отказы, чтобы один тормозящий сервис не обрушивал весь ответ целиком.
Сразу оговоримся по границам: нам не нужен ни имитатор API, ни приёмник вебхуков — задача именно в рабочем агрегирующем слое GraphQL поверх живых REST-сервисов. Итог должен запускаться локально, иметь документацию и тесты. В отклике опишите предпочитаемый стек (Node с Apollo, федеративный роутер или своё решение) и обоснуйте выбор. Ориентир по срокам — около трёх недель, с толковым специалистом готовы обсуждать.
— Общая схема GraphQL над 4+ REST-сервисами
— Резолверы со склейкой, федерацией и data loader
— Кеширование ответов и понятный механизм сброса
— Проброс токена и контроль доступа по полям и типам
— Тесты, документация и локальный docker-compose
