Czy pisanie backendu pod web dev polega tylko na tworzeniu crudowego Rest Api? Czy powinienem Od razu zacząć tworzyć api z bazą danych, czy cos jeszcze do tego trzeba umieć?
0
6
Ahh słodka niewiedza.. :)
Praca na backendzie, jeśli nie jesteś szarym klepaczem w korpo, januszexie czy coś podobnego polega głównie na modelowaniu. Polega na tym, aby napisać logikę aplikacji w taki sposób, żeby różne flow, założenia i przypadki brzegowe przekazane ci od biznesu (czyli ludzi którzy wiedzą co i po co ma robić twoj system) były zawarte w kodzie i idealnie - nie związane z żadnymi konkretnymi technologiami. Często backend devowie muszą myślec o architekturze aplikacji, zdecydować sposób w jaki ma wyglądać np komunikacja w całym systemie.
Często praca polega na integracjach z innymi systemami - np płatności, powiadomienia czy też z innymi teamami. Polega na "chronieniu swojego podwórka" żeby nie dać błędom popełnionym przez twórców systemow z ktorymi się integrujesz wpłynąć na twoj system tak, że przestanie być spójny.
Praca w mikroserwisach, ktore teraz dosyc popularne - polega też na tym aby były one rozsądnie poukładane. Każdy mikroserwis powinien realizować jakis kontekst całego systemu. To znów przynosi ci całą masę decyzji które musisz podejmować, ponieważ czasami opcji jest klika i każda ma wady.
Dodatkowo - w ramach rozsądku warto kod który piszesz przetestować. Tu warto znać libki do testów unitowych i integracyjnych, tak by tworzyć (w tych drugich) wyizolowane środowisko i móc w nim odpalać różne case "blackboxowo" (tzn znasz parametry wejscia i oczekujesz cos na wyjsciu)
Często gęsto backendowcom przypada troche DevOpsa - deploymenty, pipeline, automatyzacja, stawianie klastrów i inne.
Zauważ, że powyżej nie wymieniłem (chyba) ani jednej technologii. Bo praca na backendzie nie polega na "napisaniu REST API w Spring Boot z użyciem PostgreSQL i tokenów JWT" - tylko przede wszystkim na rozsądnym zamodelowaniu tego co aplikacja ma robić dla ludzi którzy będą ją używać.
Ale w skrócie tak - backend to pisanie REST API i zapisywanie/czytanie z bazki.
1
@azalut: czy mógłbyś w ten sam sposób wytłumaczyć mi co to jest frontend? Będę wdzięczny
3
ikdsde
Pewnie są gdzieś ludzie którzy klepią generic crudy, ale generalnie backend to jest zwykle klepanie logiki biznesowej czymkolwiek by ona nie była.
Np. jak robisz przelew w banku to jakimś sposobem pieniadze znikaja z jednego konta a pojawiają sie na drugim i jakby coś w międzyczasie się wywaliło, to nie mogą "zniknąć". Od tego właśnie jest backend. Albo jak w JPL siedzi koleś który jeździ marsjańskim łazikiem, to przygotowaniem odpowiedniego pakietu i wysłaniem go na Marsa też zajmuje się backend.
Frontend jest odpowiedzialny za zrobienie interfejsu użytkownika.
6
@gswidwa1: czym jest frontend pytasz.. no tu może być mi trudniej
Frontend to przede wszystkim.. tak, właśnie CSS i HTML; no i JS. Z mojego doświadczenia można trafić na.. dwie? opcje: projekt w którym są designerzy, UXowcy oraz frontendowcy itd. oraz na team w ktorym frontendowiec jest wszystkim na raz
Więc w tej pierwszej opcji zazwyczaj troche mniej musisz myśleć o UX, a trochę więcej o robieniu tak, żeby było 1 do 1 jak na mockupach, ktore przygotowują designerzy/UXowcy.
W tej drugiej opcji - większe pole manewru, mniej "pixel-perfect" porównywania z mockupami itp. Więcej musisz wiedzieć o UXie, o zachowaniach, trendach na stronach. Znać duże portale i wiedzieć "jak oni to robia" "do czego ludzie sa przyzwyczajeni" itp.
Poza tym - z mojego doświadczenia - większość frontendów nie ma jakiejś wielkiej logiki, większość obsługuje backend. Więc w skrócie można powiedzieć - trzeba procesy backendowe przedstawić tak, żeby end-user nie wiedział o twoich bazach, AWSach i innych zarazach. Powinien być intuicyjnie prowadzony przez aplikacje. Z mojego doświadczenia - czasami drobna zmiana w nazewnictwie robi ogromna róznicę (to samo z reszta jest jak modelujesz backend ale nie o tym tu mowa)
Jak zespół jest typowo DevOpsowy (znaczy że każdy jego członek zaczyna od implementacji, a konczy na wdrożeniu i utrzymaniu ficzera) to musisz znać analogicznie DevOpsa jak napisałem wyżej.
Do tego dochodzi internacjonalizacja (różne jezyki na stronie, sposób obsługi tego, że czasem czyta sie od drugiej strony). Kombinowanie z dark-mode na stronach. RWD - musisz znać swojego odbiorce - jedne aplikacje będą odbierane w 95% przez smartfony, inne w 100% przez IE11 - i inne tego typu.
Poza tym to testy - wiadomo. Choc tu z mojego doswiadczenia czasami wystepują unity, rzadziej jakies testy e2e które automatycznie testują dane user-flow (jakis przypadek biznesowy - logowanie, utworzenie czegos, edycja, usuniecie itp).
Jakoś mam wrażenie że we frontcie bardziej liczy sie znajomość konkretnych technologii. React, Vue, Angular - wiodące narzędzia. Plus miliard innych, małych coś-robiących bibliotek w JS.
Często natomiast są projekty gdzie aplikacja jest internal (na potrzeby firmy, wewnętrzne) i intuicyjność UI, UX albo wygląd mają.. pięciorzędne znaczenie. Wtedy są inne problemy - ma być szybko, na czas. Albo ma wyglądać jak Excel bo każdy kto będzie tego używał jest do niego przyzwyczajony. Czasem jest problem wydajnościowy - np backend zwraca ci tyle parametrów na UI, że musisz to jakoś rozsądnie ogarnąć, żeby nie przycięło.
Na forum są ludzie którzy dużo kompetentniej mogą się na ten temat wypowiedzieć.
2
@azalut: dziękuję Ci bardzo 
, teraz muszę wygooglać kilkanaście wyrazów których nie rozumiem, ale ogólny zarys już mam :) bo rwd to nie jest pewnie "rejestr wydanej dokumentacji" xd
2
Descendant napisał(a):
Czy pisanie backendu pod web dev polega tylko na tworzeniu crudowego Rest Api? Czy powinienem Od razu zacząć tworzyć api z bazą danych, czy cos jeszcze do tego trzeba umieć?
W ogólności to tak, tylko często nie ma cruda, resta, API ani bazy.
A do tego, co @azalut napisał, to dodam, że poza backendem jest też backend backendu, dla którego "biznesem" jest infrastruktura. I tam za bardzo nie ma czego crudować, za to np. trzeba dynamicznie tworzyć mikroserwisy na podstawie jakiejś konfiguracji, albo tworzyć wydajne i konfigurowalne systemy, które przepychają dane z jednej chmury do drugiej. Tak więc, czasem tego API jest bardzo mało, a użycie baz dąży do zera.
gswidwa1 napisał(a):
@azalut: czy mógłbyś w ten sam sposób wytłumaczyć mi co to jest frontend? Będę wdzięczny
Frontend to nie programowanie.