Cześć,
mam na stronie kilka sekcji, zawierających jakieś dane. Wchodzę na stronę i dane się zaciągają z API.
Które podejście będzie lepsze (i dlaczego)? :
Thank you from the mountain
na moje rozumienie, cała ta rewolucja z dwuwarstwowymi aplikacjami głosiła na sztandarach że API są proste oraz ortogonalne względem siebie. I np Twoje sekcje mogą być developowane niezależnie od siebie i od serwera (bo wszystko może być developowane niezależnie)
Bardzie koszerne jest z całą pewnością niezależne.
Inaczej API nie będzie uniwersalne, będzie krojone tylko i wyłącznie pod konkretny widok (i nieustanne telefony do backendowca)
Ale potrafię podać złośliwy przykład, w rodzaju że saldo konta w jednej sekcji jest inne suma obrotów w drugiej (bo tak się złożyło w milisekundach)
To byłby argument za jednym wywołaniem brzydkiego all-in-one.
I teraz mi wytłumaczcie, dlaczego to rzekomo ma to być lepsze od generowania strony po stronie serwera, gdzie to miałem spójne z mocy ustawy :(
Słuszna uwaga.
Ja bardziej zastanawiałem się pod kątem wydajności, obciążenia, itd.
Ale Twoje wątpliwości również są zasadne
Zrób tak jak będzie Ci łatwiej. Problem obciążenia zostaw do rozwiązania dopiero wtedy gdy faktycznie okaże się on problemem.
Standardowa odpowiedź konsultanta #1 - "to zależy" :)
Ogólnie oczywiście lepiej jest zrobić osobne requesty per osobne komponenty na froncie, wtedy powiązanie frontend-backend jest luźniejsze, zresztą, taka jest w ogóle idea API - backend wystawia jakieś dane, frontend robi co potrzebuje, nie wiedzą o sobie nawzajem.
Natomiast z drugiej strony - pracowałem w projekcie, w którym podejście "osobny request per komponent na stronie" (plus każdy komponent potrzebował kilka/kilkanaście razy odpytać API) spowodowało po roku developmentu, iż zalogowanie się użytkownika i pokazanie strony głównej (kilka sekcji) wymagało chyba z 200 niezależnych requestów (większość się duplikowała wielokrotnie), co masakrowało UX i wydajność backendu. Wiadomo że lepiej do tego stanu nie doprowadzić ;) natomiast użytkownicy w 95% na tym kończyli interakcję ze stroną (chcieli tylko podgląd danych), więc jako quick fix można by spakować wszystko potrzebne do wyświetlenia głównej strony w 1 endpoint, ładnie zoptymalizować, i wtedy byłoby to IMO uzasadnione.
DHTML dzielnie walczy z problemami nieznanymi w klasycznej sieci web.
Skoro zaczynasz rozważać, czy X albo XX zapytań wysyłanych do serwera stanowi problem, to czy przesyłanie surowych danych do przetworzenia i wyświetlenia faktycznie stanowi tu jakiś zysk względem sytuacji, gdy dane grupowane są po stronie serwera i wysyłane w postaci gotowej strony?