Duzy produkt oparty o mikroserwisy niekoniecznie oznacza kilkadziesiat aplikacji UI.
Tego nie sugerowałem. Chodizło mi o to, że jak jest dużo skomplikowanych UI, to fullstackowcy moga je co najwyżej zepsuć.
Ponadto UI mozna rozsadnie podzielic na odpowiedzialnosci, tak ze czesc mikroserwisow ma odpowiadajacy im "lekki" front- komponenty, ktore nastepnie sa skladane w calosc w dedykowanym serwisie (aplikacji UI).
Być może, chociaz nie łapię o co chodzi, pewnie dlatego, że nie umiem sobie wyobrazić gdzie by to miało mieć zastosowanie. Użytkownik oczekuje jednej aplikacji GUI - ma się ona sama poskładać z różnych kawałków dostarczonych przez różne teamy?
Tak jak patrzę po odpowiedziach, to jednak przeważa to, że bardzo ciężko być tylko i wyłącznie backendowcem.
Dla jednych ciężko, dla mnie to prawie jak raj. ;)
Backendowiec, który nie ma rozsądnego pojęcia o froncie bywa szkodliwy. Np. robi CRUDy, chociaż nikt go o to nie prosi (standard).
Programista robi to, co zleca BA. Jak BA zleca CRUDa, albo nie ma BA i programiści robią co chcą, to jest problem procesowy.
IMO warto jedną sensowną technologię front znać, jeśli chcesz robić sensowny backend.
Pomaga to też w ogarnieciu frontendowców, czy np. nie odwalają jakieś fuszerki.
Najpierw wymagania biznesowe, potem front. To po co w ogóle podział na różne zawody, skoro wszystko ma i tak robić jedna osoba?
Ten bajzel to bardzo pozytywna sprawa. Świadzy o tym, że jakiś postęp jest.
Dziwne, że w prawdziwych branżach inżynierskich dąży się do porządku, tylko w IT syf uznaje się za postęp.