Ajax - rodzaj zwracania danych

pytanie zadane 30 października 2016 w JavaScript przez Filip2248 Dyskutant (8,840 p.)

Witam. Tworzę kod ajax'a "generujący" część interfejsu na stronie. Dotychczas robiłem to tak: w pliku php wstawiałem zapytanie do bazy. Rekordy które miały być wyświetlone w formie: rekord + parę przycisków do modyfikowania go, wypisywałem pętlą w php. Potem tylko wkładałem w ajax'ie otrzymaną zmienną result do div'a, no i gotowe.

Ostatnio jednak spotkałem się z opcją - zamiast wyświetlania w php gotowych już elementów html, zwrócić ajax'owi string JSON'a z treścią poszczególnych elementów. Tak, żeby js na jego podstawie sam uzupełnił wygenerowane przez siebie elementy.

Wizualizacja :)

Pierwsza opcja:

echo '<p>Przykładowy komentarz</p>';

Druga:

echo '{"p":"Przykładowy komentarz"}';

Pytanie brzmi: Która opcja jest lepsza? Nie generuję na stronie jednego paragrafu tylko cały interfejs.

2 odpowiedzi

odpowiedź 30 października 2016 przez Comandeer Guru (606,240 p.)
wybrane 30 października 2016 przez Filip2248

Najlepsza

A co jeśli user ma wyłączony JS? A co jeśli userowi nie zadziała JS? A co jeśli nowa wersja Chrome'a ma mega buga, który de facto ubija funkcjonalność Ajaksa? A co jeśli proxy wytnie JS? A co jeśli komórka usera straci zasięg i nie doczyta JS-a?

Warto zauważyć, że chyba wszystkie duże i liczące się frameworki na rynku odkryły, że istnieje coś takiego jak "server side rendering". W tym segmencie przoduje od dawna Ember.js, ale React czy Angular 2 podobne techniki również wypracowały. Jak bardzo ważna jest to kwestia, świadczy fakt istnienia tak bardzo hackowatych usług jak chociażby Prerender.IO. I choć głównymi motywacjami twórców frameworków jest zdecydowanie wydajność czy lepsze dostosowanie pod SEO, tak naprawdę znacząco podnosi to dostępność danej strony. Kiedyś nazywano to "izomorficznym JS-em", obecnie to "uniwersalny JS".

I cały ten trend komponuje się także bardzo dobrze ze zmianami, jakie zachodzą po stronie backendu, gdzie coraz żywsza staje się idea middleendu (czy też – jakby to powiedział ktoś z 2016 roku – "backends for frontends"). Idea ta jest bardzo prosta: sam backend to nic innego jak REST API, które zwraca czyste dane (czy to jako JSON, czy to jako XML). Middleend z kolei to usługa, która pośredniczy między klientem (frontendem) a backendem. Usługa, która zwraca pobrane z backendu dane w formie, w której życzy sobie klient. Może to być np. zlepek odpowiedzi z kilku endpointów REST API, ale może to być też gotowy HTML (gdy np. wiadomo, że klientem jest super stary fon). Tak zaprojektowana architektura aplikacji pozwala dostarczać klientowi tego, czego mu potrzeba.

Oczywiście nie zachęcam w tym wypadku do takiej rozbudowy architektury, bo zapewne byłoby to z jednej strony niesamowicie pracochłonne, z drugiej zaś – stanowiłoby pewnie typową armatę na muchę. Niemniej uważam, że odpowiedź z serwera powinna być dostosowana do potrzeb klienta. Oznacza to ni mniej, ni więcej, że jeśli klient posyła żądanie Ajaksem, zwracamy mu czyste dane. W innym wypadku zwracamy mu gotowy HTML. Na takiej zasadzie działa chociażby (zapomniany już [*]) Taunus czy dziwaczny, przekombinowany, ale wciąż ciekawy Next (co pokazuje empirycznie, że React faktycznie się do takich rzeczy nadaje!). No i zawsze zostaje tradycyjny pjax, który również zachęca do takich działań w swoim README.

TL;DR Klient odpytuje serwer Ajaksem – JSON. Klient wysyła normalne żądanie – HTML.

komentarz 30 października 2016 przez Filip2248 Dyskutant (8,840 p.)

Dziękuję za tak rozbudowaną odpowiedź :)

odpowiedź 30 października 2016 przez ribeiro Stary wyjadacz (11,440 p.)

Druga opcja zdaje się być lepsza. Dzięki niej backend zajmuje się wyłącznie wysłaniem odpowiednich danych do frontendu, nie zaś tym, jak ma wyglądać sama ich prezentacja. Wyobraź sobie że zmienią się jakieś zasady tego, jak ma być wyświetlany ten interfejs, z jakich elementów korzystać, albo w ogóle z jakich frameworków JSa. Twój backend wysyłający tylko dane w formacie JSON na podstawie jakiegoś GETa w ogóle nie ulegnie zmianie i nie będzie się tym interesować. Frontend z kolei otrzyma suche dane i wyświetli je według swojego uznania. Z tego też względu nie ma nawet sensu wysyłać informacji o tym, że to ma być paragraf. Po prostu programista zajmujący się tym od strony frontu ma wiedzieć, w czym to umieścić.

1	komentarz 30 października 2016 przez Filip2248 Dyskutant (8,840 p.) Dziękuję za odpowiedź. Dokładnie tak to sam rozumowałem, ale nie wiedziałem czy słusznie. Poczekam jeszcze na odpowiedzi innych :)