Cum se scrie Middleware
Vă întrebați vreodată ce se întâmplă în toate middleware-urile Express.js pe care le adăugați la aplicația dvs. web? De fapt, este destul de impresionant ce fel de funcționalitate puteți adăuga la aplicațiile dvs. cu o singură linie de cod sau câteva:
Ultimele trei linii de mai sus tratează destul de puțin funcționalitatea aplicației web pentru noi. Primul apel app.use () spune Express unde se află fișierele noastre statice și cum să le expunem, middleware-ul cookieParser („secret”) gestionează toate analizele cookie-urilor (cu criptare), iar ultimul gzip comprimă automat toate HTTP-urile noastre datele corpului. Nu este rău pentru doar trei linii de cod.
Aceste middleware sunt destul de tipice în aplicația dvs. web medie, dar puteți găsi unele care fac mai mult decât simpla compresie de date standard sau analiza cookie-urilor. Luați aceste exemple, de exemplu:
- cască: ajută la securizarea aplicației dvs. prin setarea diferitelor antete HTTP
- express-simple-cdn: utilizați cu ușurință un CDN pentru activele statice
- join-io: Alăturați fișierele din mers pentru a reduce numărul de solicitări HTTP
- pașaport: adaugă autentificarea utilizatorului la rutele selectate
Iată o listă mult mai largă de middleware pe care ați putea dori să o folosiți.
Acum că ați văzut câteva exemple, iată aproape tot ce puteți face cu el:
- Executați orice cod, inclusiv cod asincron
- Efectuați modificări sau adăugiri la obiectele de solicitare și răspuns
- Încheiați ciclul de solicitare-răspuns
- Apelați următorul middleware din stivă
Cu posibilitățile nesfârșite, sunt sigur că aveți câteva idei proprii pe care ați dori să le creați, așa că în restul acestui articol vă voi arăta cum să vă scrieți propriul middleware. Există câteva tipuri diferite de middleware pe care le puteți scrie (aplicație, router, gestionarea erorilor etc.), dar în acest articol ne vom concentra doar la nivelul aplicației.
Cele elementare
Middleware poate fi gândit aproape ca și cum ar fi un traseu Express. Aceștia iau aceiași parametri și totul, dar spre deosebire de rutele normale, nu vi se cere să furnizați o cale URL pentru middleware. Cele mai mari două diferențe sunt modul în care este tratată calea și când este apelată.
Calea furnizată este tratată ca un prefix, deci dacă ați avut ceva de genul app.use ('/ api',.), atunci middleware-ul dvs. va rula dacă/api este apelat și dacă/api/users este apelat. Acest lucru este diferit de traseele în care calea trebuie să fie o potrivire exactă.
Calea URL-ului poate fi omisă din apelul app.use () dacă doriți ca codul dvs. să ruleze pentru toate cererile, altfel puteți specifica o cale și să vă rulați codul numai atunci când ruta respectivă (și toate subrutele sale) este solicitat. De exemplu, acest lucru ar putea fi util pentru adăugarea autentificării doar la câteva rute date.
Un middleware simplu ar putea arăta astfel:
Întrucât un gestionar de traseu arată astfel:
Vedea? Practic sunt același lucru, așa că scrierea acestor funcții ar trebui să vă fie destul de familiară.
Parametrii utilizați sunt:
- cerere: un obiect care conține toate informațiile relevante despre cerere. Aceasta poate fi orice, de la adresa URL solicitată către corpul unei cereri POST la adresa IP a utilizatorului.
- res: Acesta este obiectul de răspuns, care este utilizat pentru a trimite date înapoi utilizatorului pentru cererea dată. Puteți utiliza acest lucru pentru a trimite înapoi un cod de răspuns HTTP 404 sau pentru a trimite înapoi HTML redat prin res.render () .
- următor: Și, în sfârșit, următorul parametru este un callback pentru a spune Express când middleware-ul nostru a terminat. Dacă faceți IO (cum ar fi apeluri la baze de date) sau calcule grele, atunci va trebui probabil să faceți funcția asincronă pentru a preveni blocarea firului principal de execuție, caz în care va trebui să utilizați următorul .