Cursul 2

Arhitecturi Web
# NT IE R #M VC #S PA # M IC R OS ER V IC ES # R E STA PI
Arhitectura “Multi tier”
IM PAR TI RE A U NE I A PLI CATI I PE NI VE LE
Arhitectura “Multi tier”
• Impartirea aplicatiei pe nivele fizice separate
• Fiecare nivel rezolva cate o problema
• Nivelele sunt strans cuplate
• Nivelele comunica intre ele liniar, de sus in jos
(nivelul k cu nivelul k+1 sau k-1)
 Arhitectura “3-tier”
• Cea mai des intalnita
• Nivelul de prezentare – Frontend
• Nivelul de logica - Backend
• Nivelul de date – Sistemul de
stocare (baze de date, fisiere,
cache, etc…)
Intrebare:
Pot cele 3 nivele (prezentare, logic, date) sa
existe pe acelasi mediu fizic?
Model View Controller
DE SI G N PAT T ER N PE NT R U W EB
Ce este MVC?
• Design pattern folosit de obicei pentru interfetele
cu utilizatorul (UI)
• Compus din 3 nivele logice (Model, View,
Controller)
• Nivelele comunica intre ele triangular, fiecare cu
fiecare
• Poate fi folosit atat pe backend, cat si pe frontend
sau chiar pentru amandoua concomitent
 Componente MVC
• Model – nivelul de date, business logic si reguli ale
aplicatiei. Considerat elementul critic in MVC
• View – nivelul de prezentare. Afiseaza informatiile
din model catre utilizator
• Controller – nivelul de legatura dintre model si
view. Acesta preia input din view si trimite mai
departe comenzi catre model.
• Flow:
• Utilizatorul interactioneaza cu view
• Interactiunea este preluata de controller si trimisa catre
model
• Modelul actualizeaza starea interna a aplicatiei si
modificarile se resimt in view
Intrebare:

Este MVC o implementare a 3-tier?

