frontend , backend a po środku co?

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?

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

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.

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

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

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.

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

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 ;)

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

@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

No to dołączcie do rozmów jakiegoś seca plus bardziej doświadczonego deva :) nic nie stoi na przeszkodzie konsultować się. To o czym pisze to, żeby nie narzucać zespołom jak ma być zrobione, bo rzeczywistosc i tak to zweryfikuje - pojawia się corner casy, smaczki domenowe itp

@Charles_Ray: Z drugiej strony też nie jest dobrze kiedy programiści ogarniają sobie wszystko, bo wtedy programista jest devopsem: robi program, CI/CD, Jenkinsa, Kubernetesa itp. Jeśli architekt miałby być kimś spoza programistów, to powinien rozumieć o czym do niego mówią programiści i brać ich zdanie pod uwagę. Po prostu powinien rozumieć co się w systemie dzieje. Jeśli osoba projektująca system jest członkiem zespołu, to też powinna być to jedna osoba, np. wyznaczona na dyżur.

U mnie były tylko małe apki headless więc wszystko było na zasadzie dogadywania się. Teraz zaczynamy robić coś trochę większego i bardziej złożonego to proces wygląda tak, że najpierw interaktywne makiety, jak biznes zatwierdzi to powstanie front działający w 90%z fejkowym api i jak już wiemy co naprawdę jest nam potrzebne to wtedy opisujemy wszystko w standardzie openapi (plik yaml wypluwamy przez apke do opisywania API w repo) i dopiero na podstawie tego powstaje backend.Endpointy sukcesywnie podmieniane na prawdziwe. Mój biznes czasami jest za bardzo Agile więc nauczony doświadczeniem prototypuje ile się tylko da,a jak już frontend jest gotowy to wiadomo jakie api jest potrzebne.

Z drugiej strony też nie jest dobrze kiedy programiści ogarniają sobie wszystko, bo wtedy programista jest devopsem

1. Nie wiem, co ustalanie API ma do DevOps.
2. Nawet jeśli, to bardzo dobrze, to jest prawdziwy agile i podejście produktowe - team ma pełnię kompetencji, żeby budować produkt i ponosi za to odpowiedzialność. Extreme ownership.
3. Gwiazdka. Takie rzeczy jak Kubernetesy, Kafki i Jenkinsy powinny być ogarnięte przez zespoły od infry i wystawione zespołom produktowym na zasadzie platformy. Polecam lekturę Team Topologies w tym temacie. Ale to ortogonalne w stosunku do tematu.

Jeśli osoba projektująca system jest członkiem zespołu, to też powinna być to jedna osoba, np. wyznaczona na dyżur.

Na jaki dyżur? Dyżur projektowania systemu? :) System projektuje cały zespół, bo cały zespół go buduje, a następnie (hopefully) wdraża i utrzymuje na prodzie. Nie ma zwalania potem na architekta, że czegoś nie przewidział.

System projektuje cały zespół, bo cały zespół go buduje, a następnie (hopefully) wdraża i utrzymuje na prodzie. Nie ma zwalania potem na architekta, że czegoś nie przewidział.

Czyli odpowiedzialność się rozmywa. Jeśli nie będziesz miał kogoś na straży projektu, prosisz się o bajzel. Skład zespołu może się zmienić na przełomie kilku miesięcy. Jeśli to jeden wielki kolektyw, to i będzie dryfować w różne strony zależnie od składu.

Według moim zdaniem całkiem sensownego CDC (Consumer Driven Contract) powinien to robić ten kto ma wiedzę co jest potrzebne, czyli w opisanym przez ciebie przypadku front. Inaczej jest spora szansa, że backend zrobi coś, co będzie trudne w użyciu, nadmiarowe, albo padnie na pysk po obciążeniu typu N+1.

@PerlMonk: A frontu nie robisz do API restowego

No nie :) To znaczy można ale wtedy jest tak:

• Użytkownik chce mieć możliwość znalezienia wszystkich faktur, gdzie zamawiał żwirek dla kota
• Frontend idzie do backendu i prosi o dorobienie API
• Dostaje odpowiedź, że zrobili przecież CRUD'a i masz tam endpointy na listę faktur, pozycje faktury, weźcie se i przefiltrujcie
• Frontend robi funkcjonalność po swojej stronie korzystając z już istniejących API
• Użytkownik wchodzi na stronę i próbuje znaleźć wszystkie faktury ze żwirkiem dla kota
• Fronted pobiera listę faktur (100), do każdej z nich listę pozycji (10), filtruje i wyświetla.

Efekt taki, że zamiast jednego zapytania do backendu będzie ich 101 a mogą dojść jeszcze jakieś słowniki, bo ktoś na backendzie nie umiał w joiny, w przypadku urządzenia mobilnego i 3G, każde z tych zapytań, to narzut 100ms, czyli łączie na same opóźnienia w komunikacji wyjdzie 10s. Po stronie backendu też łatwo nie będzie, bo przecież jedno minimalnie bardziej złożone zapytanie obciąży bazę w znacznie mniejszym stopniu niż 100 prostych.

I nie - to nie jest przerysowany przykład.

piotrpo napisał(a):

