Back-end vs Front-end — czym to się tak naprawdę różni?

Słuchasz podcastu DevStarter. Twojej przestrzeni rozwoju w branży IT. Odcinek 9. Wracamy po wakacyjnej przerwie i dzisiaj porozmawiamy o tym jak to jest pracować na Front-endzie i Back-endzie. Będzie konkretna analiza i postaramy się ukazać jak nam się pracuje w naszej specjalności. Zapraszam do odsłuchu. Dzień dobry. Witamy Was serdecznie po długiej przerwie. Zrobiliśmy sobie wakacyjną przerwę, o której wspominaliśmy w ostatnim odcinku, ale ta przerwa właśnie minęła i dzisiaj słyszymy się ponownie. Bardzo się z tego cieszę. Dziewiąty odcinek. Czarku, witaj ponownie.

Będzie to całodniowa transmisja, podczas której będziecie mogli posłuchać wartościowych prelekcji przygotowanych przez wspaniałych prelegentów, którzy w tej branży zjedli już zęby z najróżniejszych specjalności, więc na pewno każdy znajdzie coś dla siebie. Zobaczcie więcej informacji na stronie dzieńprogramisty.pl. Oczywiście bez polskich znaków. Tam jest wszystko. Warto wziąć udział 13 września. To jest data, to jest ten dzień programisty taki oficjalny, przyjęty. Więc zachęcamy. A dzisiaj porozmawiamy sobie o bardzo fajnym temacie w mojej ocenie, ponieważ porozmawiamy o tym, jakie są różnice między back-endem a front-endem. I to jest o tyle fajny temat, że ja jestem front-endowcem, Czarek jest back-endowcem, więc idealnie możemy przekazać Wam naszą perspektywę i ukazać, jakie są różnice.

Z czym się je? Daną specjalność, jakbyśmy mogli tak to ująć. I zacznijmy może od takiego bardzo ogólnego pytania. Czarek, dla Ciebie, jak myślisz sobie o back-endzie i front-endzie, to czym to się tak naprawdę różni? Oczywiście nie mówimy tutaj o tym, co widać, jakby co tworzymy, ale faktycznie co to ma w sobie jeszcze ukrytego? Wracając jeszcze do tej autopromocji, to tam też będą właśnie takie perspektywy back-endowców, front-endowców, więc jeszcze jak najbardziej ja zachęcę osobiście do udziału w tym wydarzeniu, bo to jest naprawdę mega inicjatywa i tutaj oczywiście Wielkie podziękowania dla Radka, że on to wszystko tutaj ogarnia i właśnie zgarnął naprawdę świetnych prelegentów.

I to wszystko jakoś organizacyjnie dźwiga, bo robi to sam. To trzeba podkreślić, że jest jednoosobową armią, która ogarnia tak duże wydarzenie. Drugie w swojej chyba karierze, o ile Radku się nie ma lat możesz mnie poprawić, bo wcześniej był świąteczny kalendarz programisty, teraz mamy dzień programisty, więc fajne charytatywne wydarzenia i warto być jego częścią. Jeśli chodzi o back-end i front-end, no to co? W skrócie można powiedzieć, że to jest to co widać i to czego nie widać. A jeśli chodzi o jakąś taką dłuższą odpowiedź, no to jest tutaj cała masa różnic. Bo jeśli chodzi o front-end, to tutaj pewnie Radek więcej nam opowie.

Od strony back-endowej, no to jasne, tutaj działamy po stronie serwera, przetwarzamy te dane, komunikujemy się z innymi aplikacjami, z innymi dostarczycielami jakichś tam dodatkowych funkcjonalności, integracje. Ale musimy może myśleć pod kątem biznesowym troszeczkę z innej perspektywy, czyli patrzeć jaki mamy wolumetrykę użytkowników, jak dużo żądań tu przychodzi, patrzeć czy to się spina biznesowo, czasami robić jakieś trade-offy, czy warto wchodzić w daną technologię, czy też nie warto. No tutaj pewnie też można znaleźć te części wspólne z front-endem. Ale jednak patrzymy na bardziej przetwarzanie danych i właśnie tą komunikację z innymi aplikacjami niż na samo prezentowanie tych danych.

