Kimenni enni és megérteni az Express.js alapjait

Kimenni enni és megérteni az Express.js alapjait

Ha valaha is ellátogatott egy ülős étterembe, akkor megértheti az Express alapjait. De ha épp most kezded el az első Node.js háttérkép felépítését ... akkor rögös útra kelhetsz.

Igen - minden bizonnyal könnyebb megtanulni a Node-ot, ha van tapasztalata a JavaScript-ről. De a kihívások, amelyekkel szembe kell néznie a háttérépítés során, teljesen mások, mint azok, amelyekkel a Java felületének használata során szembesül.

Amikor megtanultam a Node-ot, a kemény utat választottam. Újra és újra tanulmányoztam az e-könyveket, az írott oktatóanyagokat és a videókat, míg végül megértettem, miért csinálom, amit csinálok.

Van egy könnyebb módszer. Egy éttermi hasonlattal fogom elmagyarázni az első Express alkalmazás négy kulcsfontosságú részét. Az Express.js egy népszerű keretrendszer a kód rendezéséhez, és minden kezdő számára ajánlom. Egy pillanat alatt elmagyarázom tovább.

Itt van a négy kulcsfontosságú rész, amelyekre kitérünk:

  1. A szükséges állítások
  2. Középprogram
  3. útvonalválasztás
  4. App.listen () / A szerver indítása

Ebben a hasonlatban Ön egy étteremtulajdonos, aki általános menedzsert szeretne felvenni - az a személy, aki létrehozza az összes folyamatot és igazgatja a helyet, hogy zökkenőmentesen működjön, és az ügyfelek boldogan távozzanak.

Itt van a következő előnézet:

A végére megérti az alap Express alkalmazás minden részének funkcionalitását.

1. lépés: A vezető felvétele (kimutatások szükségesek)

Ebben a példában Ön az étterem tulajdonosa. És fel kell vennie egy szakértőt az új étterem napi működésének lebonyolításához. Te biztosan nem vagy szakértő, és nem hagyhatod a pincérnőnek és a konyhának, hogy rájöjj.

Ha hatékony és biztonságos éttermet szeretne működtetni, akkor szüksége van valakire, aki maximális hatékonysággal tartja munkáját. Az Express az új menedzser.

Az első rész elég egyértelmű. Mint bármely más NPM csomagot, meg kell NPM telepíteni kifejezett modult majd egy előírják nyilatkozatot betölteni a modult.

Sok más NPM csomagtól eltérően ezt a sort is használnia kell:

const app = express();

Ennek oka az, hogy változóra van szükség az új Express alkalmazás tárolásához. Az Express nem a Node alapértelmezett része.

2. lépés: döntések meghozatala az étteremben (köztes szoftver)

Tegyünk egy lépést vissza ide. Melyek az éttermekben megszokott rutinok? Három van, amelyek azonnal a fejembe ugranak:

  1. Új ügyfelek befogadása
  2. Élelmiszer rendelések elfogadása
  3. A csekk bemutatása az étkezés végén

Mindegyikhez tartozik egy sor ellenőrzés, amelyet futtatnia kell a művelet végrehajtása előtt. Például, mielőtt leültetné az ügyfeleket, tudnia kell:

  1. Inget és cipőt (és nadrágot) viselnek? Ellenkező esetben nem ülhetnek le.
  2. Ha a bárban akarnak ülni, akkor 21 évesek (ha Ön az Egyesült Államokban tartózkodik)?

Ez nem egy tengerparti bár! Hasonlóképpen, a kódban érvényesítenie kell, hogy a kérelmeknek vannak bizonyos feltételei, mielőtt folytathatnák. Például, ha egy személy megpróbál bejelentkezni a webhelyére:

  1. Van fiókjuk?
  2. Helyes jelszót adtak meg?

Itt jön létre a köztes szoftver fogalma. A köztes szoftver funkciói lehetővé teszik a beérkező kérések végrehajtását és azok módosítását, mielőtt válaszokat küldenének.

