Опис проєкту
ПерекладУ нас працює кілька REST-мікросервісів, кожен з яких відповідає за свій участок домену — користувачі, каталог, замовлення, білінг. Веб- та мобільні клієнти стомилися робити по три-чотири запити підряд, щоб відрисувати один екран. Нам потрібен GraphQL-шлюз, який встане перед цими сервісами, віддасть одну акуратну єдину схему і дозволить клієнтам за один запит отримувати рівно ті поля, які їм потрібні. Підкреслюємо: це саме завдання шлюзу, а не переписування — REST-API залишаються як є, а ваш шар їх агрегує та федерує.
Основна частина роботи — проектування схеми та резолвери. Чекаємо добре структурованої системи типів з зрозумілими іменами та резолверів, які звертаються до нижчележних REST-ендпоінтів, зшивають пов'язані сутності та розв'язують кросс-сервісні посилання без класичного вибуху N+1 — тобто батчинг та паттерн data loader на кожний запит обов'язкові. Поверх цього потрібно кешування відповідей з адекватною інвалідацією та авторизація: пробрасувати токен викликаючого, перевірити його на шлюзі та застосувати правила доступу на рівні полів та типів. Будь ласка, обробляйте часткові збої акуратно, щоб один повільний бекенд не роз'єднував весь запит.
Щоб не було плутанини: це не мок-сервер API та не вебхук-шлюз — нам потрібен саме бойовий шар агрегації GraphQL над живими REST-API. Результат повинен запускатися, бути задокументованим і покритим тестами. Напишіть, який стек ви віддаєте перевагу (Node з Apollo, федеративний маршрутизатор або інший підхід) і чому. Оцінка — три тижні, для сильного інженера строки обговорювані.
— Єдина схема GraphQL над 4+ REST-сервісами
— Резолвери зі зшиванням, федерацією та data loader
— Кешування відповідей і стратегія інвалідації
— Пробрасування токену та авторизація на рівні полів та типів
— Тести, документація та локальний docker-compose для запуску
Основна частина роботи — проектування схеми та резолвери. Чекаємо добре структурованої системи типів з зрозумілими іменами та резолверів, які звертаються до нижчележних REST-ендпоінтів, зшивають пов'язані сутності та розв'язують кросс-сервісні посилання без класичного вибуху N+1 — тобто батчинг та паттерн data loader на кожний запит обов'язкові. Поверх цього потрібно кешування відповідей з адекватною інвалідацією та авторизація: пробрасувати токен викликаючого, перевірити його на шлюзі та застосувати правила доступу на рівні полів та типів. Будь ласка, обробляйте часткові збої акуратно, щоб один повільний бекенд не роз'єднував весь запит.
Щоб не було плутанини: це не мок-сервер API та не вебхук-шлюз — нам потрібен саме бойовий шар агрегації GraphQL над живими REST-API. Результат повинен запускатися, бути задокументованим і покритим тестами. Напишіть, який стек ви віддаєте перевагу (Node з Apollo, федеративний маршрутизатор або інший підхід) і чому. Оцінка — три тижні, для сильного інженера строки обговорювані.
— Єдина схема GraphQL над 4+ REST-сервісами
— Резолвери зі зшиванням, федерацією та data loader
— Кешування відповідей і стратегія інвалідації
— Пробрасування токену та авторизація на рівні полів та типів
— Тести, документація та локальний docker-compose для запуску
Веб програмування Готівка, Банківський переказ
