Jak zapewnić komunikację z serwerem?

Witam.

Na początku zaznaczę, że nie byłem pewny czy umieścić ten temat w dziale PHP czy w Webmasteringu, jednak poruszany przeze mnie wątek dotyczy też frontendu i webdevu jako całości, dlatego zdecydowałem się na ten dział.

Chciałbym się zapytać w jaki współczesny sposób zapewnić komunikację w obydwie strony pomiędzy backendem napisanym w języku php, a frontendem przy użyciu czystych technologii webowych, tj html, css, js, php, mysql, czyli BEZ frameworków (pomijam tutaj dyskusję, czy warto obecnie tworzyć aplikacje webowe bez frameworków, ale powiedzmy, że jestem początkujący i chcę póki co nauczyć się czystych technologii webowych)?

Wiem, że dawno temu strony w php pisało się w taki sposób, że po prostu "mieszało się" kod html z php w jednym pliku, poprzez dodawanie w kodzie html wstawek:

<?php ?>

jednak z tego co zdążyłem wyczytać, jest to obecnie bardzo zła praktyka i powinno się dążyć do całkowitej separacji frontendu od backendu. Przeczytałem na necie, że obecnie taką komunikację pomiędzy frontem i backiem powinno się zapewniać za pomocą API i przesyłania danych za pomocą formatu JSON. Zacząłem szukać na necie przykładowych aplikacji i znalazłem na Youtube prostą apkę webową typu CRUD, która jest napisana w czystych technologiach webowych. Do wymiany komunikacji pomiędzy frontem a backiem służy format JSON - od strony frontu za pomocą JS i metody fetch() dane są odbierane z backendu i z powrotem odsyłane. Poniżej wrzucam link do filmu prezentującego apkę:

oraz do repo na Githubie z kodem apki:

https://github.com/hilalahmad32/php-javascript-crud-with-fetch-api/tree/master

Chciałbym się zapytać, czy ktoś mógł na szybko przejrzeć kod na repo i napisać, czy taki sposób komunikacji pomiędzy frontendem a backendem jest ok?

Znam już dobrze JS i powoli zaczynam się uczyć php i później chciałbym zrobić jakieś mini projekty, aby poćwiczyć php i js, oraz które potem mógłbym wrzucić na swojego githuba jako portfolio, jednak do tej pory nie wiem za bardzo jak połączyć frontend z backendem. Powoli zaczynam "czuć" ideę API i wysyłania informacji za pomocą formatu JSON, ale nadal do końca nie wiem jak to powinno się zrobić, gdyż na YT znajduje różne tutoriale i różne osoby robią to w nieco inny sposób i dlatego prosiłbym kogoś o poradę, jak to powinno się robić.

Znalazłem jeszcze na YT dwa poniższe, krótkie filmiki, pokazujące jak odbierać dane z php po stronie frontu oraz jak wysyłać dane z frontu do php, też wszystko za pomocą JSONa i fetch API:

Odbieranie danych z php:

Wysyłanie danych do php:

I tutaj też prosiłbym o opinię, czy taki sposób jest ok? Może nie tyle, że jest to sposób idealny, ale bardziej mi chodzi tutaj o poprawny kierunek w którym powinienem iść, aby nauczyć się komunikacji pomiędzy frontendem z backendem.

jest to obecnie bardzo zła praktyka

Trochę dużo powiedziane :) server side rendering ma nadal sens, wszystko zależy od przypadku. Ale faktycznie, jeśli tworzysz aplikacje, a nie strony, to komunikacja po API jest zwykle lepszym wyborem.

I tutaj też prosiłbym o opinię, czy taki sposób jest ok?

Kierunek jest dobry, jedynie ten PHP z ohydnym formatowaniem, SQL injection jak na talerzu i brakiem jakiejkolwiek obsługi błędów to jest totalna porażka i wstyd. Więc może nie sugeruj się tym kodem za bardzo :) edit: chodzi mi o link do gh

BTW, nie bój się frameworków, bo one załatwią za ciebie mnóstwo roboty.

kelog napisał(a):

Kierunek jest dobry, jedynie ten PHP z ohydnym formatowaniem, SQL injection jak na talerzu i brakiem jakiejkolwiek obsługi błędów to jest totalna porażka i wstyd. Więc może nie sugeruj się tym kodem za bardzo :) edit: chodzi mi o link do gh

