Ce este un server web
O componentă importantă în arhitectura unei aplicații web este serverul, pentru că aplicațiile web sunt puse la dispoziția utilizatorilor prin intermediul protocolului denumit HTTP.
Da, ceea ce vezi la începutul fiecărui URL este protocolul prin care urmează să fie apelată resursa respectivă. De-asta în momentul în care încerci să accesezi o pagină web o să pui înaintea URL-ului protocolul HTTP.
Același lucru se va întâmpla și dacă vrei să comunici cu o resursă folosind protocolul SSH, vei pune ssh: înaintea URL-ului resursei respective.
Faptul că aplicațiile web sunt servite dintr-un punct centralizat, anume server-ul web, le deosebește de alte tipuri de aplicații, cum ar fi cele desktop sau mobile, unde codul ajunge să fie stocat pe mașina locală, adică pe PC-ul sau telefonul tău propriu.
Și atunci avem nevoie de o locație unde să stocăm fișierele aplicațiilor noastre web, pentru a putea fi accesate de alți oameni prin intermediul HTTP.
Sau mai simplu spus, internet, deși nu e obligatoriu ca o aplicație web să fie expusă public pe internet.
Și atunci serverul web nu este altceva decât un software care știe să prelucreze și să onoreze cereri (requests) HTTP.
Deși așa cum spuneam la început, serverele web sunt componente vitale în arhitectura unei aplicații, serverele web moderne sunt de asemenea și extrem de complexe și capabile, făcând munca inginerilor software mai ușoară decât era în trecut, prin întărirea securității împotriva vulnerabilităților cunoscute, introducerea unor funcționalități precum middlewares (interceptori).
Deși serverele web moderne oferă securitate mult mai solidă decât în trecut, există totuși și vulnerabilități de care noi, ca și ingineri trebuie să fim conștienți și să știm cum să ne păzim. În C# Masterclass discutăm mai detaliat despre aceste vulnerabilități și vedem care sunt tehnicile prin care putem să ne protejăm într-o aplicație ASP .NET MVC.
Un interceptor, sau middleware ne oferă posibilitatea de a captura și manipula o cerere (request) înainte ca ea să părăsească sau să lovească în codul aplicației pe care server-ul web o găzduiește. Astfel că putem loga activitatea, analiza metrice etc.
Dacă vrei, middleware e ca un fel de ofițer de la vamă. Indiferent că vrei să ieși sau să intri în țară, vei fi nevoit să treci pe la vamă unde ți se vor cere actele de identitate.
Server web vs. back-end
Nu face confuzie între serverul web și serverul (back-end-ul) aplicației tale.
Serverul web e cel care interceptează cererile HTTP și deleagă mai departe accesul la fișierele aplicației tale în funcție de ruta specificată (/index, /contact, /about, /api/products etc.).
Dacă nu există nicio aplicație/pagină web care să onoreze o rută anume, server-ul va întoarce răspunsul cu codul de status 404 - Not Found.
În cazul ăsta nicio linie de cod din aplicația sau pagina ta web nu a fost atinsă, totul e gestionat de server-ul web direct.
Serverul aplicației tale se numește “application server” sau back-end, sau server de aplicație și se află în interiorul serverului web.
După ce serverul web a stabilit că, de exemplu, ruta /api/products e o rută validă pentru serverul aplicației tale, el deleagă cererea la serverul aplicației.
De multe ori când vorbim de backend, server-ul web e ignorat, dar el reprezintă scheletul, fundația fără de care aplicația ta web nu ar putea funcționa, asta dacă nu cumva aplicația ta implementează și toate funcționalitățile de care ți-am povestit că un server web e capabil.
Dar noi ca programatori nu vrem să facem asta, vrem să decuplăm și să refolosim componentele aplicațiilor pe măsură ce tehnologia evoluează, pentru a putea accelera procesul de dezvoltare, elimina potențialele probleme și a ne concentra pe logica de business a aplicației pe care o dezvoltăm.
Tipuri de conținut servite de un server web
Serverele web pot servi 2 tipuri de conținut:
- Static
- Dinamic
În cazul conținutului static, serverul web dă mai departe fișierele exact așa cum sunt stocate ele acolo, fișiere al căror cod a fost scris linie cu linie de un programator.
Site-urile statice cu rol doar de prezentare așa funcționează, întrucât ele nu au un backend sau o bază de date.
Adică în momentul în care prin HTTP apare o cerere de tip GET, server-ul web returnează fișierul HTML pentru ruta respectivă.
Nu există niciun fel de altă procesare pe care serverul în sine o face, codul returnat către client, adică de exemplu browser-ul persoanei care încearcă să acceseze site-ul, e același pe care l-a scris dezvoltatorul.
În schimb, în cazul conținutului dinamic, serverul web va delega cererea la serverul aplicației tale, care va procesa și va întoarce fie fișiere de transmitere a datelor (cum ar fi json), fie fișiere HTML generate de el însuși pe baza parametrilor din cerere și a datelor din baza de date.
Deci în cazul ăsta, fișierele nu mai sunt trimise așa cum se regăsesc pe server, ci sunt procesate și generate de server însuși, de-aici și denumirea de “dinamic”.
Abordarea asta face ca aplicațiile web să fie mai performante, întrucât toată procesarea este făcută pe server, clientul (sau browser-ul) trebuie doar sa randeze pe ecran componentele HTML și stilizarea aferentă.
De asemenea tehnica descrisă anterior pentru generarea conținutului și care poartă denumirea de server side rendering sau SSR nu e singura care se folosește în dezvoltarea de aplicații web, mai sunt și altele cum ar fi SSG sau static site generation și CSR sau client side rendering care prezintă anumite diferențe față de server side rendering.
Dar despre asta cu altă ocazie.
Uite câteva exemple de servere web mai cunoscute, ca să știi pe viitor la ce se referă dacă le auzi numele:
- nginx
- kestrel (ASP .NET Core)
- IIS (Internet Information Services)
- Apache Tomcat (Java)
Cam atât pentru azi, ne auzim data viitoare.
