Jak często w pracy spotykacie się z projektami w których jest odseparowany frontend od backendu? Do tej pory w pracy byłem na trzech projektach i na żadnym z nich front od backendu nie był odseparowany. Zastanawia mnie to ponieważ miałoby to znaczący wpływ jeśli miałbym zmieniać prace, a np. po stronie backendu byłaby java. Jedynie jestem zaznajomiony z .netem od strony backendowej. Jestem frontendowcem.
W każdy dzień roboczy.
Jako, że nie umiem zbytnio w JavaScript mój ostatni FE był w WPF jakieś 6 lat temu
Wszystkie a jak któryś nie był to szybko rozdzielaliśmy
U mnie nasz projekt nawet nie wie nic o froncie
Wystawiasz jakieś publiczne API, ewentualnie swaggera , jako jego dokumentację, a drugi zespół bawi się w HTMLa :3
Codziennie, setki projektów.
Jak wygląda Twój projekt z nierozdzielonym frontem i back-endem? Jest taki jeden plik np:
<php>
//jakiś kod
echo "<html> <!-- jakiś markup-->
??
Codziennie :)
Crazy_Rockman napisał(a):
Jak wygląda Twój projekt z nierozdzielonym frontem i back-endem? Jest taki jeden plik np:
<php> //jakiś kod echo "<html> <!-- jakiś markup-->
??
To nie musi być jeden plik. To mogą być tysiące plików. Kilka/kilkanaście lat temu pisało się głównie w taki sposób.
tak się zastanawiam - czy większość z Was pisze same strony? Czy nikt nie robi już w desktopie? (i nie mam tu na myśli kolejnego CRUDa)
Wszystko zależy od miejsca pracy i projektu. Ja w następnym tygodniu zaczynam nową pracę gdzie będę zajmował się tylko backendem, natomiast w obecnym miejscu jest duży nacisk na to aby każdy dev zajmował się fullstackiem, oczywiście w ramach rozsądku. Jedni robią więcej w backendzie, inny we froncie. Ogólnie to patrząc na moje niedawne rozmowy z różnymi firmami wynika że częściej preferuje się jednak podział.
Praktycznie od dawna tylko rozdzielone - osobne procesy - wydzielone API. itd.
Ale można zajść daleko. W jednej firmie wyspecjalizowanej w Java EE (taka technologia, znana z tego, że jej programisci lubią wszystko upraszczać) miałem takie warstwy:
Backend Backendu Backendu (baza danych - gruba)
Backend Frontendu Backendu (java ee - procesy/ batche /logika - synchronizacja danych ze 100 ma innymi systemami tak napisanymi)
Frontend Backendu Backendu (java - API biznesowe - core enterprise - dla frontendu)
Frontend Frontendu Backendu (api gateway / firewall - też trzeba było programować)
Backend Backendu Frontendu (baza danych - to nie żart - druga, kopie danych z backendu backendu backendu potrzebne na czas sesji użytkowników, ale tu chyba nie było procedur składowanych, albo było mało, więc taki lajtowy komponent)
Backend Frontendu Frontendu (java batche - kolejny raz - synchronizacja danych użytkowników do backendu backendu )
Frontend Backendu Frontendu ( java API dla frontu frontu frontu )
i tu jeszcze firewall - ale mniej upierdliwy, nie było co konfigurować, i tak wszystko ubijał - :-)
Frontend frontendu Frontendu ( javascript Single page application)
Były projekty, gdzie część ( _ _ Frontend ) była rozdzielona jeszcze na dwie - i to po grubości :-) - każda z własną bazą danych (tylko innego typu). Nie zamieszczam tej rozpiski, bo w tym to i ja się gubiłem. Poza tym nie było symetrii, bo nie było backendu backendu backendu backendu - dopiero pracowaliśmy nad tym.
Tak czy siak - dodanie jednego pola na formularzu to było pracowite przerypywanie się przez wszystkie projekty i dodawanie tego pola w klasach, tabelach, mapperach - tak 2 tygodnie pracy. Chyba zapomniałem jeszcze dodać, że wszystkie te komponenty były robione wielowarstwowo. Było godnie.
Przy okazji - było to trochę straszne, ale nie uważam, że było całkiem źle, był pewien powód biznesowy tego warstwowienia - paranoiczne security. W zasadzie w 2019 chyba wiem jak to można było zrobić lepiej. Ale w czasach kiedy ten system powstawał nie wiedziałem jak, i firmowi architekci raczej też nie.