De la UI la Full Stack

Internet
1

Salutare draga comunitate!

Sunt intr-o dilema decizionala fata de tehnologie. Lucrez ca UI Developer cu HTML, CSS, JS unde folosesc Angular, React (TS included). Pe langa asta mai am de a face cu servicii precum jenkins, kafka, alfresco, wordpress (de la custom la builded with themes and plugins like elementor). Sunt destul de obisnuit cu task-urile de UI. As vrea sa trec la nivelul urmator si sa devin full stack. Am facut pana acum ca si experimente scripturi cu python, m-am jucat un pic cu Java si Spring dar strict pe la munca si cu chestii mici. Intrebarea mea este. Conform nevoiei de piata in Romania ce e mai benefic? Java Spring ca si BE framework sau Python Django? Django sincer imi e mult mai friendly si mai usor de perceput si setat pe langa spring. Acum as vrea sa stiu si parerea voastra. Si fiindca vin dintr-un field mainly UI nu prea am avut de a face cu configuri de servere. As vrea sa stiu daca pot face un website cu BE in Django/Spring pe un host normal de website cum folosesc pentru wordpress.

Voi ce parere aveti despre asta?

3 Likes
2

Salutare!

Eu lucrez cu java si spring. Pe front end folosesc insa jsf si primefaces care sunt chestii specifice ecosistemului java. Java cu Sping este cautat, mai ales in zona companiilor multinationale. Pe langa Spring, mai ai si Spring Boot care se bazeaza pe adnotari pt configurare, pe scurt mai muta magie ca spring :smiley:

Pe partea de front end, este la putere si Angular cu Typescript, precum si restul de framework-uri web. Deci aici esti acoperit cu ceea ce deja faci la locul actual de munca.

Legat de partea de configurare de servere, in java world, avem Tomcat. Nici eu nu prea am configurat la el. L-am despachetat si aia a fost. Pt dev si test al aplicatiei pe local nu cred ca este nevoie de o configuratie speciala.

Aplicatiile web in java se pot impacheta in jar-uri si le poti rula cu comada java -jar myApp.jar si gata. Mai este si varianta war, dar pt asta este nevoie de tomcat. Anumite aplicatii pot avea server-ul deja integart, Deci destul de simplu. Tomcat are o interfata de administrare unde poti uploada proiectul tau in arhiva war si se ocupa el de restul.

Legat de care este mai benefic, eu cred ca nu dai gres cu nici o varianta. Insa eu zic sa alegi ce stii mai bine. Iti va fii mai usor. Oricum se cauta si pe java si pe python, deci ambele iti pot pune o paine pe masa.

Succes!

3 Likes
3

Hosturile de baza sunt Amazon AWS, Google Cloud, Microsoft Azure sau IBM Cloud. Probabil Google Cloud e cel mai usor de utilizat, dupa vine Azure cu integrare in VSCode sau Visual Studio.

O solutie de compromis e https://zeit.co ca sa pornesti cat mai simplu pe backend.

Java e cerut de multinationale, daca vrei sa faci bani in ziua de azi eu m-as axa pe Java low-latency si Java microservices. Problema e ca la interviu toata lumea o sa iti ceara vechime, which sucks.

Calea de mijloc ar fi golang sau nodejs pentru frontend + backend, nu e greu, n-ai nevoie de cine stie ce experienta si in multe locuri se cauta. NodeJS cu Apollo GraphQL si rxJS e genial cu Angular pe frontend.

La Django la fel ca si cu Java, pot sa iti ceara multi ani de experienta din start.

1 Like
4

