Fullstack - nieunikniona przyszłość?

1

MI też wydaje się, że jak backandowiec ogarnia trochę frontend to nie jest to złe. Ja sam rozwijam się w backendzie, ale dla funu jakieś tam proste apki w React/Angular popełnijem i uważa, że to było cenne doświadczenie bo łatwiej mi się z frontami dogadać. Czasami wpadają też proste taski, gdzie 90% to backend ale na froncie trzeba dodać jakiś guziczek czy inną kontrolkę i głupio wtedy zaraz fronta w to angażować. Dochodzą kwestie typu deploye, gdzie trzeba umieć zbudować front "w locie" itp.

Ogólnie uważam, że jest to jakiś logiczny etap w rozwoju kariery, że oprócz skilowania się w swojej działce dodajemy też trochę skilli z innego poletka. Taki typowy fullstack, co sam ciągnie cały projekt to faktycznie możliwe chyba tylko w jakichś małych apkach, ale podstawy warto znać.

1
Terrored napisał(a):

Jestem .net devem pracującym na backendzie od ponad 3 lat. W zespole mamy dedykowane osoby od backendu i frontu.

Regularnie śledzę rynek i zdecydowana większość ogłoszeń dla .net developerów jest aktualnie dla fullstacków. Szczerze jak widzę w ilu zagadnieniach jeszcze jestem zielony jeśli chodzi o backend to nie wyobrażam sobie potrafić drugie tyle i więcej jeśli chodzi o front.

Chciałbym rozwijać się w kierunku back-endowym i nie zbaczać na kierunki frontowe :) Czy w dzisiejszych czasach jest to nadal możliwe?

Oczywiście, że jest to możliwe i to nie jest żaden problem. Wygląda na to, że nawet nie zdajesz sobie sprawy z tego jak dużo można umieć i wiedzieć.
Programista, który potrafi "ogarnąć" cały proces tworzenia aplikacji w dzisiejszych czasach nazywana "FullStackiem" kiedyś to była jednak norma.
Oczywiście podział na front / backend istniał niemal zawsze ale to był raczej wstyd przyznać się, że nie ogarnia się "drugiej strony medalu".

W dzisiejszych czasach "korpo", w których tymczasowo nikt nie liczy się z kosztami wynikającymi z zasobów ludzkich ale i jednocześnie brakiem wyspecjalizowanych ludzi na rynku podział na mniejsze specjalizacje jest głęboko uzasadniony. Warto jednak wiedzieć, że cały świat to nie tylko aplikacje dla "korpo", a poza nim jest ogromy i coraz większy rynek małych aplikacji, które z założenia nie muszą być utrzymywane 100 lat, być top security z administracją 24h/dobę i mieć wydajność pozwalającą na obsługę100000 userów w jednym momencie.
W takim przypadku zdecydowane zalecane i najbardziej ekonomiczne będzie skorzystać właśnie z usług FullStacka, który poradzi jaką bazę i środowisko dobrać do potrzeb, a i rozumiejąc zagadnienie interfejs użytkownika skleci.
Zresztą nie raz było tu już pisane, że nie rozumiejąc back-endu nie zrobisz dobrego front-endu i odwrotnie.

Poza wszystkim rodzi się pytanie czy współcześnie programiści tkwiący w podziale front/back nigdy nie napisali samodzielnie żadnej aplikacji od początku do końca?

scibi_92 napisał(a):

A i mam pytanie do fullstackow - jak będzie trzeba zrobić fronted w Androidzie albo IoS to też od razu będziecie się za to zabierać? Czym to się różni od robienia frontendu w JS?

Choć w każdej chwili jestem gotów zacząć pisać aplikację pod iOS czy Android i to "od początku do końca" to docelowa platforma jest jednak czymś innym niż umiejętność napisania jakiejkolwiek aplikacji "od początku do końca". Nie ma kompletnej aplikacji bez frontu.

Mogę w każdej chwili napisać aplikację desktopową na iOS czy natywną na Android ale mogę też dla każdego z tych środowisk dostarczyć aplikację WEB z back-endem na serwerze i sensownym frontem, który się z nim komunikuje. Tak czy siak dostarczę odbiorcy aplikację na jego komputer niezależnie od tego czy używa Linuxa, Widowsa, Andoida czy inne applowe wynalazki.
Oczywiście poziom wiedzy w różnych obszarach jest różny ale uważam, że trzeba przynajmniej mieć pojęcie jak się za programowanie w poszczególnych systemach zabrać tak żeby to miało ręce i nogi.

