Hogyan kell kezelni a környezetre jellemző beállításokat a JavaScript alkalmazásaiban

A modern internetes alkalmazások… bonyolultak.

Manapság sok webes alkalmazás a React, a Angular, a Vue, az Ember és mások segítségével épül fel. Ezek a modern ügyféloldali megjelenített alkalmazások gyakran web-API-kat hívnak meg, amelyeket külön szerveren tárolnak. Ez problémát okoz: hogyan állíthatja be az alkalmazását, hogy minden környezetben meghívja a megfelelő API URL-t?

Például, a fejlesztés során az API-t helyileg tárolhatja a localhost: 3000-en. A gyártás során az API tárolható más kiszolgálón az api.mycompany.com oldalon. Szüksége van az alkalmazásra, hogy felhívja a localhost: 3000 fejlesztést és az api.mycompany.com a gyártást. De hogyan?

Az alap URL csak egy példa a beállításokra, amelyek környezetenként változhatnak. Dönthet úgy, hogy környezeti szempontból más beállításokat is módosít teljesítmény-, biztonsági vagy naplózási célokra. Az alábbiakban szereplő néhány megközelítés alkalmazható ezekre az általános környezet-specifikus konfigurációkra is. De az egyszerűség kedvéért ez a bejegyzés az alap URL-ek környezetben történő konfigurálásának technikáira összpontosít.

Pár kérdéssel közzétettem egy felmérést a Twitter-en:

Kiderült, hogy számos módon lehet ezt kezelni. Sok ragyogó választ kaptam a tweet szálban. Az alábbiakban nyolc lehetőséget foglaltam össze. Megrendeltem ezeket a lehetőségeket (lazán) abban a sorrendben, hogy figyelembe vegyék őket. Tehát, ha siet, az elsőként fontolóra vehető lehetőségek vannak a tetején.

1. lehetőség: Állítsa be az API-t az alkalmazással

Egyszerű. Csak tárolja az alkalmazást és az API-t ugyanabból a webszerverből, így a relatív URL-ek mindenütt működnek. Ez elkerüli mind az alap URL-problémákat, mind a származási helyekkel kapcsolatos problémákat.

Mikor kell figyelembe venni:

  • Az Ön API-ját egyetlen alkalmazás fogyasztja.
  • Az API-t és az alkalmazást nem kell külön-külön méreteznie, így praktikus az ugyanazon a szerveren tárolás.

2. lehetőség: Környezet-specifikus építkezés

Ez a megközelítés tiszteletben tartja a fordítási idő maximumát:

"Soha ne csináljon futás közben azt, amit kezelni tud fordítási időben."

Ezzel a megközelítéssel általában egy folyamatos integrációs (CI) kiszolgálót használ az egyes környezetekhez létrehozott egyedi telepítések létrehozására és telepítésére. Ez egy erőteljes, biztonságos és sokoldalú megközelítés, de minden fejlesztőt megköveteli .env fájl létrehozásáról és karbantartásáról a számítógépen. Ez egy nagyszerű üzenet néhány trükkövel, amelyek ezt a fájdalmatlanná teszik.

Mikor kell figyelembe venni:

  • Kényelmesen konfigurálhatja a CI-kiszolgálót az összeállítási és telepítési folyamat automatizálásához a megbízhatóság biztosítása érdekében.
  • Jelentősen meg szeretné változtatni a gyártáshoz alkalmazott kódot, például el kell távolítania azt a kódot, amelyet teljesítmény vagy biztonsági okokból csak a nem gyártási környezetben használnak.
  • Örülök annak a kockázatnak, amely azzal jár, hogy eltérő kódot telepít a termeléshez, mint a fejlesztés és a minőségbiztosítás során használt kód.

3. lehetőség: Futásidejű konfiguráció

Ezzel a megközelítéssel az alkalmazást az egyes környezetekhez úgy konfigurálhatja, hogy hivatkozáskor hivatkozik a vonatkozó konfigurációs adatokra (szemben a fentiekben ismertetett összeépítéssel). Tehát a fenti megközelítéstől eltérően, ezzel a megközelítéssel ugyanazt a kódot alkalmazzák minden környezetben. Az indításkor átadott konfigurációs adatok testreszabják az alkalmazás viselkedését.