Zdecydowanie między front-endem a back-endem są olbrzymie różnice. Ja kiedyś miałem wrażenie, że te różnice się zacierają, że front-end robi warstwę wizualną, back-end robi warstwę logiczną nazwijmy to. Ale gdy dłużej już popracowałem w tej branży, to zauważyłem, że nie do końca tak musi być, bo logika biznesowa również może być po stronie front-endu. Nawet niektóre widoki mogą być po stronie back-endu. Przecież jest znane takie podejście jak tworzenie label partsów, które właściwie Przygotowują praktycznie cały kawałek ze strony back-endu, front-end musi je tylko odpowiednio poskładać i tyle, więc to się bardzo mocno zatarło z biegiem lat, jak też ta technologia gdzieś tam stawała się coraz bardziej dojrzała.

I faktycznie jest tak, że Front-end jest uznawany za tą warstwę, którą widać, Back-end, której nie widać. I uważam, że w tym jest bardzo dużo prawdy i właściwie nie wyobrażam sobie sytuacji, żeby Front-endu jakby nie miało być widać. Oczywiście my na Front-endzie przede wszystkim definiujemy jak strona internetowa działa. My obsługujemy zdarzenia, my obsługujemy jak coś tam wygląda, my obsługujemy W jaki sposób użytkownik wchodzi w interakcję z przeglądarką? Druga rzecz, którą Front-end robi, no to oczywiście jest obsługa tego, co serwer nam wypluwa. To, co przesyła nam na warstwę Front-endową. I jest tak, jak powiedziałeś, że Back-end

Ja kiedy wchodziłem do branży, no to branża już miała mocny podział pomiędzy back-endowców i I ja nie wiedzieć czemu zdecydowałem się na bycie back-endowcem. Może z tego powodu, że gdzieś tam dotykałem jakiegoś C++ na studiach. Kompletnie tego nie rozumiałem, ale gdzieś miałem to z tyłu głowy, że głównie programowanie to właśnie ten język. Potem przyszła pora na naukę Javy, a dopiero potem zacząłem poznawać takie języki jak Javascript czy tam właśnie jakieś takie bardziej front-endowe. Names mentioned.

Radek Wojtysiak. Jakiś sklep internetowy i po prostu musiał sam naklepać coś w PHP i gdzieś to tam ładnie zaprezentować, żeby można było z tego korzystać. Być może wraz ze wzrostem skomplikowania projektów wyniknęła właśnie taka potrzeba na podział właśnie back-endowy i front-endowy. A teraz znowu słyszę głosy, że to się znowu zaczyna trochę zacierać, więc tutaj nie wiem czy się trochę nie zgodzimy jednak Radku.

Jeszcze, no może nie kilka lat, ale paręnaście lat temu, w sumie gdy ja też zaczynałem, to faktycznie było takie stanowisko web developer, na przykład w przypadku moim, w sensie w przypadku aplikacji internetowych. I to był one-man army, który robił wszystko od podstaw. Najczęściej to był PHP, który tam wystawiał sobie jakąś tam warstwę komunikacji z bazą danych, no i jednocześnie robił widoki. Już nawet nie pamiętam, jak to się tam dokładnie nazywało, ale pamiętam te swoje początki, że właśnie w ten sposób to robiłem. Później ten podział zrobił się taki, jaki mamy teraz, czyli front-end i back-end. I to zdecydowanie powstało Z potrzeby rynku, tak?

Oczywiście, my teraz jesteśmy w stanie stworzyć całą aplikację, jak najbardziej. Całą warstwę back-endową, front-endową. Jeśli potrzebujemy, to również i warstwę mobilną. Tylko problem jest taki, to że ten AI stworzy nam działający fragment kodu, stworzy nam działającą aplikację. Czy to oznacza, że my wiemy, co tam się dzieje? Czy my wiemy, jakie niebezpieczeństwa No bo może, nie wiem, nie pomyśleliśmy, że tutaj jest jakaś tam możliwa do wykonania podatność, czy tam jakiś atak, tak? I ja zawsze obawiam się tego, że jeżeli, oczywiście tutaj podkreślam, zdarza mi się robić już teraz tak, że jeżeli tworzę sobie jakąś tam warstwę back-endową, powiedzmy prostego kruda, który miałby coś