3
katakrowa napisał(a):

Nie ma kompletnej aplikacji bez frontu.

Mógłbym napisać że kłamiesz, ale napiszę że rozmijasz się z prawdą. Przez ostatnie pięć lat dwa razy pracowałem w aplikacji bez frontendu. Za pierwszym razem klient chciał od nas tylko backend bo stwierdził że front mamy brzydki i napisze sobie sam lepszy. W rezultacie frontendowcy nie mieli co robić i zaczęli pisać microserwisy w Node. Jakoś nie potrafili się nauczyć Javy/Scali czy Erlanga/Elixira (języków w których była napisana reszta backendu)

Za drugim razem była to aplikacja bez frontu by design. Skaner paszportów łączył się z nami po SOAP i żadnego frontu dla użytkowników nie mieliśmy.

0
KamilAdam napisał(a):
katakrowa napisał(a):

Nie ma kompletnej aplikacji bez frontu.

Mógłbym napisać że kłamiesz, ale napiszę że rozmijasz się z prawdą. Przez ostatnie pięć lat dwa razy pracowałem w aplikacji bez frontendu. Za pierwszym razem klient chciał od nas tylko backend bo stwierdził że front mamy brzydki i napisze sobie sam lepszy. W rezultacie frontendowcy nie mieli co robić i zaczęli pisać microserwisy w Node. Jakoś nie potrafili się nauczyć Javy/Scali czy Erlanga/Elixira (języków w których była napisana reszta backendu)

Jeśli celem jest stworzenie API to ok. Oczywiście są API, które w założeniach nie mają mieć "okienek" bo są tylko po to by serwować jakieś dane ale to jedynie podgrupa z wszystkich aplikacji. ...Chociaż w sumie ta działa dla API co gadają z innymi API wcale nie jest taka mała... Zatem masz rację.

Mając jednak w zamyśle, sytuację gdy piszemy API stricte dla front-endu wcześniejsze opinie podtrzymuję :-)

1

Full stack jest idealny w małych i prostych projektach, bo tam nie traci się za dużo na braku specjalizacji, a sporo oszczędza na zlikwidowaniu konieczności dogadywania każdej pierdoły. Podobnie tam gdzie jedna z tych części jest mała i prosta i zatrudnienie frontend only developera nie ma sensu, bo brakuje dla niego roboty na cały etat, czyli w koniec końców lepiej zrobić to samodzielnie niż czekać aż komuś gdzieś się zwolni miejsce w grafiku. W dużych i złożonych projektach z mojego punktu widzenia optymalne jest utrzymywanie t-shape, czyli są ludzie specjalizujący się w czymś, ale każdy z nich ma przynajmniej podstawowe kompetencje w innych dziedzinach. Daje to sporo korzyści - minimalizacja bus factor, zrozumienie problemów po obu stronach, możliwość wrzucenia ludzi w część projektu, która jest akurat pilna.

2
hadwao napisał(a):

MI też wydaje się, że jak backandowiec ogarnia trochę frontend to nie jest to złe.

Oczywiście, że nie jest złe. Generalnie każda wiedza i umiejętności są dobre. Tylko nie dorabiajmy teorii, że koniecznie każdy musi.

Ogólnie uważam, że jest to jakiś logiczny etap w rozwoju kariery, że oprócz skilowania się w swojej działce dodajemy też trochę skilli z innego poletka.

Mhm, tylko w dzisiejszych czasach tych poletek jest o wiele więcej niż dwa.

katakrowa napisał(a):

Programista, który potrafi "ogarnąć" cały proces tworzenia aplikacji w dzisiejszych czasach nazywana "FullStackiem" kiedyś to była jednak norma.
Oczywiście podział na front / backend istniał niemal zawsze ale to był raczej wstyd przyznać się, że nie ogarnia się "drugiej strony medalu".

No właśnie, kiedyś.
Kiedyś nie było tylu języków, technologii, platform docelowych, oraz sposobów tworzenia i dostarczania aplikacji.

Zresztą nie raz było tu już pisane, że nie rozumiejąc back-endu nie zrobisz dobrego front-endu i odwrotnie.