@PerlMonk: A frontu nie robisz do API restowego

No nie :) To znaczy można ale wtedy jest tak:

• Użytkownik chce mieć możliwość znalezienia wszystkich faktur, gdzie zamawiał żwirek dla kota
• Frontend idzie do backendu i prosi o dorobienie API

no jak tak jest to bardzo dobrze, niestety znam przykłady że

• Frontend robi funkcjonalność po swojej stronie korzystając z już istniejących API
• Fronted pobiera listę faktur (100), do każdej z nich listę pozycji (10), filtruje i wyświetla.

bez pytania o inne możliwości

@Miang: Ale czego to dowodzi? Oczywiste jest, że jak masz niekompetentny zespół to zrobi źle, nawet jak ma możliwość zrobienia dobrze (bo nie wie jak, bo mu się nie chce, bo zupa była za słona). Piszę jak moim zdaniem powinna wyglądać relacja front-back i że moim skromnym zdaniem to części z którymi ma kontakt potencjalny użytkownik (frontend, klienty mobilne, API do integracji z czymś tam) powinny napędzać rozwój systemu, a nie to co sobie ktoś na backendzie wymyślił. Że często jest inaczej to wiem, widziałem nie raz i jedyne co było w stanie ratować taki projekt, to ktoś ogarnięty po stronie backendu, rozumiejący co jest celem projektu. Inaczej powstaje potworek, gdzie są piękne diagramy backendu, dostosowany do tego co sobie backend wymyślił frontend, który od strony użytkownika jest pokolorowaną kupą, a wszystko razem robi to co sobie wymyślił architekt backendu a nie to co powinno robić. Zwyczajnie programiści piszą tak, żeby było łatwo im, a nie użytkownikowi. Jak ktoś popatrzy na Librusa, albo aplikację do księgowości w mBanku to zrozumie o co mi chodzi.

@piotrpo: Spoko, zmiany mogą wychodzić od frontu. Ale też nie każda zmiana na froncie powinna pociągać za sobą zmianę w API backendu. Może być tak, że endpoint jest używany w kilku formularzach. Jeśli mam zmieniać endpoint, bo zmienił się jeden formularz z dziesięciu, to coś nie tak jest z architekturą systemu. Utrudniać zmianę może specyfikacja bazy danych albo szyna po drodze - powodów może być przynajmniej kilka.

@PerlMonk: Jasne, jedynie piszę, że jeżeli chcemy osiągnąć to, czego oczekuje użytkownik, to należy robić system pod to czego oczekuje użytkownik, a nie wrzucić jego wymagania do walizki z naklejką "zajefajna architektura backendu" i kazać całemu zespołowi na nią usiąść, żeby dała się dopiąć. Nie twierdzę też, że klient (np. front) ma być tyranem, dyskusja jest wskazana. Tylko koniec końców, ja chcę postawić telewizor tam gdzie mi się podoba, a nie tam gdzie elektryk zamontował gniazdko. Skoro jest to moje gniazdko, to ma być w takim miejscy, gdzie go oczekuję.

Jak robi się po prostu api, żeby udostępnić jakiś zasób innym aplikacjom zewnętrznym to logiczne, że nie trzeba się dostosowywać do każdej jednej apki, tylko wystawia się jakieś kluczowe endpointy i tyle, ale kiedy robi kompletną aplikację, to nie ma czegoś takiego, że ktoś sobie wymyśli backend i front ma z niego korzystać tak jak jest zrobiony, bo wtedy api się piszę dla frontendu i jeżeli frontend wymaga jakiegoś endpointu, to należy go dodać.
W ogóle pisanie api jakiegoś ogólnego, a pisanie api pod konkretną aplikację, to według mnie kompletnie 2 różne rzeczy.
Jak choćby zwracanie linków w responsach jest bez sensu, jak pisze się api pod aplikację, bo i tak frontend raczej przekazuje do backu to co dostaje w urlu, a nie wybiera sobie akcje z responsa.

Technical product owner

Między frontendem a backendem jest nieprzejawienie.

Backend powinien wiedziec co ma zrobić od product ownera/pm'a, jako front end czekam tylko na api i dokumentacje. Jak coś jest źle to zwracam to do bakendowca i czekam na poprawke

Generalnie temat jest dość nietrywialny. Z jednej strony racja FE gdzie chce się robić jak najmniej calli z przeglądarki bo inaczej strona zwalnia a z drugiej BE gdzie trzymanie osobnego setu endpointow dla każdej strony powoduje koszmar w utrzymaniu. Do tego jeżeli mamy jeszcze (makro/mikro/nano)serwisy to taki call to często nie wyciągnięcie czegoś z bazy ale i odpytanie innych usług.

W bardziej skomplikowanych przypadkach sens może mieć dodatkowy serwer BackendForFrontend gdzie dowolne endpointy może sobie zakodzic zespół FE a wola on już domenowe serwisy gdzie domena a nie widok dyktuje API.

Jak backend ma obsługiwać tylko jedna appke webową to w sumie może FE wymyślać co ma być ale najczęściej spotykałem sie z tym że BE służył wielu appkom FE, API albo innym integracjom/uslugom a wtedy FE nie zna wszystkich reguł rządzących domena