A környezeti konfigurációs adatok továbbítására néhány lehetséges módszer létezik:

  1. Parancssori konfiguráció - adja át a beállítást az alkalmazás indításakor.
  2. Környezetvédelmi konfigurációs fájl - Töltse fel az .env fájlt minden környezetben, és induláskor olvassa el tőle. Íme egy példa a létrehozás-reagál-alkalmazás-dokumentumokból, de ez a megközelítés minden JavaScript-alkalmazásra érvényes.

De hogyan kapja meg alkalmazásod ezt az információt? Van néhány módszer erre:

  1. Konfigurációs fájl - Írja be a konfigurációs adatokat egy különálló JavaScript fájlba az alkalmazás indításakor. Az alkalmazás képes importálni és elolvasni ezt a fájlt indításkor.
  2. Globális az index.html fájlban - Írja be a konfigurációs adatokat egy globális elemre az index.html fájlban az építési eszköz használatával. Itt ismét egy példa a létrehozás-reagál-alkalmazás dokumentumokból, de ez a megközelítés vonatkozik minden JavaScript-alkalmazásra.

Igaz, hogy ezek a megközelítések kissé megváltoztatják a kódot az indításkor, a megadott futási idő konfiguráció alapján. De különböznek a fenti 2. opciótól, mivel ugyanazt a kódot telepítik minden környezetre.

Mikor kell figyelembe venni:

  • Inkább ugyanazt a kódot telepíti minden környezetben.

4. lehetőség: Fordított proxy

Ezzel a megközelítéssel ugyanazt a relatív URL-t hívja meg minden környezetben. Hogyan működik? Nos, a front-end webszerver felelőssége, hogy minden környezetben továbbítsa a hívásokat a megfelelő API-ra. Ennek a megközelítésnek több előnye van:

  1. Az összes API-hívásban az Ön URL-je tiszta, relatív URL. Például / felhasználó.
  2. Az előtér-webkiszolgálót gyorsítótárrétegként konfigurálhatja a hozzáadott teljesítmény érdekében.
  3. Ez a megközelítés támogatja a háttérrendszer váltását azáltal, hogy egyszerűen átkonfigurálja a proxyt.

Mikor kell figyelembe venni:

  • Minden környezetben konfigurálhatja a webszervert
  • Érdekel egy gyorsítótárazási réteg bevezetése a felhasználói felület és az API között.
  • A front-end webszerver megbízhatóan és gyorsan továbbíthatja a hívásokat az API-kiszolgálóra. Ez a megközelítés teljesítményköltséget jelent, mivel a webszervernek továbbítania kell a kéréseket egy másik szerverhez.

Oldaljegyzet:

Miközben a proxykről beszélünk, egy másik proxy-megközelítés, amelyet érdemes megemlíteni, a proxy-köztes szoftver (ez egy teljesen más megközelítés, mint a fentebb tárgyalt fordított proxy).

A helyi gépen futó proxy-köztes szoftverrel a fejlesztés során a kérések egy meghatározott URL-re továbbítódnak. Például, ha Ön React fejlesztő, akkor a create-react-app beépített proxy támogatással rendelkezik. A Webpack proxy köztes szoftvert használja.

Itt található egy áttekintés a proxy-megközelítésről a React és az Express használatával.

Ugyanakkor: A proxy köztes szoftverek csak az alap URL problémát oldják meg a fejlesztésben. Tehát használja a postában szereplő többi technika egyikét más környezetek, például a minőségbiztosítás és a termelés kezelésére.

5. lehetőség: dokkoló

A Docker segítségével az UI-t és az API-t különálló tárolókként telepítheti, de létrehozhat egy „LAN” -ot, amely lehetővé teszi, hogy a tárolók úgy kommunikáljanak, mintha ugyanazon a hálózaton lennének. Ilyen módon az alap URL nem változik minden környezetben. A konténerek azonos környezetben működnek minden környezetben. És átadhatja a releváns környezeti változókat a konténerekbe minden környezetben. Nézze meg a Kubernetes vagy a Docker Swarm ezt a megközelítést.

Mikor kell figyelembe venni:

  • Ön már befektetett a Docker ökoszisztémába.

6. lehetőség: Környezeti szippantás

Ezzel a megközelítéssel kódot használ a jelenlegi környezet „szippantásához” typically, általában az URL megnézésével. Például, ha az URL http: // localhost, akkor tudja, hogy fejlesztés alatt áll.

Ennek a megközelítésnek az előnye az egyszerűség. A fejlesztőknek nem kell semmiféle konfigurálást elvégezniük a gépeken, és nem kell sem CI-kiszolgáló, sem webszerver-konfigurációval majmokkal.

Mikor kell figyelembe venni:

  • Van egy egyszerű alkalmazás, amely kis számú API-t hív fel.
  • Nincs CI-kiszolgálója.
  • Vállalati politikája megnehezíti vagy kivitelezhetetlen a fenti fenti lehetőségek megvalósításában.
  • Nem aggódik azok miatt, akik potenciálisan megtalálják az URL-eket a nem termelő környezetéhez. (Biztonsági okokból a nem gyártási környezetnek a vállalati LAN / VPN-n kívül egyébként nem szabad hozzáférhetőnek lennie).

7. lehetőség: Egyéni HTTP fejléc

Konfigurálja az elülső webkiszolgálót olyan egyedi HTTP-fejléc biztosítására, amely a környezet releváns ügyfél-URL-jét tartalmazza. Ennek a megközelítésnek az a hátránya, hogy alkalmazásának először HTTP-hívást kell kezdeményeznie erre az API-ra, hogy meghatározzák, hogy mi a vonatkozó alap-URL minden környezetben.

Mikor kell figyelembe venni:

  • Nem javaslom ezt a megközelítést, mivel az alkalmazásának megkövetelnie kell egy oda-vissza HTTP hívást, mielőtt ténylegesen megkezdi az adatok letöltését. Jobban szeretem a fenti megközelítések egyikét.

8. lehetőség: App Config végpont

Ezzel a megközelítéssel az alkalmazás ugyanazon az URL-en hívja ugyanazt az „alkalmazás-konfigurációs” API-t, minden környezetben. Az alkalmazás először hívja ezt az API-t. Az API-hívás visszaadja a vonatkozó alap-URL-t minden környezetben (valamint esetlegesen más környezet-specifikus beállításokat is). Ezzel a megközelítéssel potenciálisan átadhatja más vonatkozó környezet-specifikus konfigurációs adatokat.

Mikor kell figyelembe venni:

  • Én sem ajánlom ezt a megközelítést. Ez befolyásolja a betöltési időt, mivel a kezdeti HTTP-hívásnak a konfigurációs adatok lekérdezéséhez be kell fejeződnie, mielőtt az alkalmazás megkezdené a kívánt adatok visszakeresését. Ehelyett fontolja meg a fenti lehetőségek egyikét.

összefoglalás

Hozzon létre környezeti struktúrát CI-kiszolgálón keresztül, ha valódi környezeti testreszabásra van szüksége (a fenti # 2). Ha inkább ugyanazt a kódot telepíti minden környezetbe, akkor fontolja meg a futásidejű konfigurációt (a fenti # 3) vagy a fordított proxyt (a fenti # 4).

Boldog kódolás!

Van más módon is kezelni ezt? Kérjük, csipogjon be a hozzászólásokon keresztül.

A Cory House több tanfolyam szerzője a JavaScript, a React, a tiszta kód, a .NET és a Pluralsight témában. Fő tanácsadója a reactjsconsulting.com webhelyen, egy szoftverépítésznek, a Microsoft MVP-nek, és nemzetközi szinten képzi a szoftverfejlesztőket a front-end fejlesztési gyakorlatokkal kapcsolatban. Cory tweets a JavaScriptről és a front-end fejlesztésről a Twitter-en, mint @housecor.