Fronton napisany w językach używanych jako back-end! [Zamknięte]

Z mojego doświadczenia w programowaniu stron internetowych wiem, że języki takie jak PHP, Java, Python..etc są używane do programowania wewnętrznego (oprogramowanie działające na serwerze), a dla języków front-end JS / HTML / CSS.

Ale widzę, że wiele firm twierdzi, że używa na przykład PHP do programowania front-end i Python do back-endu.

Czy to oznacza, że ​​PHP jest front-endem do wywoływania innych usług napisanych w innych językach przez REST, RPC ..etc?

Pomylono pojęcia „front-end” i „back-end” z „po stronie serwera” i „po stronie klienta”. „Back-end” zwykle odnosi się do systemów, które nie są bezpośrednio narażone na działanie użytkownika (serwery baz danych, oprogramowanie pośrednie itp.), Podczas gdy „front-end” zwykle odnosi się do aplikacji (w przypadku sieci zwykle oznacza to statyczny oraz dynamiczne strony internetowe), do których klient ma bezpośredni dostęp.

W aplikacji internetowej klient (przeglądarka użytkownika) uzyskuje dostęp do stron internetowych, które są przechowywane lub dynamicznie generowane „po stronie serwera” za pomocą technologii „front-end”. Te komponenty frontonu mogą z kolei pobierać dane lub inne informacje z komponentów back-endu. Aplikacja napisana w PHP byłaby więc „front-endem”, ale „po stronie serwera”. Jednakże, jeżeli strony internetowe zawierały żadnych javascript, aby być wykonywane przez przeglądarkę użytkownika, że kod JavaScript zostanie zrealizowany „client-side”.

Mam nadzieję, że usunąłem pewne zamieszanie, ale teraz ryzykuję, że stworzę więcej.

Po pierwsze, mamy AJAX , czyli kod (zwykle JavaScript) wykonywany w kliencie (czyli po stronie klienta), aby tworzyć wyświetlane strony internetowe, pobierając informacje z usług internetowych, które same nie generują stron internetowych. Usługi generują informacje po stronie serwera na interfejsie (ponieważ są one publiczne i możesz skierować przeglądarkę prosto na nie, jeśli znasz adres URL).

Po drugie, JavaScript nie ogranicza się oczywiście do użycia po stronie klienta. Stał się coraz bardziej popularny jako język „po stronie serwera” (patrz przykład node.js ). Jako taki, jego najczęstszym zastosowaniem jest właśnie ten rodzaj usług internetowych, które opisałem w poprzednim akapicie.

Kiedyś Web 2.0 było znacznie prostsze . Wtedy, w kontekście aplikacji internetowych , fronton był miejscem, w którym generowane były strony internetowe, podczas gdy JavaScript działał tylko po stronie klienta i tworzył drobny kosmetyk do stron internetowych, takich jak podświetlane obrazy po najechaniu na nich myszą. Jednak ta prostota spowodowała, że ​​ludzie lenili się swoimi definicjami. Teraz sytuacja jest bardziej złożona, dlatego ważne jest precyzyjne określenie tych warunków.

(Aha, i jeśli mają korzystać z PHP, należy trzymać go na przednim końcu. Jest to zdecydowanie nie to technologia dobry back-end. I jeśli kiedykolwiek znaleźć nikogo tworzenia przeglądarki, która wykonuje PHP po stronie klienta, strzelać do nich.)

Myślę, że twoje pytanie może być dość specyficzne dla PHP, ponieważ nie widzę żadnej innej technologii zaplecza, o której wspominasz, jest wykorzystywana w ten sposób.

PHP jest zabawnym przykładem, ponieważ może być (w dość brzydki sposób mogę dodać) postrzegany jako język „wszystko w jednym” w odniesieniu do wielu projektów internetowych. Możesz wykonywać swoje tradycyjne zadania „ zaplecza ” - takie jak operacje na plikach i bazach danych, a także budować znaczniki „ front-end ”.

Może to oczywiście prowadzić do bałaganu spaghetti, w którym nie ma prawdziwego oddzielenia zmartwień, więc naprawdę powinienem się na to zgodzić. Na przykład, jeśli przeglądasz źródło wordpress, często możesz się zgubić - i to jest jeden projekt, w którym obwiniam język, organizacja bazy kodu jest w rzeczywistości bardzo dobra.

