Van Express.js naar Azure Functions

Express.js is een van de populairste Node.js frameworks voor webontwikkelaars en blijft een uitstekende keuze voor het bouwen van apps die API-eindpunten dienen.

Wanneer u code migreert naar een serverloze architectuur, heeft het herstructureren van Express.js eindpunten invloed op de volgende gebieden:

  • Middleware: Express.js beschikt over een robuuste verzameling middleware. Veel middlewaremodules zijn niet langer vereist in het licht van de mogelijkheden van Azure Functions en Azure API Management. Zorg ervoor dat u logica die wordt verwerkt door essentiële middleware kunt repliceren of vervangen voordat u eindpunten migreert.

  • Verschillende API's: de API die wordt gebruikt voor het verwerken van zowel aanvragen als antwoorden verschilt tussen Azure Functions en Express.js. In het volgende voorbeeld worden de vereiste wijzigingen weergegeven.

  • Standaardroute: standaard worden Azure Functions eindpunten weergegeven onder de api route. Routeringsregels kunnen worden geconfigureerd via routePrefix in het bestand host.json.

  • Configuratie en conventies: een Functions-app gebruikt het bestand function.json om HTTP-woorden te definiëren, beveiligingsbeleid te definiëren en de invoer en uitvoer van de functie te configureren. Standaard definieert de mapnaam die de functiebestanden bevat de naam van het eindpunt, maar u kunt de naam wijzigen via de route eigenschap in het bestand function.json .

Voorbeeld

Express.js

In het volgende voorbeeld ziet u een typisch Express.js-eindpunt GET .

// server.js
app.get('/hello', (req, res) => {
  try {
    res.send("Success!");
  } catch(error) {
    const err = JSON.stringify(error);
    res.status(500).send(`Request error. ${err}`);
  }
});

Wanneer een GET aanvraag wordt verzonden naar /hello, wordt een HTTP 200 antwoord met Success geretourneerd. Als het eindpunt een fout tegenkomt, is het antwoord een HTTP 500 met de foutdetails.

Azure Functions

Azure Functions organiseert configuratie- en codebestanden in één map voor elke functie. Standaard bepaalt de naam van de map de naam van de functie.

Een functie met de naam hello heeft bijvoorbeeld een map met de volgende bestanden.

| - hello
|  - function.json
|  - index.js

In het volgende voorbeeld wordt hetzelfde resultaat geïmplementeerd als het bovenstaande Express.js-eindpunt, maar met Azure Functions.

// hello/index.js
module.exports = async function (context, req) {
  try {
    context.res = { body: "Success!" };
  } catch(error) {
    const err = JSON.stringify(error);
    context.res = {
      status: 500,
      body: `Request error. ${err}`
    };
  }
};

Wanneer u naar Functions gaat, worden de volgende wijzigingen aangebracht:

  • Module: De functiecode wordt geïmplementeerd als een JavaScript-module.

  • Context- en antwoordobject: met de context kunt u communiceren met de runtime van de functie. Vanuit de context kunt u aanvraaggegevens lezen en het antwoord van de functie instellen. Voor synchrone code moet u 1.x context.done() aanroepen om de uitvoering te voltooien, terwijl 2.x+ async -functies de aanvraag impliciet oplossen.

  • Naamconventie: de mapnaam die wordt gebruikt om de Azure Functions bestanden te bevatten, wordt standaard gebruikt als de naam van het eindpunt (dit kan worden overschreven in function.json).

  • Configuratie: u definieert de HTTP-woorden in het bestand function.json , zoals POST of PUT.

Het volgende function.json-bestand bevat configuratie-informatie voor de functie.

{
  "bindings": [
    {
      "authLevel": "function",
      "type": "httpTrigger",
      "direction": "in",
      "name": "req",
      "methods": ["get"]
    },
    {
      "type": "http",
      "direction": "out",
      "name": "res"
    }
  ]
}

Door in de methods matrix te definiërenget, is de functie beschikbaar voor HTTP-aanvragenGET. Als u wilt dat uw API ondersteuningsaanvragen POST accepteert, kunt u ook toevoegen post aan de matrix.

Volgende stappen