Frond-end z innej perspektywy - jak to powinno wygladac

pytanie zadane 30 maja 2023 w JavaScript przez Ardzej16 Początkujący (450 p.)

Cześć.

Dobra, zadam głupie pytanie, ale najpierw wyjaśnię, że bawie się w back-end, w PHP.

Tak z pasji wszystko, siedzę po godzinach i piszę sobie framework.

Ciekawi mnie, bardzo chce to pojąć (chyba jestem za głupi, może Wy mi łopatologicznie wytłumaczycie) jak zrobić front-end.

Od początku.

W skrócie u mnie do tej pory wygląda tak, że mam serwer, tam jest cała strona. Router wywołuje odpowiedni kontroler, kontroler w razie potrzeby łączy się z modelem, model pobiera dane i zwraca do kontrolera, między czasie kontroler sprawdza czy są prawa dostępu, czy user zalogowany i inne bzdety. Na koniec wywoływany jest widok (z wysyłką ewentualnych danych). Ten wysyła dane jSON (API) lub uruchamia szablon, dodało odpowiednie CSSy, skrypty i ciało strony (tak w skrócie to co w <body></body>).

W szablonie tym (lub podpiętymi skryptami do niego w widoku) jak jest potrzeba pobieram dodatkowe dane, np poprzez ajax i wyświetlam modyfikująć html (DOM i te sprawy).

Tak to wygląda teraz.

I tu moje głupie pytanie:

Jak to powinno się robić?

W mojej głowie, w moim opisie, wszystko do słowach o widoku mam dobrze zrobione. Ale jeśli chciałbym na innym serwerze mieć sam widok i pobierać informacje z API (tego serwera opisanego wyżej).

Jak to powinienem zrobić? Postawić serwer dla widoku, tam PHPem wrzucić sam widok z tego co opisywałem wyżej i pobierać wszystkie dane łączącc się z serwerem gdzie jest API.

A może jakoś tworzyć szablony w JS i pobierać np ajaxem dane z API. Tylko w tym przypadku co z odświeżaniem adresu w przeglądarce, cofaniem do poprzedniej strony, itd.

Bawie się trochę w programowanie na Androida. Tam jest, hmmm... "prościej". Łącze się z API wysyłąjąc żądanie i pobieram dane, które sobie wyświetlam.

Jak to się robi przy tworzeniu stron internetowych? I czy moje podejście, którym aktualnie się posługuje jest opowiednie?

Prosze pomóżcie bo ślęcze przy tym i nie mogę ogarnąć tej jednej kwestii.

Przepraszam za chaos, pytajcie o szczegóły, i prosze za bardzo mnie nie skarćcie :)

2 odpowiedzi

odpowiedź 30 maja 2023 przez Comandeer Guru (600,810 p.)

Podejście, które obecnie stosujesz, w sumie powoli zyskuje drugą młodość, dzięki rozwiązaniom pokroju Hotwire. Zresztą GitHub AFAIR od niemal zawsze korzystał z podobnej techniki.

Niemniej bardzo często backend sprowadzany jest głównie do REST API (lub innego rodzaju API, np. GraphQL), do którego będą wysyłały żądania różne aplikacje. Autoryzacja często przebiega przy użyciu takich rzeczy jak OAuth i/lub JWT, dzięki czemu całość komunikacji można zamknąć w żądania HTTP.

Często istnieje też warstwa tzw. middleendu, czyli takiego backendu przeznaczonego wyłącznie do generowania frontendu. Middleend jest odpowiedzialny za generowanie strony na serwerze oraz za komunikację właśnie z tym "prawdziwym" backendem (czyli API). I, prawdę mówiąc, dzisiaj chyba to podejście jest najpopularniejsze, za sprawą de facto fullstackowych rozwiązań pokroju Next.js (który może być zarówno middleendem, jak i pełnoprawnym backendem).

Można też zrobić wszystko po stronie frontendu i to on będzie bezpośrednio odpytywał API. Wówczas po stronie frontendowej wystarczy superprosty serwerek do wysłania początkowego HTML-a i tyle – cała reszta się dzieje w przeglądarce. Tutaj oczywiście wchodzą problemy z bezpieczeństwem, czyli jak zabezbieczyć dobrze tokeny dostępowe, żeby nie wyciekły – więc do apek z wrażliwymi danymi jakaś forma middleendu de facto musi być.

Ogólnie temat rzeka, ale rozwiązań na rynku jest na tyle dużo, że jakiegokolwiek podejścia byś nie użył, ktoś inny na pewno też go używa – i może nawet jakiś duży gracz.

A może jakoś tworzyć szablony w JS i pobierać np ajaxem dane z API. Tylko w tym przypadku co z odświeżaniem adresu w przeglądarce, cofaniem do poprzedniej strony, itd.

Są API do tego:

History API – starsze, ale działające wszędzie,
Navigation API – nowiutke, ale działające tylko w Chrome

odpowiedź 30 maja 2023 przez rafal.budzis Szeryf (85,260 p.)

Wszystko zależy od tego co chcesz osiągnąć. Generowanie HTMLa w PHP i AJAX to spoko rozwiązania ale obecnie to straszne starocie. Ja teraz w pracy stosuje podejście że FE tak jak aplikacja na androida to zupełnie osobny kod który odpytuje o wszystko API (funkcja fetch żaden AJAX).

Ja do front-endu używam Next.js i React ;)

komentarz 30 maja 2023 przez Comandeer Guru (600,810 p.)

Powiedziałbym, że fetch to też Ajax. Ajax to zbiorcza nazwa metod asynchronicznego pobierania danych, nie konkretnej technologii.

komentarz 31 maja 2023 przez rafal.budzis Szeryf (85,260 p.)

@Comandeer Nie zgodziłbym się ze względu na to że fetch nie wspiera XML (chyba że sami pobieramy dane jako .text()). Skrót AJAX to jednak Asynchronous JavaScript and XML ;)

Może jest gdzieś luka w moim pojmowaniu jednak dla mnie AJAX = XMLHttpRequest

komentarz 31 maja 2023 przez Comandeer Guru (600,810 p.)

Gdyby się trzymać ściśle skrótu, to większość użyć XHR też nie jest Ajaksem, bo pobiera JSON.

Fetch jest mocno niskopoziomowy i w sumie oprócz JSON-a nie wspiera nic innego out of the box. Ale można dodać prostą obsługę przy pomocy DOMParser. I to IMO wciąż wyczerpuje definicję Ajaksu (to wciąż zbiór technologii do pobierania danych w tle).