Eu am o parere putin diferita. Nu cred ca este nevoie sa devii fullstack pentru a trece la “nivelul urmator”.
Eu pot spune ca sunt fullstack. Am inceput cu .NET (C#) acum 15 ani, iar de vreo 5-6 ani lucrez mai mult pe partea de frontend (AngularJS, Angular, Typescript).

Problema mea (poate altii invata mai repede) este ca nu pot tine pasul cu ambele. Prin 2013 am avut o perioada de vreo 2-3 ani in care am facut doar frontend (AngularJS), practic atunci am invatat Javascript.
Dupa aceea am schimbat pe un rol de fullstack si a trebuit sa “catch-up” cu ce s-a schimbat in .NET. Poate nu chiar atat de multe, dar mie mi-a placut mereu sa adopt tehnologii si arhitecturi noi.
Daca inainte de 2013 lucram in .NET cu arhitecturi 3-tier (sau n-tier), data-centric, in 2015 toata lumea vorbea despre Domain Driven Design, microservicii, etc., ceea ce e cu totul altceva.

Referitor la experienta mea pe frontend (cu Angular), pot spune ca m-a ajutat enorm faptul ca stiam OOP destul de bine, plus ceva arhitectura.
Poate sunt cam dur, dar personal nu am intalnit multi (ii numar pe degetele de la o mana) programatori pur de frontend care sa stie si ceva arhitectura, si care sa stie sa proiecteze o aplicatie de frontend bine organizata si scalabila.

Astfel, cred ca programatorii de frontend au foarte mult loc de crescut in directia asta - a arhitecturii aplicatiilor frontend. Trebuie doar sa-si deschida putin ochii. Aplicatiile web din ziua de azi pot fi extrem de complexe.

In momentul de fata pregatesc o prezentare pentru echipa mea despre “Clean Architecture in Angular” - adaptarea unor tehnici de Domain Driven Design pe frontend.
De ce? Pentru ca desi am programatori frontend mai buni decat mine in echipa, nu sunt prea organizati (in cod), iar dupa 6 luni de dezvoltare a unui monorepo (2 aplicatii momentan + librarii) de catre o echipa de 5-6 web developeri, mi se pare ca tindem spre o arhitectura “monolith” si “spaghetti code” - da, se poate si in Typescript.

Asa ca sfatul meu pentru orice frontend developer este sa aprofundeze framework-ul (sau framework-urile) cu care lucreaza, sa invete arhitectura Redux/Flux, reactive programming si alte lucruri smechere care se folosesc acum.
Web developmentul s-a dezvoltat foare mult in ultimul timp, iar web developerii vor avea de munca multi ani de acum incolo. La fel si foarte multe lucruri de invatat.

7 Likes
5

Crezi ca poti share-ui prezentarea? :slight_smile:
Si eu lucrez in Angular de ceva timp si m-ar interesa sa-mi dezvolt cunostintele pe zona asta
Presupun ca principiile se aplica indiferent de framework
Mersi

1 Like
6

In caz ca intereseaza pe cineva, las aici slide-urile de la prezentarea mea - Advanced Angular, November 2019.pptx
Cu mentiunea ca a fost o prezentare interna pentru echipa mea, nu pentru vreo conferinta (nu sunt trainer sau speaker).
Parola este: AdvancedAngular

3 Likes
7

Dacă în back end era Node JS nu exista problema.

8

M-am uitat peste prezentare, am vazut istoricul tau de .NET si chiar ma mir ca ai prezentat pattern-ul de state reducer in Angular. E o idee buna, dar destul de greu de aplicat peste tot.

Problema de spaghetti code se rezolva doar cu code review la fiecare pull request, poate un SonarQube pe github/gitlab si timp pentru refacturat la N sprint-uri.

@George_Ilie NodeJS e o idee buna si pe backend si pe automatizare. (totusi eu care il folosesc zi de zi trebuie sa precizez ca un incepator ar fi foarte confuz daca intervin erorile de compilare de la libariile care contin dependine de C sau daca nu face microservicii, daca vrea sa foloseasca TypeScript, daca vrea rxJS) In schimb e foarte accesibil la websockets si graphql.

9

Cum ziceam mai sus, suntem o echipa relativ mica (~6 web devs), dar construim un monorepo pentru mai multe aplicatii de tip produs si cuvantul de ordine este “maintainability”. UI-ul trebuie sa reziste ani buni de acum inainte si sa fie relativ usor de extins.

Din pacate nu avem Pull Requests inca, deci code review-ul lasa de dorit. Folosim un server GIT rudimentar, dar vrem sa trecem la GitLab.

Eu nu mai cred in timp pentru refactoring la N sprint-uri, asa cum nu mai cred nici in “vom scrie teste unitare mai incolo” sau “scrie tu niste teste pentru codul meu”. Am observat ca de multe ori sunt pusi sa scrie teste cei care vin noi in echipa, chipurile “asa se familiarizeaza si ei cu codul”.
Mai mereu m-am trezit cu teste greu de mentinut sau inutile care de fapt nu testau nimic, ci erau ma mult teste de integrare.

Testele trebuie scrise atunci cand scrii codul (sau INAINTE sa scrii codul) si trebuie scrise de cel care scrie codul respectiv, ca el stie cel mai bine ce a facut acolo. Si nu trebuie scrise teste pentru orice, ci doar pentru lucrurile mai complexe. Just my 2 cents.

Cat despre refactoring - unii spun ca in secunda in care ai facut release, codul devine deja “legacy” si trebuie mentinut. Apoi, stim cu totii ca “niciodata nu va fi timp suficient pentru refactoring”, asa ca ne cam invartim in cerc mereu.
Solutia? - Refactoring continuu, eventual scris codul bine de la inceput. Pentru asta trebuie multa experienta si ceva timp investit pentru arhitectura si design vs. “azi incepe proiectul, hai sa scriem niste cod si vedem noi mai apoi cum il refactorizam”.

I’m late to the party, dar din punctul meu de vedere Rxjs, Redux si “one-way data flow” reprezinta diferenta majora dintre Angular 2+ si AngularJS. Restul sunt detalii.

2 Likes