Spodziewałem się, że nie ma obsługi błędów itd, jednak tutaj bardziej chodzi mi o samą wymianę danych pomiędzy backendem a frontendem za pomocą JSONa i fetch API.

BTW, nie bój się frameworków, bo one załatwią za ciebie mnóstwo roboty.

Wiem, ale podobno przed nauką frameworków powinno się dobrze poznać czyste technologie webowe, czyli nie uczysz się Bootstrapa czy Reacta bez znajomości CSS i JS. Po prostu jak się nauczę PHP, to chciałbym sobie porobić jakieś aplikacje webowe w celu przećwiczenia tego języka, a nie nauczyć się tylko suchej teorii i podczas pisania tych aplikacji chciałbym w "poprawny" sposób połączyć frontend z backendem. A problem jest taki, że w większości kursów czy książek o PHP widzę, że PHP jest wymieszany z HTMLem lub są używane tzw. szablony jak np. Smarty, a ja chciałbym to zrobić za pomocą JSONa i fetch API.

Ogólnie masz dobre podejście do nauki.
Odnośnie przykładu to tutaj tak nie do końca jest to json bo tam się wiele rzeczy po drodze może wydarzyć. To echo to tylko dla happy path.

if(mysqli_num_rows($run_sql) > 0){
    while($row=mysqli_fetch_assoc($run_sql)){
        $output[]=$row;
    }
}else{
    $output["empty"]="empty";
}
echo json_encode($output);

Zapoznaj się z REST link . Json to tylko usystematyzowany format pliku, ale jego zaletą jest obsługa od strony JavaScript.
Poszukaj lepszego przykładu do nauki z użyciem REST.
Jak zapoznasz się z tym, możesz iść dalej w GraphQL i zobaczyć co to SOAP w którym używa się dla odmiany XMLa.
Jak napiszesz jakieś proste rzeczy to przejdź już na jakiś framework.

kario97 napisał(a):

przy użyciu czystych technologii webowych, tj html, css, js, php, mysql, czyli BEZ frameworków

PHP i MySQL to technologie webowe? :D

kario97 napisał(a):

Wiem, że dawno temu strony w php pisało się w taki sposób, że po prostu "mieszało się" kod html z php w jednym pliku, poprzez dodawanie w kodzie html wstawek:

<?php ?>

jednak z tego co zdążyłem wyczytać, jest to obecnie bardzo zła praktyka i powinno się dążyć do całkowitej separacji frontendu od backendu.

To kiedyś było popularne, ale to nigdy nie była dobra praktyka - ani wtedy, ani teraz ani nigdy. Masz całkowitą rację, że logikę i widok należy od siebie oddzielić .

kario97 napisał(a):

Przeczytałem na necie, że obecnie taką komunikację pomiędzy frontem i backiem powinno się zapewniać za pomocą API i przesyłania danych za pomocą formatu JSON. Zacząłem szukać na necie przykładowych aplikacji i znalazłem na Youtube prostą apkę webową typu CRUD, która jest napisana w czystych technologiach webowych.

Nie musisz od raz popadać z jednej skrajności w drugą. Nadal możesz renderować HTML w PHP, oraz mieć odpowiednie oddzielenie logiki od widoku. Chodzi po prostu o to żeby kodu PHP związanego z logiką, nie mieszać z kodem PHP odpowiedzialnego za widok. Nie musisz od razu zaprzęgać API do tego.

kario97 napisał(a):

Do wymiany komunikacji pomiędzy frontem a backiem służy format JSON - od strony frontu za pomocą JS i metody fetch() dane są odbierane z backendu i z powrotem odsyłane. Poniżej wrzucam link do filmu prezentującego apkę:

No takie rozwiązania się stosuje jak nie chcesz mieć Server-Side rendering, i chcesz zrobić apkę która wczytuje nowe dane bez przeładowania. Jeśli to jest Twój cel - to spoko, możesz tego użyć.

Ale jeśli Twoim celem są tylko "dobre praktyki", to moim zdaniem już za daleko pojechałeś.

kario97 napisał(a):

oraz do repo na Githubie z kodem apki:

https://github.com/hilalahmad32/php-javascript-crud-with-fetch-api/tree/master

Chciałbym się zapytać, czy ktoś mógł na szybko przejrzeć kod na repo i napisać, czy taki sposób komunikacji pomiędzy frontendem a backendem jest ok?

