Опис проєкту
ПерекладМи переходимо зі застарілого 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
Веб програмування Готівка, Банківський переказ
