La începutul carierei, aveam o convingere tăcută că backend-ul era partea serioasă a engineering-ului. Frontend-ul era unde făceai lucrurile frumoase. Backend-ul era unde le făceai să meargă.
Greșeam, firește. Dar mi-au trebuit ani de traversat stack-ul în ambele direcții ca să înțeleg cât de mult greșeam, și de ce tocmai călătoria asta s-a dovedit a fi cel mai valoros lucru pe care l-am făcut pentru cariera mea de inginer software.
Începuturile pe backend
Prima mea muncă reală de engineering a fost preponderent pe backend. PHP cu Symfony, construind API-uri REST, proiectând scheme de baze de date, legând logica de business pentru ERP-uri custom și aplicații web. Îmi plăcea claritatea: vine request-ul, rulează logica, pleacă response-ul. Intrări curate, ieșiri curate, comportament previzibil.
Munca pe backend m-a învățat să gândesc în sisteme. Cum circulă datele. Unde se formează blocajele. De ce îți normalizezi schema acum ca să nu regreți peste șase luni. Cum proiectezi un API contract pe care tu, cel de mâine, n-ai să-l blestemi.
Mă simțeam acasă acolo. Backend-ul era locul unde se întâmpla engineering-ul adevărat, sau așa credeam.
Atracția frontend-ului
Prima oară când a trebuit să construiesc un frontend complex, l-am tratat ca pe un inconvenient necesar. Doar randează datele pe care le trimite API-ul. Cât de greu poate fi?
Foarte greu, cum s-a dovedit.
Frontend-ul m-a adus cu picioarele pe pământ. Brusc, aveam de-a face cu state care trăia în browser, nu în baza de date. Cu interacțiuni ale utilizatorului care nu puteau fi prezise sau controlate. Cu sisteme de layout care se comportau diferit pe dispozitive, browsere și dimensiuni de ecran. Cu constrângeri de performanță care n-aveau nimic de-a face cu optimizarea query-urilor și totul de-a face cu ciclurile de randare și dimensiunea bundle-urilor.
Dar dincolo de provocarea tehnică, frontend-ul mi-a schimbat modul în care gândeam despre utilizator. Pe backend, „utilizatorul" era un concept abstract: un request cu headere și un payload. Pe frontend, utilizatorul era o persoană care apasă butoane, așteaptă răspunsuri, se pierde la un label prost scris, abandonează un flow care durează prea mult.
Schimbarea asta de perspectivă, de la system-first la human-first, a fost transformativă.
Aprofundarea pe frontend
Am petrecut peste doi ani ca Lead Frontend Developer, construind întregul dashboard pentru o platformă de infrastructură cloud. Nu era muncă de „fă-l frumos." Însemna state management complex pentru monitorizarea de infrastructură în timp real, arhitecturi de componente care puteau scala pe zeci de view-uri și transformarea unor informații profund tehnice în ceva accesibil pentru ingineri care n-aveau răbdare pentru UX slab.
Apoi a venit React: construind o interfață completă de management pentru o companie de servicii din Madrid. Și Flutter pentru aplicația mobilă. Fiecare tehnologie de frontend nouă m-a forțat să regândesc presupunerile pe care le aduceam din lumea backend-ului.
Ce am învățat în acei ani:
State management-ul e o disciplină în sine. Developerii de backend gândesc state-ul ca „orice e în baza de date." Cei de frontend știu că state-ul e peste tot: parametri URL, local storage, state de componentă, store-uri globale, cache de server, actualizări optimiste. Să-l gestionezi bine e la fel de solicitant intelectual ca proiectarea unei scheme de baze de date bune.
Arhitectura de componente e system design. Cele mai bune codebase-uri de frontend la care am lucrat aveau aceleași calități ca cele mai bune sisteme backend: granițe clare, responsabilități unice, compozabilitate și contracte explicite între module. Pattern-urile sunt diferite, gândirea e aceeași.
Performanța e o funcționalitate, nu o metrică. Pe backend, performanța înseamnă timpi de răspuns și throughput. Pe frontend, performanța înseamnă că utilizatorul nu simte fricțiune. Sunt legate, dar nu identice. Un răspuns API de 200ms se simte lent dacă UI-ul nu arată un loading state. O încărcare de pagină de 2 secunde se simte rapidă dacă conținutul de deasupra fold-ului se randează imediat.
Drumul de întoarcere
După ani de muncă profundă pe frontend, m-am simțit atras înapoi spre backend, dar eram un inginer software diferit acum.
La compania de servicii din Madrid, am proiectat și construit întregul stack: backend Symfony/API Platform, frontend React, aplicație mobilă Flutter, chiar și un sistem de pontaj offline bazat pe NFC. După ce petrecusem ani pe frontend, proiectam acum API-uri altfel. Mă gândeam la datele de care clientul are efectiv nevoie, nu la datele pe care se întâmplă să le aibă baza de date. Structuram răspunsurile de eroare pentru UI, nu pentru fișierul de log. Luam decizii de paginare și filtrare pornind de la cum vor fi randate listele, nu doar de la cum vor performa query-urile.
Drumul dus-întors mi-a dat ceva ce n-aș fi putut căpăta rămânând pe o singură parte: empatie pentru celălalt capăt al firului.
Ce înseamnă fullstack cu adevărat
Am ajuns să cred că „fullstack" e unul dintre cei mai prost înțeleși termeni din engineering.
Nu înseamnă că poți scrie o componentă React și un query SQL în aceeași după-amiază. Asta e doar sintaxă.
Gândirea fullstack reală înseamnă:
-
Înțelegi constrângerile ambelor părți. Știi de ce developerul de frontend cere o altă formă de API. Știi de ce cel de backend se opune conexiunilor WebSocket în timp real. Poți media pentru că ai trăit ambele realități.
-
Proiectezi peste granițe. Când te gândești la o funcționalitate, te gândești la modelul de date, contractul API, state management-ul, interacțiunea din UI și gestionarea erorilor, ca un sistem interconectat, nu ca straturi separate aruncate peste un zid.
-
Faci compromisuri mai bune. Logica asta ar trebui să fie pe client sau pe server? Datele astea ar trebui calculate la citire sau la scriere? Validarea asta ar trebui să fie în formular, în API, sau în ambele? Nu sunt întrebări de religie. Sunt decizii de engineering, și să le iei bine presupune să înțelegi ambele medii.
De ce călătoria contează mai mult decât eticheta
Nu mă mai prezint ca „fullstack developer." Titlul a fost diluat până în punctul în care poate însemna orice, de la „am făcut un bootcamp care a acoperit HTML și Node" la „am proiectat sisteme distribuite și am construit design system-uri."
Ce contează nu e eticheta. E călătoria: disponibilitatea de a intra pe teritoriu incomod, de a fi din nou la început, de a descoperi că problemele pe care le-ai respins drept simple sunt de fapt adânci și fascinante.
Trecerea de la backend la frontend m-a învățat modestie. Trecerea înapoi la backend m-a învățat empatie. Combinația m-a învățat că cei mai buni ingineri software nu sunt cei care sapă cel mai adânc pe un singur lucru, sunt cei care pot ține întreaga imagine în cap și pot lua decizii care servesc sistemul ca întreg.
Asta e valoarea reală a unei călătorii fullstack. Nu că poți face totul. Ci că înțelegi suficient din tot încât să conduci bine.
Dacă ai făcut o călătorie similară, sau te gândești să treci pe cealaltă parte a stack-ului, sunt curios să aud ce te-a surprins cel mai mult. Lecțiile din drumul dus-întors sunt mereu diferite pentru fiecare.