To stwierdzenie jest tak bardzo oderwane od rzeczywistości, że nawet nie wiadomo jak je skomentować. Mógł na to wpaść chyba tylko ktoś, kto w życiu widział jedynie crudy, a swoje błędy próbuje przerzucić na innych. Backend wysyła i przyjmuje dane, co z tym zrobi frontend to jest sprawa frontendu. A jeśli coś jest nie tak w kwestii UX, to pretensje trzeba mieć do analityków, ownerów i managerów.
To brzmi równie sensownie jak jeśli nie umiesz wydobywać gazu ziemnego i wytapiać patelni, to nie zrobisz dobrej jajecznicy i odwrotnie.

Poza wszystkim rodzi się pytanie czy współcześnie programiści tkwiący w podziale front/back nigdy nie napisali samodzielnie żadnej aplikacji od początku do końca?

To nie jest kwestia tego, co kto zrobił, albo co umie robić, tylko tego, co chce robić zawodowo przez kilkadziesiąt godzin w tygodniu.

4
somekind napisał(a):

Zresztą nie raz było tu już pisane, że nie rozumiejąc back-endu nie zrobisz dobrego front-endu i odwrotnie.

To stwierdzenie jest tak bardzo oderwane od rzeczywistości, że nawet nie wiadomo jak je skomentować. Mógł na to wpaść chyba tylko ktoś, kto w życiu widział jedynie crudy, a swoje błędy próbuje przerzucić na innych. Backend wysyła i przyjmuje dane, co z tym zrobi frontend to jest sprawa frontendu. A jeśli coś jest nie tak w kwestii UX, to pretensje trzeba mieć do analityków, ownerów i managerów.

To stwierdzenie jest tak bardzo oderwane od rzeczywistości, że nawet nie wiadomo jak je skomentować. Mógł na to wpaść chyba tylko ktoś, kto w życiu widział jedynie crudy.
Już kilka razy widziałem jak zespół backendowców rozmawiał z klientem i analitykami i na tej podstawie modelował dziedzinę a potem API. Z tego wychodziło tak cudowne rozwiązanie, że pierwsza stronka aplikacji mobilnej potrzebowała robić 114 zapytań, żeby pokazać kilkanaście tekstów i liczb.

Backendowiec może oczywiście nie znać front-endu i być dobrym backendowcem jeśli:
a) aplikacja nie ma frontendu zasadniczo (albo frontendy to są poboczne sprawy),
b) jeśli aplikacja ma frontent - to ogarnie, że w kwestii modelowania API to jego klientemi i panem jest właśnie frontend. Niestety jak ktoś robi całe życie CRUdy to problemu nie widzi i wpieprza się tam, gdzie nie powinien, często w czasie rozmów z klientem i analitykami proponując absurdalne rozwiązania (które potem rzutują na beznadziejny UX).

4

Przepraszam jeśli uraziłem swoją wypowiedzią, a po odpowiedzi widzę, że uraziłem bardzo, ale jeżeli ktoś widzi jednoznaczne i oczywiste powiązanie między backendem a frontendem, to znaczy, że zna chyba tylko crudy. Bo chyba tylko w crudach takie powiązanie 1:1 występuje, więc trzeba "rozumieć oba", żeby zrobić dobrze.

A rzeczywistość jednak potrafi być bardziej skomplikowana, w wielu systemach takiego powiązania nie ma. Często frontendów jest kilka-kilkanaście (per platforma lub per typ użytkownika), a backendów kilkadziesiąt jak nie kilkaset. I jeden frontend może korzystać z jednego lub wielu backendów, a te backendy korzystają z innych backendów. I są też backendy, do których użytkownik w ogóle nie ma żadnego dostępu, bo tylko przesyłają dane z jednego źródła do innego. A nawet istnieją backendy, które służą do zarządzania i monitorowania pracy innych backendów.

To tyle. Warto znać rzeczywistość - nawet jeśli samemu się w niej nie uczestniczy, żeby nie być od niej oderwanym.

jarekr000000 napisał(a):

Już kilka razy widziałem jak zespół backendowców rozmawiał z klientem i analitykami i na tej podstawie modelował dziedzinę a potem API. Z tego wychodziło tak cudowne rozwiązanie, że pierwsza stronka aplikacji mobilnej potrzebowała robić 114 zapytań, żeby pokazać kilkanaście tekstów i liczb.