Jest okej, kod w PHP trochę średnio napisany, ale nie trudno byłoby go poprawić. Bo niby mówisz że chcesz oddzielić logikę od widoku, więc dodałeś API; ale Twój kod PHP nadal ma pomieszaną logikę z widokiem (tylko zamiast mieszać logikę i htmla, teraz mieszasz logikę i api). Plus, masz podatność na SQL injection.

Ale jak mówiłęm:

• Jeśli chcesz zrobić SPA, to spoko
• Jeśli chcesz tylko oddzielić logikę od widoku, to już overkill

Bo rozumiem że masz podejście: "chciałbym oddzielić logikę od widoku, więc muszę dodać API"? Bo jeśli tak, to jesteś w dobrym błędzie. Da się bardzo fajnie oddzielić logikę od widoku w PHP bez żadnych API, mogę Ci pokazać jak chcesz. Bo wraz z API dochodzi MASA kolejnych case'ów które trzeba obsłużyć, dużo więcej niż w SSR. Dużo dodatkowej pracy i potencjalnych luk w bezpieczeństwie.

Riddle napisał(a):

Bo rozumiem że masz podejście: "chciałbym oddzielić logikę od widoku, więc muszę dodać API"? Bo jeśli tak, to jesteś w dobrym błędzie. Da się bardzo fajnie oddzielić logikę od widoku w PHP bez żadnych API, mogę Ci pokazać jak chcesz. Bo wraz z API dochodzi MASA kolejnych case'ów które trzeba obsłużyć, dużo więcej niż w SSR. Dużo dodatkowej pracy i potencjalnych luk w bezpieczeństwie.

Masz rację, "chcę oddzielić logikę od widoku za pomocą API". Ale co masz namyśli mówiąc, że jestem w "dobrym błędzie"? W sensie z jednej strony jest to spoko idea, ale z drugiej tak jak napisałeś, razem z API pojawia się masa kolejnych rzeczy, których trzeba się nauczyć i zrozumieć, żeby to wszystko miało ręce i nogi, a "da się bardzo fajnie oddzielić logikę od widoku w PHP"?

Tak jak wspomniałem wcześniej, ja jestem dopiero początkujący, Właśnie kończę się uczyć asynchronicznego JS i korzystania z fetch api i za jakiś czas jak zacznę się uczyć PHP i MySQL, to chciałbym w celu przećwiczenia tego języka zrobić jakieś proste stronki internetowe (przy okazji ćwicząc CSS i JS), jakiś aplikację do dodawania notatek z systemem logowania i rejestracji, prosty sklep internetowy, podróbkę portalu społecznościowego itd.

I chciałbym po prostu w "poprawny" sposób oddzielić logikę PHP od widoków aplikacji żeby od razu zrobić jakieś projekty i nie tracić niepotrzebnie czasu, bo tak jak napisałem wcześniej, ile kursów z PHP, tyle sposobów: część miesza HTML z PHP, część korzysta z szablonów jak np Smarty (a inni podobno piszą jeszcze własne szablony), część pisze API i przesyła wszystko za pomocą JSONA.

Napisałeś, że jest fajny sposób na oddzielenie PHP logiki PHP od widoków bez użycia API, więc jakbyś mógł o tym tutaj napisać, a jeszcze lepiej podesłać link do jakiegoś kursu/tutoriala na YT, który pokazuje napisanie takiej apki od podstaw, to byłbym wdzięczny. :)

kario97 napisał(a):

Riddle napisał(a):

Bo rozumiem że masz podejście: "chciałbym oddzielić logikę od widoku, więc muszę dodać API"? Bo jeśli tak, to jesteś w dobrym błędzie. Da się bardzo fajnie oddzielić logikę od widoku w PHP bez żadnych API, mogę Ci pokazać jak chcesz. Bo wraz z API dochodzi MASA kolejnych case'ów które trzeba obsłużyć, dużo więcej niż w SSR. Dużo dodatkowej pracy i potencjalnych luk w bezpieczeństwie.

Masz rację, "chcę oddzielić logikę od widoku za pomocą API". Ale co masz namyśli mówiąc, że jestem w "dobrym błędzie"?

Mam na myśli to, że jeśli chcesz oddzielić po prostu logikę od widoku to są na to lepsze i prostsze sposoby niż API.