Passaggio da Express.js a Funzioni di Azure

Express.js è uno dei framework di Node.js più diffusi per gli sviluppatori Web e rimane una scelta eccellente per la creazione di app che servono endpoint API.

Quando si esegue la migrazione del codice a un'architettura serverless, il refactoring Express.js endpoint influisce sulle aree seguenti:

  • Middleware: Express.js offre una raccolta affidabile di middleware. Molti moduli middleware non sono più necessari alla luce delle Funzioni di Azure e delle funzionalità di Azure Gestione API. Assicurarsi di poter replicare o sostituire qualsiasi logica gestita dal middleware essenziale prima della migrazione degli endpoint.

  • API diverse: l'API usata per elaborare entrambe le richieste e le risposte differisce tra Funzioni di Azure e Express.js. Nell'esempio seguente vengono dettagliate le modifiche necessarie.

  • Route predefinita: per impostazione predefinita, gli endpoint Funzioni di Azure vengono esposti nella api route. Le regole di routing sono configurabili tramiteroutePrefix il file host.json.

  • Configurazione e convenzioni: un'app Funzioni usa il file function.json per definire verbi HTTP, definire i criteri di sicurezza e configurare l'input e l'output della funzione. Per impostazione predefinita, il nome della cartella contenente i file di funzione definisce il nome dell'endpoint, ma è possibile modificare il nome tramite la route proprietà nel file function.json .

Suggerimento

Per altre informazioni, vedere l'esercitazione interattiva Refactor Node.js e le API Express alle API serverless con Funzioni di Azure.

Esempio

Express.js

Nell'esempio seguente viene illustrato un tipico endpoint di Express.js 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}`);
  }
});

Quando viene inviata una richiesta a /hello, viene restituita una GETHTTP 200 risposta contenenteSuccess. Se l'endpoint rileva un errore, la risposta è un HTTP 500 oggetto con i dettagli dell'errore.

Funzioni di Azure

Funzioni di Azure organizza i file di configurazione e codice in una singola cartella per ogni funzione. Per impostazione predefinita, il nome della cartella determina il nome della funzione.

Ad esempio, una funzione denominata hello ha una cartella con i file seguenti.

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

Nell'esempio seguente viene implementato lo stesso risultato dell'endpoint di Express.js precedente, ma con Funzioni di Azure.

// 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}`
    };
  }
};

Quando si passa a Funzioni, vengono apportate le modifiche seguenti:

  • Modulo: Il codice della funzione viene implementato come modulo JavaScript.

  • Oggetto Contesto e risposta: context consente di comunicare con il runtime della funzione. Dal contesto è possibile leggere i dati delle richieste e impostare la risposta della funzione. Il codice sincrono richiede di chiamare 1.x per completare l'esecuzione, mentre le funzioni 2.x context.done() + async risolvono la richiesta in modo implicito.

  • Convenzione di denominazione: il nome della cartella usato per contenere i file di Funzioni di Azure viene usato come nome dell'endpoint per impostazione predefinita (questo può essere sottoposto a override nella funzione.json).

  • Configurazione: definire i verbi HTTP nel file function.json , POST ad esempio o PUT.

Il file function.json seguente contiene informazioni di configurazione per la funzione.

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

Definendo get nella methods matrice, la funzione è disponibile per le richieste HTTP GET . Se si vuole accettare le richieste di supporto POST , è anche possibile aggiungere post alla matrice.

Passaggi successivi