Czyli kilka razy pracowałeś przy crudach w źle zorganizowanych firmach o słabej kulturze pracy.
To nie "zespół backendowców" jest od modelowania dziedziny, jeśli ktoś tak działa, to jest to właśnie działanie w oderwaniu od rzeczywistości.

0

nie wiem czy nieuniknione ale mi praca nad tylko jedną częścią wydaje się ułomna - to trochę jak granie w dwie osoby w grę na jednym komputerze gdzie jedna osoba operuje myszką a druga klawiaturą...
Byłem w sytuacji że zajmowałem się tylko frontem a backendem kto inny i musiałem często czekać aż api będzie gotowe żeby móc kontynuować, potem się okazywało że api jest tragicznie zaprojektowane albo czegoś brakuje i zaczynało się przerzucanie taska od osoby do osoby. Zdarzyło mi się też pracować tylko nad backendem podczas gdy task frontendowy dostał ktoś inny i wcale nie było bardziej różowo. W zasadzie to samo tylko od drugiej strony - wizja api które chciałby dostać frontendowiec od wizji backendowca jest często skrajnie różna. Ogólnie dużo czasu zbędnie straconego na dodatkowe meetingi i synchronizację.

No chyba że się jest głęboko w backendzie - tj. nie robimy po prostu api pod front tylko grzebiemy gdzieś głębiej w aplikacji nad jakimś przetwarzaniem danych, nie obchodzi nas wcale front i jesteśmy samowystarczalni. Wtedy praca jest ok, ale takiej jest znacznie mniej.
Tylko że to chyba się już wtedy nie nazywa backend developer, raczej data scientist / big data developer czy po prostu software engineer. Osobiście pracowałem we wszystkie trzy wymienione sposoby i muszę przyznać że ten trzeci był najprzyjemniejszy (najspokojniejszy), choć praca z frontem daje naoczne efekty pracy przy najmniejszym nakładzie i też potrafi być satysfakcjonująca.

3

Założmy że mamy osoby A i B.
Osoba A pracuje w jakiejś tam firmie X, jest jeden monolit który ewentualnie integruje się przez jakieś staromodne SOAPy albo RESTy z innymi systemami, jest fullstackiem. Ogarnia Jave, Springa, jakąs bazę SQL, Mavena (takie narzędzie do budowania, niezbyt trudne), Angulara i jakieś tam narzędzie do budowania frontu, potrafi też coś tam wyklikać w Jenkinsie.
Osoba B pracuje jako pure backend developer, w architekturze rozproszonej, ma Jave, Springa, Maven/Gradle plus jeszcze integracje zarówno REST/SOAP jak i przez systemy kolejkowe/rozproszone logi jak RabbitM lub, Kafke, ogarniać Dockera, Kubernetesa, SQL i NoSQL jak np. ElasticSearch.
Z jakiś powodów mam wrażenie że osoba A byłaby przez niektórych uznawana za jakąś lepszą, mimo że mogłaby potrzebować nawet mniej do nauki niż osoba B. Tak jak @somekind napisał i czego sam doświadczyłem jest to że istnieja aplikacje ktore nie sa nawet bezpośrednio powiązane z jakimkolwiek frontem, mogą to być nawet systemy które nasłuchują jedne topici na Kafce a na drugie coś wysyłają.

Kiedyś nie było tylu języków, technologii, platform docelowych, oraz sposobów tworzenia i dostarczania aplikacji.

Programuje stosunkowo niedługo, ale z tego co wiem frontend zaczął się rozwijać szybko stosunkowo niedawno. Wczesniej nie było aplikacji SPA jak teraz, zaawansowanych narzędzi do budowania frontu, tylko był jakiś server-side rendering albo jakieś proste JQuery.

@wasiu

robiłem frontend w Androidzie :) ciekawa odskocznia. Jakby trzeba było to pewnie i IoS'ie zrobił. To jest coś, co nas wyróżnia jako Polaków na arenie międzynarodowej ale widzę, że nowe pokolenie programistów jest dosyć mocno ograniczona pod tym względem i idzie torami zachodu - robię tylko swoje i nic więcej.

Pozwolę się odnieść do tego w poście. Po prostu niektórzy piszą że backendowcy powinni nauczyć się frontendu żeby lepiej dogadać się z frontendami. Często aplikacja mobilna tez jest frontendem, idąć takim tokiem rozumowania backendowcy powinni też uczyć się Androida.

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