frontend , backend a po środku co?

5

Mam pytanie kto u Was w firmie decyduje w jaki sposób backend z frontendem rozmawia,co jest zwracane, i kto definiuje API? backendowiec, frontendowiec czy może jakiś manager lub architekt?

2

W moim modelu pracy - sam sobie sterem, okrętem żeglarzem. Myślę, że API się samo definiuje jak pytasz o konkretne endpointy, a nie o rodzaj tego API

2

Kwestia dogadywania kontraktów dotyczy nie tylko komunikacji frontu z backendem, ale np. też z innymi serwisami, zewnętrznymi firmami.
Pewnie powinno się to uzgadniać wspólnie, ale doświadczenie pokazuje, że kto pierwszy ten lepszy, czasem to ten bardziej uparty.

7

Teoretycznie architekt w zespole. W praktyce backendowiec w porozumieniu z frontendowcem

6

Jak pracowałem nad dużym produktem to endpointy przychodziły opisane w story. Robili to End2End architekci. Jak pracuję nad małym produktem to rozmawiam z frontendowcem. Często jest na zasadzie jak będzie prościej. Do kłótni żadnych jeszcze nie doszło

5

Najlepiej byłoby tak jak napisał @szydlak - architekt. Ale nie zawsze tak jest. Ja byłem w zespole, w którym to backendowiec ustala API biorąc pod uwagę, że front też ma swoje zabawki. Przykład: przeglądanie dużej ilości danych. Pytałem frontu jak chcą to zrobić: szukajką, listą rozwijaną czy jeszcze czymś. Ustalaliśmy jak zrobić, żeby nie obciążać bazy danych. Czasem też ludź od frontu może chcieć zachować dane po stronie klienta. Wtedy ja wiem jakie dać mu API. Z czasem idzie się przyzwyczaić o ile zespół jest zgrany.

1

Najwygodniej jest zrobić bakckend oddzielnie z wystawionym API i front oddzielnie, wtedy oba zespoly sobie pracuja indywidualnie kazdy ma swojego PM. Jesli jest was malo to mozecie polaczyc wszystko w jednym. Mi sie podoba ta koncepcja rozdzielenia cos jak procesor ma swoje komendy a reszta urzadzen po magistrali odpytuje inne. Mozesz wpiac nowa karte i tak samo tu dodawac nowe moduly, wiec jest wygodnie bo ty jako backend mozesz zajc sie kolejnym projektem a front moze dodawac ficzery czasem nawet bez potrzeba angazowania backendowca

1
piotrevic napisał(a):

Kwestia dogadywania kontraktów dotyczy nie tylko komunikacji frontu z backendem, ale np. też z innymi serwisami, zewnętrznymi firmami.
Pewnie powinno się to uzgadniać wspólnie, ale doświadczenie pokazuje, że kto pierwszy ten lepszy, czasem to ten bardziej uparty.

zapomniałam o przypadku miedzy firmami dobrze że mi przypomniałeś. Teoretycznie to powinno wtedy być ustalane wszystko na piśmie. ale ja np. się wykłócałam że chcę mieć formalne API a nie parę linijek ogólnego opisu, współpracownicy nie widzieli potrzeby żeby firma zewnętrzna coś dla nas robiąca musiała dokładnie definiować co ;)
Sama w innej firmie robiłam backend i kierowałam projektem, więc naturalnie mówiłam juniorom co dostaną na froncie i jak zwracać wprowadzane dane, czyli dawałam opis metody i parametrów, nawet jak jeszcze do końca nie działała. Niestety wlazła w to firmowa polityka, manager próbujący namieszać w projekcie właśnie wtrącaniem się w przepływ danych
A obecnie przepływ danych jest nie do końca miedzy frontendem a backendem i kto szybszy ten lepszy ;)

1

Z mojego doświadczenia wynika, że jak ktoś inny dogaduje integrację (np. manager albo architekt), a ktoś inny to potem implementuje, to wychodzi kuktas. To jest średniowieczne podejście, tymczasem najwiecej wiedzy jak to powinno działać jest „na dole” - u zespołów. Po to zatrudniamy programistów, żeby sobie ogarnęli API.

Odnośnie współpracy między firmami - najlepiej sprawdzają się mniej formalne zdzwonki devów, poza oficjalnym anturażem. Okazuje się, że można dogadać integracje w 30 minut bez popisywania się, kto jest lepszy i ma większego jsona.

Odnośnie frontu i backendu - trzeba się dogadać. Warto, żeby uwzględnić jak to API będzie używane, żeby wiedzieć, co i jak wystawić - więc tutaj podejście consumer-driven wydaje się Ok (szczególnie jak do stołu przychodzą mobilki). Narzędziowo, API można sobie dogadać np. na pull requeście albo w docsach (nie polecam).

1

@Charles_Ray: z drugiej strony uważam że lepiej żeby ktoś z pojęciem o całości sprawdził czy za dużo danych nie lata w tę i z powrotem, umożliwiając użyszkodnikowi na froncie np. podejrzenie innego

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