Diferenta dintre MVC si 3-tier
• 3-tier este o arhitectura web, MVC este un design
pattern
• 3-tier are separatie fizica intre nivele, MVC are
separatie logica (poate avea si fizica, dar nu este
obligatoriu)
• MVC poate fi inclus in nivele din 3-tier, de
exemplu, in Presentation Layer sau Logic Layer
sau chiar in ambele:
• Frontendul poate avea MVC ca si design pattern preferat
(Angular)
• Backendul poate avea MVC ca si design pattern preferat
(Java, C#, Django)

• Nivelele din 3-tier comunica liniar, de sus in jos.

Nivelele din MVC comunica triangular
Structura unui Frontend
ON E PAG E TO R U LE T HE M ALL?
 Frontendul modern
• Frontendul a evoluat mult in ultimii ani
• De la pagini web simple s-a ajuns la platforme
complexe si site-uri masive de e-commerce si
media (si nu numai - http://webverse.org/)
• Cele doua standarde de-facto pentru frontend sunt:
• MPA – multi page application
• SPA – single page application
Ce este MPA?
• MPA este frontendul clasic, compus din mai multe
pagini HTML
• Fiecare pagina este returnata de catre server, in urma
unei cereri HTTP
• Interactiunea cu frontendul rezulta in refresh, adica
printr-o noua resursa intoarsa de la server (aceeasi
pagina modificata, sau o noua pagina)
• Exemplu: https://www.amazon.com/
 Ce este SPA?
• SPA presupune un frontend realizat integral sub forma
unei aplicatii individuale, decuplate de backend
• Frontendul este procesat complet de catre browserul
utilizatorului
• Interactiunea cu frontendul rezulta in cereri AJAX,
adica cereri HTTP asincrone transmise catre server
pentru schimb de informatii (ex: JSON)
• Exemplu: https://mail.google.com/
SPA vs MPA
 SPA vs MPA
• SPA este mai rapid si mai • MPA permite realizarea SEO-
responsive, datorita randarii ului mult mai usor si performant
locale in browser si a cererilor
AJAX care nu blocheaza pagina • MPA nu sunt atat de vulnerabile
la atacuri cross-site scripting
• Management mai bun al starii
interne, utilizand cache-ul • Potential de scalabilitate mai
browserului mare, deoarece pot fi cuplate
oricand mai multe pagini web
• Mai usor de dezvoltat si
intretinut
Structura unui Backend
MO R E IS L E SS ?
 Backendul modern
• Acum 10-15 ani, backendurile returnau pagini web
• Acum, acestea executa procese complexe, comunica cu
sisteme diverse si inglobeaza majoritatea business logicului
din orice aplicatie moderna
• Cel mai intalnit tip de backend este REST Api-ul, adica un
blackbox care primeste informatii, le proceseaza si intoarce
alte informatii peste cereri HTTP
• Structura backendurilor variaza mult, insa cele mai intalnite
doua structuri sunt:
• Monolit
• Microservicii
Backendul modern
 Backendul Monolit
• Natura unitara
• Toate functionalitatile sunt implementate in cadrul
aceluias program
• Chiar daca business logic-ul nu este spart in module
fizice, un monolit poate fi modularizat din punct de
vedere logic
• Comunicatia intre modulele logice se realizeaza in-
process, prin apeluri de functii sau prin evenimente
 Microservicii
• Natura distribuita
• Functionalitatile disjuncte sunt implementate in module
fizice separate
• Fiecare microserviciu trebuie sa fie capabil sa execute
actiunile pentru care a fost facut cu ajutor minimal din
exterior (compact si self-contained)
• Microserviciile comunica intre ele prin mai multe moduri:
• Sincron - REST- cereri HTTP
• Asincron – cozi de mesaje (RabbitMQ, Kafka)
Intrebare:

Cat de mic trebuie sa fie un Microserviciu?

 Monolit vs Microservicii
• Monolitul este mai usor de dezvoltat pentru • Chiar daca un monolit poate avea modularizare
incepatori buna, microserviciile duc modularizarea la un
alt nivel, prin separare clara a problemelor de
• Monolitul este indicat pentru aplicatii mici, business in servicii decuplate fizic
fara prea multa complexitate
• Fiecare microserviciu poate fi dezvoltat in orice
• Monolitul foloseste acelasi limbaj de tehnologie
programare pentru fiecare modul al sau (un • Usor de scalat, deoarece microserviciile critice
singur framework/proiect) pot fi scalate individual
• Mai greu de scalat, deoarece toata aplicatia • Deployment superior, deoarece fiecare
trebuie replicata integral microserviciu este deployat individual

• Deploymentul are de suferit deoarece toata • Mult mai greu de dezvoltat, deoarece este
aplicatia trebuie recompilata si rerulata de nevoie de analiza in ansamblu cu privire la:
fiecare data cand se face cate o modificare • Obiectivul fiecarui serviciu
• Comunicarea dintre servicii
Cum alegem?
Practici indicate pentru
dezvoltarea web
G E NT LE WE B ’ S C O DE
Etica de munca
• O aplicatie sau un proiect nu
inseamna numai cod scris
• Planificarea si analiza joaca
un rol crucial, chiar mai
important decat dezvoltarea
efectiva
• “Failing to plan is planning to
fail”
Modularizare optima
• Este bine ca fiecare proiect sa aiba functionalitatile
exprimate cat mai clar si concis
• Cu cat exista un grad de modularizare mai mare, cu
atat scade riscul de cod buggy & messy.
• Modularizarea optima atrage cu sine dezvoltarea semi-
decuplata a fiecarei functionalitati
• Modularizarea permite si lucrul in echipa mult mai usor
Testare proactiva
• Incercati sa testati cat
mai des codul scris
• Este bine sa folositi atat
unit testing cat si
manual testing
• Postman pt. backend
• In browser direct pt.
frontend
Folositi GIT si Docker

good