5 technik optymalizacji API, które realnie przyspieszają aplikację

Wstęp

Wydajność API to jeden z tych tematów, o którym wszyscy mówią, ale mało kto robi to dobrze. Zauważam, że w rozmowach z klientami często słyszę: „API mamy szybkie, problem leży gdzie indziej”. Tymczasem po wdrożeniu kilku prostych optymalizacji czas odpowiedzi spada o 40-60%, a użytkownicy przestają narzekać na „lagi”. W tym artykule pokażę 5 technik, które sam stosuję w projektach – od małych sklepów e-commerce po platformy SaaS.

1. Paginacja cursor-based zamiast offsetowej

Większość developerów domyślnie sięga po LIMIT i OFFSET w SQL, bo to proste. Problem zaczyna się, gdy dane rosną. Offsetowa paginacja skaluje się liniowo – im głębiej, tym wolniej. Przy 100 tysiącach rekordów i offset=50k, baza musi przeskanować 50 tysięcy wierszy, zanim zwróci właściwe 20.

Rozwiązanie? Paginacja cursorowa. Zamiast numeru strony, klient wysyła identyfikator ostatniego elementu z poprzedniej odpowiedzi (np. ?cursor=eyJpZCI6MTIzNH0=). Backend wykonuje prosty WHERE id > :cursor LIMIT 20, co jest praktycznie O(1) niezależnie od rozmiaru zbioru.

Przykład z życia: W migracji API dla sklepu z 200k produktów, zmiana z offsetu na kursory skróciła średni czas odpowiedzi z 1.2s do 200ms, a baza przestała generować alerty o wysokim CPU.

2. Response caching na poziomie API Gateway

Często widzę, że każdy endpoint jest traktowany tak samo – bez cache’owania, nawet jeśli dane zmieniają się rzadko (np. lista kategorii, regulamin czy opisy produktów). Tymczasem dobrze skonfigurowany cache może obsłużyć 90% żądań bez dotykania backendu.

Użyj API Gateway (np. Cloudflare, AWS, Kong) lub wstaw warstwę Redis/Varnish. Ustaw nagłówki Cache-Control: public, max-age=3600 dla zasobów statycznych. Dla dynamicznych danych, gdzie każdy użytkownik widzi coś innego, rozważ cache prywatny z s-maxage dla CDN i private dla przeglądarki.

Przykład z życia: W platformie kursowej z 10k użytkowników, strona główna kategorii była renderowana dla każdego requestu. Po dodaniu cache’u Redis z TTL 5 minut, obciążenie serwera spadło o 80%, a czas odpowiedzi z 300ms do 5ms.

3. Kompresja JSON-a i serializacja

Serializacja/deserializacja JSON-a jest droższa, niż myślisz. W aplikacjach Node.js często stanowi 20-30% czasu odpowiedzi. Można to poprawić na dwa sposoby:

• Wybór szybszego serializatora: Zamiast domyślnego JSON.stringify, użyj fast-json-stringify lub msgpack. W testach na dużej strukturze JSON (10KB) fast-json-stringify był 3x szybszy.
• Kompresja odpowiedzi: Włącz gzip lub brotli na poziomie serwera. W przypadku API HTTP/2, brotli daje lepszą kompresję (nawet 20% mniejszy rozmiar niż gzip) przy niskim koszcie CPU.

Przykład z życia: W jednym projekcie SaaS, gdzie API zwracało listę 500 obiektów po 2KB każdy, zmiana serializatora i włączenie brotli skróciło czas odpowiedzi z 120ms do 45ms, a transfer danych zmniejszył się o 65%.

4. Connection pooling i persistent connections

Każde nowe połączenie z bazą danych kosztuje czas i zasoby. W środowisku produkcyjnym bez poolowania, przy 100 równoczesnych requestach, powstaje 100 nowych połączeń, co może przeciążyć bazę.

Rozwiązanie to connection pooling. W PostgreSQL używamy pg-pool lub w MySQL mysql2/pool. Dla zapytań HTTP do zewnętrznych API – keep-alive i agent z pulą.

Przykład z życia: W aplikacji, która integruje się z 3 zewnętrznymi API, brak keep-alive powodował opóźnienia rzędu 300ms na każde żądanie (TCP handshake). Po włączeniu persistent connections czas skrócił się do 30ms na żądanie.

5. Batching i deduplikacja zapytań

Częsty problem: frontend wysyła 10 osobnych requestów, podczas gdy jeden batch mógłby je zastąpić. Np. panel administratora ładuje statystyki dla 10 produktów – każde osobne API to osobny koszt.

Zaimplementuj endpoint POST /batch lub GET /products?ids=1,2,3,4,5. W backendzie użyj deduplikacji zapytań: jeśli dwa requesty dotyczą tych samych danych w krótkim czasie (np. w promieniu 50ms), połącz je w jedno zapytanie do bazy.

Przykład z życia: W dashboardzie SaaS z 50 użytkownikami, każdy ładował swoje dane w pętli 15 requestów. Po dodaniu batchnigu i cache’a zapytań (DataLoader w GraphQL), średni czas ładowania strony spadł z 4s do 0.8s.

Podsumowanie

Optymalizacja API nie musi oznaczać przepisywania całego systemu. Wystarczy spojrzeć na najczęstsze wąskie gardła: paginację, cache, serializację, połączenia i batchnig. Każda z tych technik jest stosunkowo prosta do wdrożenia, a korzyści są natychmiastowe – szybsze odpowiedzi, mniejsze obciążenie serwera i zadowoleni użytkownicy.

Jeśli chcesz, żeby Twoje API działało jak dobrze naoliwiona maszyna, zacznij od tych pięciu kroków. A gdybyś potrzebował wsparcia – w JurskiTech.pl pomagamy firmom w optymalizacji wydajności na co dzień.