nieefektywne zapytania do API

Nieefektywne zapytania do API to wielokrotne pobieranie tych samych danych zamiast korzystania z operacji zbiorczych.

Skąd bierze się nieefektywność zapytań do API

Nieefektywne zapytania do API powstają wtedy, gdy aplikacja pobiera dane w sposób powodujący niepotrzebne operacje po stronie serwera, sieci albo bazy danych. Typowym przykładem jest wykonanie osobnego żądania dla każdego elementu listy. Jeżeli ekran ma wyświetlić informacje o 100 produktach, a program najpierw pobiera listę produktów, a następnie wysyła 100 kolejnych zapytań po szczegóły każdego rekordu, powstaje wzorzec nazywany często „N+1 queries”. Dane mogłyby zostać pobrane jednym żądaniem zbiorczym albo za pomocą mechanizmu dołączania powiązanych obiektów.

Problemem może być również wielokrotne pobieranie tego samego zasobu bez wykorzystania pamięci podręcznej, parametrów warunkowego żądania lub lokalnego stanu aplikacji. Powtarzające się żądania zwiększają liczbę przesyłanych bajtów, wydłużają czas oczekiwania i zużywają limity ustalone przez dostawcę API. Nieefektywność nie oznacza wyłącznie dużych odpowiedzi. Małe żądanie wysyłane setki razy może obciążać system bardziej niż jedno większe zapytanie, zwłaszcza gdy każde wywołanie wymaga uwierzytelnienia, otwarcia połączenia i wykonania zapytania po stronie usługi.

Wielokrotne pobieranie danych a opóźnienie działania programu

Każde zapytanie do API składa się z kilku etapów: przygotowania żądania przez aplikację, przesłania go przez sieć, obsługi po stronie serwera oraz odebrania i przetworzenia odpowiedzi. Opóźnienie jednego wywołania może być niewielkie, ale przy sekwencyjnym wykonywaniu wielu żądań sumuje się. Gdy aplikacja czeka na zakończenie pierwszego żądania przed rozpoczęciem następnego, czas ładowania rośnie proporcjonalnie do liczby operacji. Równoległe wysyłanie żądań może skrócić czas oczekiwania, lecz nie usuwa kosztu nadmiarowych operacji i może doprowadzić do przekroczenia limitu jednoczesnych połączeń.

Skutki są widoczne między innymi jako opóźnione odświeżanie widoku, chwilowe puste listy, powtarzające się komunikaty o ładowaniu albo błędy limitu zapytań. Dostawca API może stosować ograniczenie liczby wywołań w określonym czasie, czyli rate limiting. Po przekroczeniu limitu serwer może zwrócić kod HTTP 429 Too Many Requests, czasem razem z nagłówkiem Retry-After wskazującym, kiedy ponowić próbę. Jeżeli aplikacja nie obsługuje takiej odpowiedzi, użytkownik może zobaczyć niepełne dane, mimo że sama usługa działa prawidłowo.

Operacje zbiorcze, filtrowanie i kontrola odpowiedzi

Podstawową metodą poprawy jest ograniczenie liczby wywołań poprzez pobieranie danych zbiorczych. API może udostępniać endpoint przyjmujący wiele identyfikatorów w jednym żądaniu, parametry filtrowania, sortowania i stronicowania albo możliwość określenia wymaganych pól. Wykorzystanie takich mechanizmów pozwala pobrać tylko rekordy potrzebne do konkretnego widoku. Stronicowanie ma znaczenie wtedy, gdy zbiór jest duży: aplikacja nie musi pobierać całej historii, jeżeli użytkownik ogląda tylko pierwszą stronę wyników.

Warto także stosować pamięć podręczną dla danych, które nie zmieniają się przy każdym odczycie. Przy żądaniach HTTP pomocne mogą być nagłówki ETag i If-None-Match. Klient wysyła identyfikator poprzedniej wersji zasobu, a serwer może odpowiedzieć kodem 304 Not Modified bez ponownego przesyłania pełnej treści. W przypadku danych często aktualizowanych czas przechowywania w pamięci podręcznej powinien odpowiadać wymaganiom aplikacji. Zbyt długi czas może pokazywać nieaktualne informacje, a całkowity brak cache zwiększa ruch i liczbę operacji.

Rozpoznanie problemu na laptopie lub komputerze PC

Analiza nieefektywnych zapytań wymaga porównania logów aplikacji, czasu odpowiedzi i liczby wywołań przypadających na jedną akcję użytkownika. Pomocne są narzędzia deweloperskie przeglądarki, szczególnie karta Network, w której można sprawdzić adresy endpointów, metody HTTP, kody odpowiedzi, rozmiary transferu oraz moment rozpoczęcia i zakończenia żądania. W aplikacji działającej lokalnie warto rejestrować identyfikator żądania, czas trwania operacji i przyczynę odświeżenia danych, bez zapisywania haseł ani tokenów uwierzytelniających.

Warszawskie Pogotowie Komputerowe wykonuje profesjonalną diagnostykę laptopów i komputerów PC, gdy spowolnienie programu, problemy z połączeniem sieciowym lub niestabilne działanie aplikacji wymagają sprawdzenia sprzętu i konfiguracji systemu. W ramach takiej analizy można rozróżnić problem samego API od problemu lokalnego, na przykład przeciążenia procesora, braku pamięci operacyjnej, błędów sterownika sieciowego albo nieprawidłowej konfiguracji programu. Sama wymiana podzespołu nie naprawi kodu wysyłającego nadmiarowe żądania, dlatego istotne jest ustalenie, czy opóźnienie powstaje w aplikacji, w sieci, czy po stronie zewnętrznej usługi.