Saptamana trecuta m-a intrebat cineva: "De ce nu folositi microservicii?"
Raspunsul scurt: pentru ca nu avem nevoie.
Am vazut startup-uri cu 200 de utilizatori care aveau arhitectura de microservicii pe Kubernetes. Costul de hosting: 800 EUR/luna. Acelasi lucru facea un singur server de 20 EUR/luna. Dar cineva a citit un articol pe Medium si a decis ca "asa se face". E aceeasi mentalitate ca la clientul care a vrut tot si a pierdut 6 luni.
Alegem tehnologii ca sa rezolvam problema clientului cel mai rapid, cel mai stabil si cel mai ieftin de intretinut — nu ca sa fim la moda.
Raspuns scurt
Folosim Node.js + Express pentru backend, PostgreSQL pentru baza de date, vanilla JavaScript pentru SPA-uri simple si Next.js pentru site-uri publice cu SEO. Hosting pe VPS-uri Hetzner (15-40 EUR/luna). Evitam microserviciile, framework-uri grele si tehnologii "la moda" care adauga complexitate fara beneficiu real. Deviem de la standard doar cand un proiect cere explicit altceva (Redis pentru queue-uri, Socket.io pentru real-time). Procesul de decizie: cine foloseste, cat de complex, cine intretine.
Pentru cine este acest articol
- Antreprenori care vor sa inteleaga de ce un developer recomanda o anumita tehnologie
- Fondatori de startup-uri care au auzit de microservicii, Kubernetes, serverless si se intreaba daca au nevoie
- Clienti care vor sa ia o decizie informata inainte de a investi in dezvoltare
- Developeri curiosi sa vada cum gandeste o echipa mica cand alege stack-ul
Problema cu "ce e la moda"
Industria tech are o obsesie cu noul. Fiecare an vine cu un framework nou, un pattern nou, o arhitectura noua care "schimba totul". Kubernetes. Microservicii. Serverless. Edge computing. AI-first. Fiecare cu promisiunea ca va rezolva toate problemele.
Stii ce rezolva problemele? Codul care functioneaza, care e usor de inteles si care nu se strica la 3 noaptea.
Nu alegem un stack ca sa impresionam pe nimeni. Il alegem ca sa livram rapid, sa intretinem usor si sa nu platim de 10 ori mai mult pe hosting decat e necesar.
Stack-ul nostru standard
De-a lungul a zeci de proiecte, am ajuns la un set de tehnologii pe care le cunoastem bine, care rezolva 90% din cazuri si care ne permit sa livram rapid.
| Tehnologie | Rol | De ce |
|-----------|-----|-------|
| Node.js + Express | Backend / API | Un singur limbaj (JS) pe tot proiectul. Express e simplu, matur, fara "magie". Un junior intelege codul in 2 ore. |
| PostgreSQL | Baza de date | Datele de business sunt relationale. 50 de ani de functionare dovedita. JSON columns cand ai nevoie de flexibilitate. |
| Vanilla JavaScript | SPA-uri simple | Zero dependinte. Se incarca instant. O app interna cu 5 pagini nu justifica 40 KB de React. |
| Next.js | Site-uri publice | SSR, SEO, imagini optimizate. Folosim pentru prezentari, landing pages, platforme cu continut public. |
| PM2 | Process management | Restart automat, logs centralizate, zero-downtime deploy. Un tool care face treaba a trei. |
| Hetzner VPS | Hosting | 15-40 EUR/luna. Performant, predictibil, fara surprize la factura. |
Node.js + Express pentru API-uri. JavaScript pe server si pe client inseamna un singur limbaj in tot proiectul. Express e simplu, matur, cu ecosistem enorm. Nu are magie — stii exact ce face fiecare linie. Cand un junior vine pe proiect, intelege codul in doua ore, nu in doua saptamani.
PostgreSQL pentru baza de date. Intotdeauna. Am incercat MongoDB. Am incercat MySQL. Ne-am intors mereu la Postgres. De ce? Pentru ca datele de business sunt relationale. Clientii au comenzi. Comenzile au produse. Produsele au categorii. Modelul relational exista de 50 de ani pentru ca functioneaza. Plus: JSON columns in Postgres iti dau flexibilitatea unui document store cand chiar ai nevoie.
Vanilla JavaScript pentru SPA-uri simple. Da, suna ciudat. Dar multe aplicatii nu au nevoie de React. O aplicatie interna cu 5 pagini, cateva formulare si un tabel — de ce ai incarca 40 KB de React pentru asta? Vanilla JS cu module ES6, cateva utilitare, si gata. Se incarca instant. Zero dependinte de actualizat. Din acelasi motiv de ce nu folosim WordPress ca default — alegem unealta potrivita, nu cea populara.
Next.js pentru site-uri publice. Cand avem nevoie de SEO, de server-side rendering, de imagini optimizate si de o prezenta web profesionala — Next.js e alegerea corecta. Il folosim pentru site-uri de prezentare, landing pages si platforme cu continut public. Inclusiv site-ul pe care citesti articolul asta.
---
Ai un proiect si nu stii ce stack e potrivit? Descrie-l si iti recomandam.
---
Cand deviem de la standard
Nu suntem dogmatici. Daca un proiect cere altceva, folosim altceva.
Am construit un sistem de procesare video care avea nevoie de queue management — am adaugat Redis si Bull. Am avut un proiect cu cerinte de real-time complex — am folosit Socket.io. Am avut un client care voia aplicatie mobila cu acces la camera si notificari push native — am recomandat React Native.
Cheia e sa nu adaugi complexitate preventiv. Nu pui Redis "pentru ca poate o sa ai nevoie". Il pui cand ai nevoie. Si cand il pui, stii exact de ce.
De ce evitam microserviciile
Microserviciile rezolva o problema reala: echipe mari (50+ developeri) care lucreaza pe acelasi produs si au nevoie sa deployeze independent. Netflix are nevoie de microservicii. Uber are nevoie de microservicii.
Un SaaS cu 500 de utilizatori si doi developeri? Nu.
Microserviciile introduc: comunicare intre servicii (HTTP/gRPC/message queues), deploy separat pentru fiecare serviciu, monitoring distribuit, debugging complex cand ceva se strica intre servicii, si un cost de infrastructura mult mai mare.
Noi construim monolite bine structurate. Un singur proces Node.js cu rute organizate pe module. Fiecare modul e izolat logic, dar ruleaza in acelasi proces. Daca maine trebuie sa extragi un modul intr-un serviciu separat, codul e deja organizat pentru asta. Dar nu o faci pana nu ai un motiv real.
| Criteriu | Monolit structurat | Microservicii |
|----------|-------------------|---------------|
| Echipa | 1-10 developeri | 50+ developeri |
| Deploy | Un singur proces, simplu | Servicii separate, complex |
| Debugging | Stack trace complet | Tracing distribuit necesar |
| Cost hosting | 15-40 EUR/luna | 200-800+ EUR/luna |
| Timp de dezvoltare | Rapid — un repo, un deploy | Lent — coordonare intre servicii |
| Cand are sens | 90% din proiecte | Netflix, Uber, Google |
Procesul de decizie
Cand vine un proiect nou, ne punem trei intrebari:
1. Cine va folosi asta? Daca e un site public, SEO conteaza, deci Next.js. Daca e o aplicatie interna, nu avem nevoie de SSR, deci SPA simplu.
2. Cat de complex e? Un CRUD cu 10 entitati nu justifica React. O aplicatie cu drag-and-drop, real-time updates si stare complexa pe client — da, React are sens.
3. Cine va intretine asta? Daca clientul are un developer junior care va prelua proiectul, scriem cod cat mai simplu posibil. Fara abstractii sofisticate. Fara patterns esoterice. Cod pe care il intelegi citindu-l.
Un exemplu concret
Ultimul proiect: o platforma de mentorat. Utilizatorii isi aleg un mentor, completeaza un formular, primesc materiale zilnice si raporteaza progresul.
Stack ales: Express + PostgreSQL + vanilla SPA + PM2 pe un VPS de 15 EUR/luna.
Am livrat in 4 saptamani. Ruleaza stabil de 3 luni. Cost total de hosting: 15 EUR/luna. Daca am fi ales Next.js + Vercel + Prisma + PlanetScale, am fi platit 50-100 EUR/luna pentru acelasi rezultat. Si am fi avut 3x mai multe dependinte de intretinut. Daca te intereseaza costurile complete, am detaliat cat costa o platforma SaaS in Romania.
Checklist rapid
- [ ] Alege un singur limbaj pe tot proiectul (noi: JavaScript fullstack)
- [ ] Foloseste baza de date relationala daca datele au legaturi intre ele (clienti-comenzi-produse)
- [ ] Nu adauga framework pe frontend daca ai sub 10 pagini si formulare simple
- [ ] Nu pune microservicii daca ai sub 50 de developeri pe proiect
- [ ] Alege hosting predictibil (VPS fix, nu pay-per-use cu surprize)
- [ ] Testeaza ca un junior intelege codul in ore, nu saptamani
- [ ] Adauga complexitate (Redis, queues, real-time) doar cand ai nevoie concreta
Obiectii frecvente
"Dar daca creste si nu scaleaza?"
Un monolit pe un VPS de 40 EUR/luna suporta mii de utilizatori concurenti. Cand ai problema de scala — felicitari, ai un business de succes si banii sa rezolvi problema. Nu optimiza preventiv pentru un scenariu care poate nu vine niciodata.
"React/Vue/Angular e standard in industrie."
Standard in industrie nu inseamna potrivit pentru fiecare proiect. O aplicatie interna cu 5 pagini nu are nevoie de React. Un site de prezentare nu are nevoie de Angular. Alege unealta potrivita, nu unealta populara.
"Microserviciile sunt viitorul."
Microserviciile sunt solutia pentru o problema specifica: echipe mari pe acelasi produs. Daca nu ai problema aia, ai doar costul si complexitatea, fara beneficiul.
Intrebari frecvente
Ce stack tehnic folositi pentru aplicatii web?
Node.js + Express pentru backend, PostgreSQL pentru baza de date, vanilla JavaScript sau Next.js pe frontend, PM2 pentru process management. Hosting pe VPS-uri dedicate (Hetzner). Acest stack acopera 90% din proiectele noastre — de la SaaS-uri cu abonamente pana la platforme de cursuri.
De ce Node.js si nu Python sau PHP?
Un singur limbaj (JavaScript) pe frontend si backend inseamna mai putina complexitate, mai putin context switching si un singur ecosistem de pachete. Express e matur, simplu si fara "magie" — un junior intelege codul in ore, nu saptamani. Python e excelent pentru data science si AI, dar pentru web apps CRUD, Node.js e mai rapid de livrat.
De ce PostgreSQL si nu MongoDB?
Datele de business sunt relationale — clientii au comenzi, comenzile au produse, produsele au categorii. Modelul relational exista de 50 de ani pentru ca functioneaza. PostgreSQL ofera si JSON columns cand ai nevoie de flexibilitate, deci ai ce e mai bun din ambele lumi. MongoDB introduce complexitate la join-uri si consistenta datelor fara un beneficiu real pentru majoritatea aplicatiilor.
Ce e un monolit si de ce e mai bun decat microserviciile pentru proiecte mici?
Un monolit e o aplicatie care ruleaza ca un singur proces. Toate modulele (auth, plati, continut) sunt in acelasi cod, dar organizate curat pe foldere. E mai simplu de dezvoltat, testat, deployat si debugat. Microserviciile au sens la 50+ developeri pe acelasi produs. Sub acel prag, adauga complexitate fara beneficiu.
Cat costa mentenanta stack-ului tehnic?
Hosting pe VPS: 15-40 EUR/luna. Domeniu si SSL: 15-30 EUR/an. Monitorizare si backup: incluse in hosting. Mentenanta cod (bugfix-uri, actualizari securitate): 200-500 EUR/luna, in functie de complexitatea aplicatiei. Un stack simplu costa mai putin de intretinut — mai putine dependinte inseamna mai putine lucruri care se strica.
Pot schimba stack-ul tehnic dupa lansare?
Tehnic, da. Practic, e costisitor. O migrare de stack inseamna rescrierea aplicatiei, nu o simpla actualizare. De aceea alegerea initiala conteaza. Daca stack-ul initial e bine ales si codul e modular, poti schimba componente individual (de ex. frontend-ul) fara sa rescrii totul.
Urmatorul pas
Tehnologia nu e scopul. E unealta. Alege unealta potrivita pentru treaba care trebuie facuta, nu unealta care arata cel mai bine pe CV.
Ai un proiect si nu stii ce stack tehnic e potrivit? Descrie-l in 10 randuri si iti recomandam abordarea corecta — cu tehnologii, cost si timeline.
Trimite un mesaj prin formularul de contact
Fara obligatii. Daca alt stack e mai potrivit, iti spunem.