No właściwie tylko podać dane, umożliwić mi ich edycję oraz usunięcie. No to wykorzystuję do tego AI, ale plus jaki widzę w tym jak ja to robię, czyli osoba już tam po parunastu latach doświadczenia jest taki, że ja dokładnie wiem co robię. Ja nie mówię sztucznej inteligencji zrób mi warstwę back-endową do tego, tego i tego. Ale mówię po kolei, że tworzymy warstwę serwerową, która ma takie i takie zapytania http, mają one to przyjmować, mają być walidowane, mają uważać na jakieś tam SQL injection, na różne tego typu aspekty. Osoba, która tego nie wie, Ona łatwo może wprowadzić błąd po prostu z własnej niewiedzy, który może doprowadzić do jakiś kosztów albo spowodować jakieś anomalie w działaniu systemu.

Więc podpisuję się pod tym, że teraz Ten full stack, czyli to bycie programistą od wszystkiego ma sens i stało się to bardzo łatwe, ale ostrożnie, więc faktycznie tutaj trochę na ten moment wydaje mi się, że zataczamy koło. I jak sobie o tym mówiłem, to poczułem lekką frustrację, nie ukrywam, i zrodziło to w mojej głowie pytanie, Co według Ciebie jest największym takim źródłem właśnie frustracji? Jak myślisz sobie o Front-endzie, Back-endzie? Może tego full stacka na ten moment zostawmy, bo to też nie miał być główny temat naszej rozmowy. Jakie frustracje po Twojej stronie są największe? Centrowanie Diva. To jest dla mnie dalej czarna magia.

Ale jeśli chodzi o powiedzmy moją specjalizację, czyli bycie po tej stronie back-endowej, Jest dużo takich aspektów związanych z przetwarzaniem dużej ilości danych, żeby też spinać to wszystko jeśli chodzi o wydajność bazy danych, czy też jak najszybsze obsłużenie danych żądań. To jest mega frustrujące, czy może nie tyle, że frustrujące, tylko wymagające, żeby to wszystko ogarnąć, żeby pospinać te aspekty i dostarczyć takie rozwiązanie, które będzie spełniało jakieś wymagania biznesowe. Kolejna rzecz to bardziej taka może organizacyjna, że każdy może mieć jakieś swoje konwencje i czasami ciężko przekonać kogoś z zespołu do swoich racji.

Pomimo tego, że być może to w dłuższej perspektywie nie mieć znaczenia, trochę takie trudność przewidzenia tego, co się wydarzy w przeszłości i próbowanie dostosować do tego nieprzewidzianego aspektu jakieś rozwiązanie, które aktualnie projektujemy. Również samo śledzenie żądań, które są wysyłane pomiędzy wszystkimi serwisami w backendzie jest trudne. Jest dużo narzędzi, które to wspomaga, ale to nie jest najprostsza rzecz. No i również programowanie współbieżne. Jeśli ktoś nie ma takiego abstrakcyjnego Myślenie albo nawet nie potrafi się jakoś tak może powiedzmy wgryźć w to jak te wątki mogą ze sobą się powiedzmy nie dogadywać no to to jest mega frustrujące i czasami nawet jak ktoś ma duże doświadczenie to i tak i tak może w tym ugrząć na bardzo wiele godzin czy nawet dni z takim problemem więc tak jest trochę takich aspektów które powodują frustrację ale myślę że też tutaj może takie podobieństwo pomiędzy front-endem i back-endem to jest estymacja.

To jest mega trudna rzecz. Czasami ludzie już mają jakieś tam swoje utarte schematy, że wyceniają coś na dwa dni, no bo tak zawsze wycenialiśmy, a finalnie przychodzi rzeczywistość i to wszystko weryfikuje, że jednak czegoś nie przewidzieliśmy, ktoś nam czegoś nie dostarczył, a jednak często jesteśmy rozliczani z właśnie dotrzymywania terminów. Wyobraź sobie, że większość back-endowców wskazuje właściwie te same rzeczy, które ty wskazałeś, jeśli chodzi o front-end. I trochę tego nie rozumiem, bo jak zapytać front-endowca, czy zaprogramuje coś w back-endzie, to może trochę pomarudzi, ale jakoś tak, nie wiem, te języki programowania ogólnie jakoś tak łatwiej je użyć. Przynajmniej ja tak mam. Jeżeli ktoś mi każe coś napisać w Javie, no to