Można temu zaradzić, używając „ silnika szablonów ” (takiego jak Smarty )) - ale to wciąż PHP buduje „front-end”, a jednocześnie zapewnia funkcję „back-end”. To była celowa decyzja dotycząca projektu PHP, jednak jest to przecież „ procesor hipertekstowy ”!

Tak więc PHP może łatwo dopasować się zarówno do zastosowań „ front-end ”, jak i „ back-end ”, co powinno wyjaśnić twój przykład. Dlatego najprawdopodobniej masz rację, ponieważ PHP będzie przetwarzać i budować wszystkie narzuty na front-end, ale będzie wysyłać żądania w innym miejscu w celu zebrania wymaganych danych - najprawdopodobniej usługa napisana w jednym z wyżej wymienionych języków .

Osobiście uważam, że cała terminologia „back-end” i „front-end” jest nieco… może przestarzała. Wolałbym, żeby rzeczy były po prostu odnoszone do klienta i serwera; wtedy nie ma prawdziwej dwuznaczności. *

Ostatnio widziałem specyfikację klienta, która wymagała systemu zaplecza napisanego w node.js i powiązanych narzędziach, ale chciała kompilacji frontonu przy użyciu frameworka PHP (Laravel). Jest to związane z wieloma kosztami i moim zdaniem - nie jest eleganckim rozwiązaniem i może powodować sporo problemów.

Osobiście mówiąc, tego rodzaju konfiguracje wyglądają, jakby ktoś niepotrzebnie przeniósł PHP na inny stos - co oznacza, że ​​potrzeba więcej zasobów, niż jest to faktycznie konieczne, personel konserwacyjny potrzebuje kontaktu z szerszą gamą technologii i jest więcej punktów awarii.

Ponadto uważam, że istnieje bardzo niewiele scenariuszy, które uzasadniają ten rodzaj stosu pośredniego; większość języków / frameworków zaplecza jest w pełni zdolna do generowania narzutów wymaganych dla interfejsu. Chociaż mogę tam zostać poprawiony.

* Jednak, aby odrzucić twoje pytanie. Co z systemami back-endowymi zbudowanymi przy użyciu Javascript? (node.js;))

Edytować:

Po przeczytaniu komentarza @itsbruce postanowiłem wyjaśnić, co rozumiem przez niejednoznaczność mojej terminologii „front-end” / „back-end”.

Tradycyjnie ta terminologia byłaby w porządku, architektonicznie aplikacje internetowe byłyby o wiele prostsze - i śmiem to powiedzieć, dużo głupsze. Moim zdaniem dużo czystsze jest mówienie „po stronie serwera” i „po stronie klienta”, a staje się to wyraźniejsze, gdy obecny trend przekazywania większej liczby procesów przetwarzania i logiki klientowi staje się powszechny.

Dopuszczalne jest wykonywanie sporej ilości przetwarzania danych po stronie klienta (wystarczy spojrzeć na niektóre z popularnych obecnie modów javascript), ale czy to naprawdę front-end? Użytkownik nie widzi tego, widzi jego wyniki - i według tradycyjnych kryteriów, które na ogół byłyby postrzegane jako „zaplecze”; ale teraz dzieje się to w przeglądarce ...

Podobnie i niezwykle istotne dla tego pytania, czy budowanie marży w PHP jest naprawdę zadaniem front-end? Wątpię, szybkie przeglądanie ofert pracy pokazuje, że niewiele stanowisk front-endowych programistów oczekuje doświadczenia w PHP lub wiedzy; jednak intuicja sugerowałaby, że narzut dla interfejsu jest z natury frontendem.

Sam fakt, że pytanie to istnieje, stanowi przykład tego, jak „ front-end ” i „ back-end ” są z natury niejednoznaczne i tak pozostanie.

Mówiąc o zadaniach „po stronie serwera” lub „po stronie klienta”, że niejednoznaczność zostanie utracona, wiesz, gdzie wykonuje się kod i jakie języki będą używane. Jeśli powiedziałeś „ front-end ” w przykładzie podanym przez OP, wątpię, by wiele osób powiedziałoby „ Och, więc PHP na serwerze, prawda? ”.