Описание проекта
Мы переходим со стареющего REST API на GraphQL, чтобы обслуживать сразу двух клиентов — мобильное приложение на React Native и SPA на React. Латать старые эндпоинты мы не хотим: нужен слой GraphQL, собранный с нуля и по уму, поэтому ищем разработчика уровня senior с реальным опытом Apollo Server в продакшне. Цель — единый, аккуратно типизированный граф, на который смогут опираться оба клиента, с предсказуемой производительностью и без внезапных N+1, когда экран подгружает список связанных записей.
Работа охватывает весь стек GraphQL-бэкенда: type-first схему для наших ключевых сущностей, резолверы поверх оптимизированного слоя PostgreSQL, JWT-аутентификацию, проброшенную через context, и авторизацию на уровне полей, чтобы разные роли видели только положенное. Важна и real-time часть — статус заказа и уведомления должны доходить до клиентов через WebSocket-подписки, а не через постоянный опрос. Кроме корректности нам важны безопасность и контроль стоимости запросов: ограничение глубины и сложности, а также persisted queries для мобильных клиентов.
Поскольку это замена живого API, чистый путь миграции и понятная документация — часть задачи, а не бонус. Расскажите про GraphQL API, который вы уже выпускали, и как решали вопросы авторизации и производительности. Подробный объём ниже.
1. Дизайн схемы
— Type-first: User, Product, Order, Review, Notification
— Типы ввода, мутации
— Кастомные скаляры (Date, JSON, Upload)
— Enum-типы для статусных полей
2. Реализация
— Apollo Server 4 + Express
— DataLoader для предотвращения N+1 запросов
— JWT-аутентификация через context
— Авторизация на уровне полей
— Subscriptions через WebSocket (статус заказа, уведомления)
3. Производительность и качество
— Ограничение глубины/сложности запросов
— Persisted queries для мобильных клиентов
— Оптимизация PostgreSQL (EXPLAIN ANALYZE)
— Юнит-тесты резолверов (Jest + Supertest)
— Apollo Studio интеграция
4. Документация
— Документированная схема (описания всех типов)
— Postman/Insomnia-коллекция
— Гайд по миграции с REST
Работа охватывает весь стек GraphQL-бэкенда: type-first схему для наших ключевых сущностей, резолверы поверх оптимизированного слоя PostgreSQL, JWT-аутентификацию, проброшенную через context, и авторизацию на уровне полей, чтобы разные роли видели только положенное. Важна и real-time часть — статус заказа и уведомления должны доходить до клиентов через WebSocket-подписки, а не через постоянный опрос. Кроме корректности нам важны безопасность и контроль стоимости запросов: ограничение глубины и сложности, а также persisted queries для мобильных клиентов.
Поскольку это замена живого API, чистый путь миграции и понятная документация — часть задачи, а не бонус. Расскажите про GraphQL API, который вы уже выпускали, и как решали вопросы авторизации и производительности. Подробный объём ниже.
1. Дизайн схемы
— Type-first: User, Product, Order, Review, Notification
— Типы ввода, мутации
— Кастомные скаляры (Date, JSON, Upload)
— Enum-типы для статусных полей
2. Реализация
— Apollo Server 4 + Express
— DataLoader для предотвращения N+1 запросов
— JWT-аутентификация через context
— Авторизация на уровне полей
— Subscriptions через WebSocket (статус заказа, уведомления)
3. Производительность и качество
— Ограничение глубины/сложности запросов
— Persisted queries для мобильных клиентов
— Оптимизация PostgreSQL (EXPLAIN ANALYZE)
— Юнит-тесты резолверов (Jest + Supertest)
— Apollo Studio интеграция
4. Документация
— Документированная схема (описания всех типов)
— Postman/Insomnia-коллекция
— Гайд по миграции с REST
Веб программирование Наличные, Банковский перевод