Nie znam tego języka bardzo dobrze, ale jakoś tak jest mi chyba łatwiej niż back-endowcom pisać front-end. Moje frustracje, jeśli chodzi o front-end, to tak jak powiedziałeś CSSy i to jest ciekawa rzecz, ponieważ CSSy w teorii są łatwe, bo to są tylko reguły. To są reguły, to nie jest jakby język programowania, nie ma tu logiki biznesowej, więc w teorii jest to łatwe, ale struktura HTML-owa Bywa bardzo zawiła, bardzo skomplikowana, szczególnie jeśli mówimy jeszcze o ShadowDome'ie, czyli takim, który jest generowany przez JavaScript i on musi jakoś być tam dekorowany, tam są różne kolejności wywoływań oczywiście, żeby te styre w odpowiednim momencie renderowania strony pokazały i tym podobne. To ja niestety jestem już na etapie, że CSS mnie irytuje, ale irytuje mnie nie z powodu tego, że ja go nie rozumiem, tylko z powodu tego, że jest tam tak bardzo dużo rzeczy, o których trzeba pamiętać oraz jest niesamowicie trudno zapewnić

Irytowało mnie sposób interpretacji niektórych operacji, które JavaScript wykonuje, ale wydaje mi się, że chyba się już do tego przyzwyczaiłem i po prostu już myślę tym torem, więc to już mnie po prostu nie frustruje. Z kolei na back-endzie, back-end dla mnie nie jest aż taki irytujący, co ciekawe, z powodu tego, że on jest dla mnie ciekawy, bo jest to jakby dla mnie Coś czego nie wykonuję na co dzień i jak ja mam do realizacji zadanie back-endowe to ja czuję olbrzymią satysfakcję jak udaje mi się takie zadanie odhaczyć. Myślę sobie z takiej frustracji, że pierwsze co bym wskazał to jest duży poziom abstrakcji. W sensie bardzo mnie irytuje te dziesiątki plików, które są potrzebne, żeby zrealizować jakąś jedną, powiedzmy większą operację, czy to jakąś logikę biznesową.

Zawsze mi się kojarzy to takie drzewko plików w Javie, jak się tam tworzyło jakąś klasę i było tego tam naście plików do jednej klasy. To jeszcze ze studiów pamiętam i później Gdzieś tam te zagnieżdżanie tych katalogów, to było dla mnie tak strasznie nielogiczne, a jak jeszcze do tego dodawało się katalog z testami, to to już w ogóle mi puchło i ja totalnie nie mogłem się w tym odnaleźć, bo przecież we Front-endzie mamy jakby jeden plik, przynajmniej w React, który zawiera i warstwę logiczną i warstwę wizualną. Oczywiście można to mocniej rozbijać, ale no co do zasady jest to raczej w jednym pliku. Druga rzecz, która mnie irytuje w Back-endzie i teraz zacząłem się zastanawiać, może mnie irytuje, bo nie wiem jak ją inaczej zrobić, no to to jest to, że tam tak naprawdę mało rzeczy jest takich out of the box.

I to jest bardzo fajne. W przypadku back-endu jest to znowu mocno rozmyte, w sensie ja mam wrażenie, że żeby dojść do właściwego błędu, no to trzeba tam setki linii jak czasami przeczytać. I może znowu nie miałem jeszcze takiej okazji, żeby samodzielnie jakby tworzyć takie zaawansowane logi, może to idzie jakoś lepiej zrobić. Ale idzie się do tego przyzwyczaić i ja się tego nauczyłem, że jak muszę sobie coś sprawdzić, w vlogach właśnie, że serwer coś tam zrobił i coś mi nie działa, to potrafię to przeczytać. Kwestia przyzwyczajenia. To jest właśnie ciekawe, że troszeczkę mamy inny background i to, co teraz ty do mnie mówisz, jeśli chodzi o back-end, no to jest takie, że coś tam jest, taki gotowy komponent, a okej z tymi logami, to nie jest takie złe.