Éttermében egy sor szabályra van szüksége annak eldöntésére, hogy be kell-e ülnie a bejövő embereket vagy sem. Tegyük fel, hogy egy pár lép be az ajtódon. Egy szabály van, mielőtt asztalt ad nekik: inget és cipőt viselnek?

Először az app.use () paranccsal indul. Ez azt jelenti, hogy ezek egyszerűen szabályok, amelyeket alkalmazni kell a következő útvonalakon. Ezek nem GET, POST, PUT vagy DELETE.

A 4. sorban egy névtelen függvény van, a req, res és a következő paraméterekkel. A kódblokk alkalmazásában csak a kérést (igény) vizsgálja meg, hogy van-e benne ing és cipő.

A következő () függvényt is használnia kell a végén, mert itt egyszerűen érvényesíti a ruházatot. Később az útvonalakon lehetővé teszi a vendégek számára, hogy tényleges asztalt kapjanak.

Az 5. és 6. sorban ellenőrizze, hogy van-e inge és cipője.

És a 7–9. Sorban csak akkor folytatja, ha mindkettőjük megvan.

A fenti kódblokkból hiányzik egy fontos dolog: egy útvonal . Ez az a speciális karakterlánc, amelyet a kérelem tartalmaz. És mivel hiányzik belőle egy útvonal, minden egyes kérésre fut.

El tudod képzelni? Amikor az ügyfelek beléptek az étterembe… ételt rendeltek ... kérték az ellenőrzést ... az alkalmazottak kénytelenek lennének fel és le nézni rájuk, hogy megbizonyosodjanak róla, hogy fel vannak-e öltözve! Ez egy gyors módja a vállalkozás megszüntetésének.

Tehát a fenti példában megváltoztatjuk a 4. sort. Most csak akkor futtatjuk ezt a kódot, amikor a felhasználó a '/ table' útvonalon kéri.

A teljes magyarázat:

3. lépés: Közös rutinok végrehajtása (útválasztás)

Folytassuk az ülési példával. Eddig csak azt tudjuk tudni, hogyan kell érvényesíteni, hogy valakit le kell-e ültetni vagy sem. De valójában nem tudjuk, hogyan lehet őket egy asztalhoz vezetni és leültetni.

Ekkor jönnek be az útvonalak . Az útvonalak lehetővé teszik számunkra, hogy az útvonal alapján írjunk le konkrét műveleteket . A lehetőségek: GET, POST, PUT és DELETE, de egyelőre a GET-re és a POST-ra koncentrálunk.

Egy étterem kapcsán létre kell hoznunk egy GET kérést annak érdekében, hogy kiválasszunk egy adott asztalt és le tudjuk ültetni a vendégeket. A GET nem módosítja és nem egészíti ki az adatbázist. Csak konkrét paraméterek alapján kapnak információt.

Ebben az esetben tegyük fel, hogy létre kell hoznia egy eljárást a két tagú párt ülésére. A 2. szám az ügyfél kérésére érkezett.

Oké, mielőtt elmagyarázom: Igen, ez csak a végén küld üzenetet. Valójában még nem talált konkrét asztalt az ügyfél számára. Szükségem lenne egy tömbre keresni egy nyitott táblázatot, inkább egy háttértörténetet ... hogy ez az oktatóanyag hatályán kívül esik.

A 12. sorban meghatározzuk a táblázat megkeresésének eljárását, amikor egy vendég a '/ table' útvonalon kér . Csakúgy, mint a fenti köztes szoftver példában, rendelkezésre állnak kérés és válasz paraméterek is. Van paramétere , összege is. Ebben a példában ez kettő.

Valójában a 12. sorban szereplő funkció deklaráció után minden technikailag köztes szoftver, mivel módosítja a felhasználói kérést. Látni fogja a diagram végén.

A 13. sorban a kérelemobjektum paramétereiből férünk hozzá a párt létszámához . Ezt sehol nem jelentik be, mivel a kérést a felhasználó küldte, és nincs semmilyen kezelői kódunk. Tehát itt nézhet ki a kérés, ha ez egy igazi alkalmazás lenne:

req = { params: { amount: 2; }}

A 13-as vonal, a párt változó hozzáfér az összeg ingatlan a params tárgy a kérelmet .

Végül a 14. sorban visszaküldjük a választ az ügyfélnek: keressük a megfelelő méretű asztalt.

Ez egyszerre sok. Itt egy diagram:

3.5. Lépés: Az étterem hatékonyabbá tétele (router)

Most nyomon követheti a teljes utat a kéréstől a válaszig. Az alkalmazás méretének növekedésével azonban nem kívánja külön-külön kódolni az egyes útvonalak szabályait. Meg fogja találni, hogy egyes útvonalakon ugyanazok a szabályok vannak, ezért meg kell találnia a módját, hogy egy szabálykészletet több útvonalra is alkalmazzon.

Az ülőhelyeket tekintve akár a bárban, akár egy asztalnál ültetheti le ügyfeleit. Ezeknek közös szabályai vannak, mint az ing és cipő, de a bárban való üléshez a párt minden tagjának 21 évesnek kell lennie.

Ami az ügyfelek kiszolgálását illeti, egy kicsit más eljárást kell alkalmaznia az előétel, a főétel és a vacsora felszolgálására. De ennek a három útnak is rengeteg közös vonása van.

Itt jön be az útválasztó . Az útválasztó lehetővé teszi az útvonalak csoportosítását, hogy közös szabályokat hozzon létre.

Létre kell hoznunk köztes szoftvert, amely lefedi ezeket az eseteket. Egyelőre csak az üléstokokat fedem le, mivel felülírja a fenti kódot.

Itt van a teljes kódrészlet:

Minden részt külön-külön fogok lefedni.

A 4. sorban kijelentjük az útválasztónkat.

A 6. és 14. sorban most már az seat.Router.use () van az app.use () helyett annak jelzésére, hogy ez a köztes szoftver csak a sittingRouter útvonalakhoz kapcsolódik.

Végül a 21. sorban hozzáadunk még több köztes szoftvert annak bemutatásához, hogy minden sittingRouter útvonal '/ ülés' -vel kezdődik. Tehát, ha valaki helyet szeretne kérni a bárban, a teljes út a következő lesz: "/ ülés / bár". Ez kissé rendezetlennek érezheti magát, mivel számíthat arra, hogy meghatározza az útvonalat, amikor létrehozza az útválasztót a 4. sorban. Ez normális!

Itt van, hogy diagram formájában:

És amikor hozzáad egy GET útvonalat, az az utolsó utasítás fölé kerül, ahol útvonalakat rendel az útválasztóhoz.

4. lépés: Megnyitás az üzleti vállalkozások számára (portok)

Oké, utolsó rész. Eddig felvett egy menedzsert, meghatározta, mit kell tennie az ügyfélkérések elfogadása előtt, és meghatározta, mit kell kezdeni az adott ügyfélkérésekkel, amint bejönnek. Most csak meg kell határoznia annak a helynek a címét, ahol mindez megtörténik.

A szerver olyan portokkal rendelkezik, amelyek olyanok, mint maga az étterem címe.Mivel a szerver egyszerre sokféle éttermet (vagy szerveroldali szkriptet) képes kezelni, el kell mondania, hogy az egyes szkriptek hol futjanak.

A fenti példában a port 3000, és a számítógépen található. Tehát ha beírja:

//localhost:3000/

a böngészőbe, és a Node alkalmazást futtatja, a szerver tudja futtatni az adott parancsfájlt. Ebben az esetben, amint megadja az URL-t, naplózza az üzenetet a konzolon, és bármely útvonalát használhatja . Ha maga az étterem a teljes alkalmazásod, akkor az üzleti vállalkozás számára nyitva áll a 3000 címen.

Élvezted ezt? Adj neki egy tapsot, hogy mások is felfedezhessék. És ha értesítést szeretne kapni, amikor jövőben bemutatom az analógiákat használó oktatóanyagokat, regisztráljon itt: