Opis projektu
PrzetłumaczonePraca obejmuje cały stos backendowy GraphQL: schemat typu-first dla naszych kluczowych encji, resolwery na zoptymalizowanej warstwie PostgreSQL, uwierzytelnianie JWT przekazywane przez kontekst oraz autoryzację na poziomie pól, aby różne role widziały tylko to, co powinny. Część w czasie rzeczywistym również ma znaczenie — status zamówienia i powiadomienia muszą docierać do klientów za pośrednictwem subskrypcji WebSocket, a nie ciągłego polling. Poza poprawnością, zależy nam na bezpieczeństwie i kontroli kosztów zapytań: limity głębokości i złożoności, plus zapytania utrwalone dla klientów mobilnych.
Ponieważ to zastępuje działające API, czysta ścieżka migracji i jasna dokumentacja są częścią zadania, a nie bonusem. Opowiedz nam o API GraphQL, które wdrożyłeś i jak rozwiązałeś problemy z autoryzacją i wydajnością. Szczegółowy zakres poniżej.
1. Projektowanie schematu
— Typ-first: Użytkownik, Produkt, Zamówienie, Recenzja, Powiadomienie
— Typy wejściowe, mutacje
— Niestandardowe skalarne (Data, JSON, Upload)
— Typy enum dla pól statusu
2. Implementacja
— Apollo Server 4 + Express
— DataLoader, aby zapobiec zapytaniom N+1
— Uwierzytelnianie JWT przez kontekst
— Autoryzacja na poziomie pól
— Subskrypcje przez WebSocket (status zamówienia, powiadomienia)
3. Wydajność i jakość
— Limity głębokości/złożoności zapytań
— Utrwalone zapytania dla klientów mobilnych
— Optymalizacja PostgreSQL (EXPLAIN ANALYZE)
— Testy jednostkowe dla resolwerów (Jest + Supertest)
— Integracja z Apollo Studio
4. Dokumentacja
— Udokumentowany schemat (opisy wszystkich typów)
— Kolekcja Postman/Insomnia
— Przewodnik migracji z REST