Jeśli chodzi o pakietowanie w Javie, to ma to sens, a właśnie twoja perspektywa też jest ciekawa i dosyć cenna, żeby tak właśnie też tego przesłuchać. Pewnie tak, jak ja mówiłem o front-endzie, to tobie też tak jakoś to lepiej przychodziło do przyswojenia, że to wcale nie jest też takie Właśnie to co wspomniałeś a propos CSS-ów, to mnie mega frustrowało, że właśnie zastanawiałem się czy ta reguła, którą tutaj napisałem nie zostanie napisana przez inną regułę, czy coś powinno być globalne, a druga kwestia, że dobieranie kolorów to też nie jest rzecz, którą mógłbym się pochwalić tak powiedzmy publicznie. Ale jeśli chodzi jeszcze o takie dopowiedzenie z tym back-endem, no to tam są gotowe biblioteki, które możemy wykorzystywać, tylko to jest właśnie kwestia tego, kto bardziej się czuje ekspertem w danej dziedzinie.

Więc tutaj też może się kiedyś w to bardziej zagłębimy, jeśli chodzi o właśnie łączenie biznesu z technologią, bo to jest mega ciekawy temat. Czarku, my tu przez pół godziny mówimy o różnicach, mówimy o tym co, no nie chcemy tutaj powiedzieć co jest lepsze, gorsze, ale pewnie słuchacz jak przeanalizuje nasze wypowiedzi może sobie gdzieś tam ukierunkować swój punkt widzenia. To może powiedzmy trochę o współpracy między front-endem a back-endem. Jak taka dobra współpraca wygląda według Ciebie? Czy masz konkretne cechy u front-endowca, które gdzieś tam szanujesz, które pozwalają Ci, żeby ta współpraca była świetnej jakości, a może są jakieś zachowania, które powodują, że Ty jako back-endowiec jesteś zirytowany i powiedzmy z takim front-endowcem współpracować nie lubisz? To jest bardzo ciekawy aspekt.

Najlepiej dogadać się z samym sobą, więc taka rola full-stacka jest tutaj najbardziej odpowiednia, jeśli miałbym tutaj powiedzieć coś wprost, co mi pierwsze przychodzi do głowy. Natomiast jeśli pracujemy w bardziej dojrzałej organizacji, gdzie faktycznie mamy takie zespoły typowo back-endowe i front-endowe, No to ta komunikacja jest istotna, jest niezbędna do dobrego funkcjonowania i po prostu do dostarczania kolejnych funkcji biznesowych, więc jeśli miałbym wskazać z perspektywy back-endowca, jak taki front-end developer mógłby tutaj ze mną dobrze funkcjonować, No to jest taka świadomość tego, że jeśli na przykład mamy jakiś komponent, czy tam dwa komponenty na frontendzie, to one mogą odpowiadać za kompletnie inną logikę biznesową.

To nie jest tak, że teraz powinniśmy myśleć w postaci makiet, że jeśli mamy jakąś stronę, to ona jest tylko jednym elementem po stronie back-endu. Tam mogą się dziać różne procesy biznesowe. Możemy mieć ścieżkę zakupową, która będzie na tej samej stronie na przykład ze ścieżką reklam. A to będzie kompletnie coś innego pod kątem back-endu. Dodatkowo jasna i klarowna komunikacja tego, co dany komponent front-endowy potrzebuje. Tutaj mam na myśli kontrakt, który musimy zawrzeć pomiędzy front-endem a back-endem. Żeby było wiadomo jakie przysłowiowo te pola są potrzebne, jakie dane są potrzebne do wyświetlenia na frontendzie i jak można to po prostu osiągnąć. No bo tak jak wspomniałem wcześniej, możemy mieć dwa procesy biznesowe, które mają różne dane, a my chcemy to zestawić wspólnie na danej stronie.

Co może nie być takie proste. Więc przydałoby się, żeby taki front-endowiec też czuł, że po stronie back-endu są inne procesy, inaczej to trochę funkcjonuje. Być może taka świadomość dodatkowych warstw typu back-end vs front-end też by się tutaj przydała. Albo np. jak te dane mogą być szybko dostarczone na front-end, bo czasami coś może dziać się asynchronicznie. I niekoniecznie możemy to od razu przedstawić użytkownikowi w danym momencie. Być może trzeba na to poczekać. Więc ta świadomość tego, że nie wszystko mamy od razu, jest bardzo pomocna. Więc troszeczkę trzeba nie zamykać się tylko w swoim świecie, że ja jestem back-endowcem i tyle, tylko jako back-endowiec muszę znać niektóre koncepty, które pozwolą mi dobrze funkcjonować w tym świecie back-endowo-front-endowym, żeby umieć się dogadać z tym.