Kiedy ma sens zwracanie gotowego do wstrzyknięcia HTMLa w requestach zamiast danych w jakimś w/w formacie?
Dlaczego tak niewiele produktów decyduje się na to rozwiązanie? chyba tylko u facebooka to zauważyłem
jedyne co mi przychodzi do głowy to sytuacja gdy chcemy mieć dość prosty frontend np. bez frameworka, a nadal mieć dynamikę itd.
Bo to ograniczenie, mając na wyjściu xml/JSON możemy wykorzystać to nie tylko do karmienia stron WWW
Niekoniecznie, przecież odpytujący zawsze może się określić czy chce xmla, czy jsona lub htmla :)
Widziałem rozwiazania z przełącznikiem xml/json, ale htmla nigdy.
No tak się robiło zanim hipsterzy stwierdzili, że teraz trzeba mieć wszystko RESTowo.
Ale jakie to ma zalety teraz?
Jaki powód mógłby mieć Facebook aby to robić?
Mniejsze zużycie zasobów u klienta? optymalizowanie pod czas baterii, a zatem potencjalne wydłużenie czasu korzystania z appki (strony)?
Jedyną sensowną przyczyną, jaką widzę przejściu html -> doczytywany html -> parsowany xml -> parsowany json, jest to, że każde kolejne rozwiązanie zmniejsza ilość danych wysyłanych z serwera.
Tyle w teorii. W praktyce ta oszczędność jest doskonale zabijana przez absolutną rozrzutność odnośnie multimediów, a w przypadku stron, do których odbiorca regularnie nie wraca, ale np. incydentalnie je odwiedza jest koncertowo zarzynana już przez sam liczony w megabajtach rozmiar bibliotek i frejmłorków, które trzeba wcześniej załadować, żeby cały system w ogóle mógł zacząć działać.
W przypadku dużych i popularnych może to mieć pewien sens. W przypadku pomniejszych stron sensu w tym za bardzo nie ma. To trochę tak, jakby wszyscy chcieli np. jeździć samochodami terenowymi z napędem na cztery koła.
Istnieje kilka uzasadnień. Choć wszystkie sprowadzają się do implementacji BFF. Pozwala to na dodawanie nowych elementów do UI bez większego ryzyka, że klientowi „nie ruszy”. Pozwala to też na lepszą obsługę rozdrobnionych UI np. Androida, bo tworzymy specyficzny dla systemu szkielet i wypełniamy go treścią z serwera.
o, faktycznie.
Zamiast udostępniać dane, które mogą się zmieniać i musiałyby dostać wsparcie na UI, to udostępniamy gotowy box, nice.
No ale dalej to się robi Server Side Rendering
@donPietro: tak, ale dzięki temu możesz łatwiej ogarnąć pewne problemy. Poza wyżej wspomnianym dostarczaniem na różne środowiska masz też większe możliwości związane z agregacją mikroserwisów. Jeżeli coś nie działa, to po stronie serwera jest to łatwiej ogarnąć niż po stronie klienta. Chociażby dzięki lepszym łączom czy dużo większym możliwościom składowania danych.
Powiedziałbym, że SSR teraz jest na topie frameworki takie jak next.js czy nuxt.js biją rekordy popularności w społeczności frontend.