Jak często w pracy spotykacie się z projektami w których jest odseparaowny frontend od backendu?

0

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.

8

W każdy dzień roboczy.

0

Jako, że nie umiem zbytnio w JavaScript mój ostatni FE był w WPF jakieś 6 lat temu

0

Wszystkie a jak któryś nie był to szybko rozdzielaliśmy

1

U mnie nasz projekt nawet nie wie nic o froncie

0

Wystawiasz jakieś publiczne API, ewentualnie swaggera , jako jego dokumentację, a drugi zespół bawi się w HTMLa :3

0

Codziennie, setki projektów.

0

Jak wygląda Twój projekt z nierozdzielonym frontem i back-endem? Jest taki jeden plik np:

<php>
//jakiś kod
echo "<html> <!-- jakiś markup-->

??

0

Codziennie :)

0
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.

0

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)

0

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ł.

7

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.

1 użytkowników online, w tym zalogowanych: 0, gości: 1