Widzia\u0142em to ju\u017c setki razy. Zesp\u00f3\u0142 developerski sp\u0119dza tygodnie na dopracowaniu interfejsu u\u017cytkownika, animacjach, responsywno\u015bci \u2013 a potem aplikacja i tak dzia\u0142a jak zepsuta winda. U\u017cytkownicy klikaj\u0105, czekaj\u0105, denerwuj\u0105 si\u0119 i odchodz\u0105.<\/p>\n
Problem cz\u0119sto nie le\u017cy we frontendzie, ale w komunikacji z API. To, jak Twoja aplikacja rozmawia z serwerem, ma ogromny wp\u0142yw na UX, wydajno\u015b\u0107 i postrzegan\u0105 szybko\u015b\u0107. A w dobie oczekiwania na natychmiastowe reakcje, ka\u017cda dodatkowa sekunda to utrata klienta.<\/p>\n
W tym artykule przedstawiam trzy najcz\u0119stsze b\u0142\u0119dy w strategiach komunikacji z API, kt\u00f3re widzia\u0142em w produkcyjnych aplikacjach \u2013 i sposoby, jak je naprawi\u0107.<\/p>\n
Wyobra\u017a sobie aplikacj\u0119 e-commerce, kt\u00f3ra przy ka\u017cdym wej\u015bciu na stron\u0119 produktu wysy\u0142a osobne zapytania o cen\u0119, opis, zdj\u0119cia, opinie, dost\u0119pno\u015b\u0107 w magazynie. Ka\u017cde \u017c\u0105danie to osobny HTTP request \u2013 a to kosztuje czas.<\/p>\n
Efekt: u\u017cytkownik widzi wiruj\u0105ce k\u00f3\u0142ko w kilku miejscach na raz, strona \u0142aduje si\u0119 etapami, interfejs jest niesp\u00f3jny. To nie tylko frustruj\u0105ce, ale te\u017c m\u0119cz\u0105ce dla backendu.<\/p>\n
Przyk\u0142ad z \u017cycia:<\/strong> Klient przyszed\u0142 do nas z aplikacj\u0105 SaaS, kt\u00f3ra na dashboardzie wysy\u0142a\u0142a ponad 20 osobnych zapyta\u0144 API przy ka\u017cdym od\u015bwie\u017ceniu. Logowanie u\u017cytkownika trwa\u0142o 8 sekund. Po wprowadzeniu endpoint\u00f3w agreguj\u0105cych (GraphQL lub dedykowane API Gateway) \u2013 czas spad\u0142 do 2 sekund.<\/p>\n Rozwi\u0105zanie:<\/strong> Zamiast dzieli\u0107 dane na ma\u0142e kawa\u0142ki, projektuj endpointy, kt\u00f3re zwracaj\u0105 wszystko, co potrzebne do widoku w jednym \u017c\u0105daniu. Wykorzystaj GraphQL lub pattern BFF (Backend for Frontend).<\/p>\n Drugi cz\u0119sty b\u0142\u0105d to ponowne pobieranie tych samych danych przy ka\u017cdym \u017c\u0105daniu. Widzia\u0142em aplikacje, kt\u00f3re za ka\u017cdym razem, gdy u\u017cytkownik wchodzi\u0142 na stron\u0119 g\u0142\u00f3wn\u0105, pobiera\u0142y list\u0119 kategorii \u2013 list\u0119, kt\u00f3ra zmienia si\u0119 raz w miesi\u0105cu.<\/p>\n To marnuje przepustowo\u015b\u0107 i wyd\u0142u\u017ca czas \u0142adowania. Co gorsza, cz\u0119sto programi\u015bci nie ustawiaj\u0105 nag\u0142\u00f3wk\u00f3w cache, wi\u0119c nawet gdy dane s\u0105 te same, serwer musi je przetworzy\u0107.<\/p>\n Przyk\u0142ad z \u017cycia:<\/strong> W projekcie dla sklepu internetowego, ka\u017cdy produkt pobiera\u0142 z API list\u0119 powi\u0105zanych produkt\u00f3w, kt\u00f3ra by\u0142a identyczna przez ca\u0142y dzie\u0144. Po dodaniu cache\u2019owania po stronie klienta (np. z u\u017cyciem localStorage i timestamp\u00f3w) \u2013 \u015bredni czas renderowania strony produktu spad\u0142 o 40%.<\/p>\n Rozwi\u0105zanie:<\/strong> Wykorzystaj nag\u0142\u00f3wki Cache-Control, a tak\u017ce mechanizmy cache w service workerach (je\u015bli u\u017cywasz PWA) lub prosty cache w pami\u0119ci aplikacji. Nie pobieraj tego, co ju\u017c masz.<\/p>\n Trzeci b\u0142\u0105d to brak obs\u0142ugi scenariuszy awaryjnych. API nie dzia\u0142a? Aplikacja pokazuje bia\u0142y ekran albo wieczne \u201e\u0142adowanie\u201d. U\u017cytkownik nie wie, co si\u0119 dzieje \u2013 czy ma czeka\u0107, czy od\u015bwie\u017cy\u0107, czy zrezygnowa\u0107.<\/p>\n Widzia\u0142em aplikacj\u0119, w kt\u00f3rej po b\u0142\u0119dzie autoryzacji (401) nie nast\u0119powa\u0142o automatyczne od\u015bwie\u017cenie tokena \u2013 u\u017cytkownik by\u0142 przekierowywany na pust\u0105 stron\u0119 z komunikatem w konsoli.<\/p>\n Przyk\u0142ad z \u017cycia:<\/strong> W mobilnej aplikacji bankowej, kt\u00f3rej audytowa\u0142em, timeout na \u017c\u0105danie ustawiony by\u0142 na 30 sekund. U\u017cytkownicy my\u015bleli, \u017ce aplikacja si\u0119 zawiesi\u0142a \u2013 i j\u0105 zamykali. Po skr\u00f3ceniu timeoutu do 10 sekund i dodaniu komunikatu \u201eTrwa \u0142\u0105czenie z serwerem\u2026\u201d \u2013 liczba porzuconych transakcji spad\u0142a o 25%.<\/p>\n Rozwi\u0105zanie:<\/strong> Zawsze obs\u0142uguj b\u0142\u0119dy \u2013 poka\u017c u\u017cytkownikowi przyjazny komunikat, daj mo\u017cliwo\u015b\u0107 ponowienia. Ustaw rozs\u0105dne timeouty (zale\u017cnie od operacji). U\u017cywaj retry z backoffem, ale nie bez ko\u0144ca. Monitoruj b\u0142\u0119dy i reaguj.<\/p>\n Komunikacja z API to cz\u0119sto pomijany element strategii UX. Tymczasem jej optymalizacja mo\u017ce przynie\u015b\u0107 spektakularne efekty \u2013 szybsze \u0142adowanie, mniejsze obci\u0105\u017cenie serwera i wi\u0119ksze zadowolenie u\u017cytkownik\u00f3w. Zanim zaczniesz przepisywa\u0107 frontend, sp\u00f3jrz na to, jak rozmawia z backendem. Cz\u0119sto to w\u0142a\u015bnie tam tkwi najwi\u0119kszy potencja\u0142.<\/p>\n W JurskiTech.pl od lat pomagamy firmom diagnozowa\u0107 i naprawia\u0107 takie problemy. Je\u015bli podejrzewasz, \u017ce Twoja aplikacja traci u\u017cytkownik\u00f3w przez \u201egadatliwe\u201d API \u2013 ch\u0119tnie przyjrzymy si\u0119 jej z bliska.<\/p>\n","protected":false},"excerpt":{"rendered":" Dlaczego Twoja aplikacja traci u\u017cytkownik\u00f3w przez z\u0142e strategie komunikacji z API? Widzia\u0142em to ju\u017c setki razy. Zesp\u00f3\u0142 developerski sp\u0119dza tygodnie na dopracowaniu interfejsu u\u017cytkownika, animacjach, responsywno\u015bci \u2013 a potem aplikacja i tak dzia\u0142a jak zepsuta winda. U\u017cytkownicy klikaj\u0105, czekaj\u0105, denerwuj\u0105 si\u0119 i odchodz\u0105. Problem cz\u0119sto nie le\u017cy we frontendzie, ale w komunikacji z API. To,<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7],"tags":[826,699,798,1003],"class_list":["post-2829","post","type-post","status-publish","format-standard","hentry","category-warto-wiedziec","tag-ai-w-ux","tag-api-gateway","tag-bledy-404","tag-debugowanie-wydajnosci"],"_links":{"self":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2829","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/comments?post=2829"}],"version-history":[{"count":0,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2829\/revisions"}],"wp:attachment":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/media?parent=2829"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/categories?post=2829"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/tags?post=2829"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}2. Brak cache\u2019owania po stronie klienta<\/h3>\n
3. Z\u0142e zarz\u0105dzanie b\u0142\u0119dami i timeoutami<\/h3>\n
Podsumowanie<\/h2>\n