Przechodzenie z Express.js na Azure Functions

Express.js jest jedną z najpopularniejszych platform Node.js dla deweloperów internetowych i pozostaje doskonałym wyborem do tworzenia aplikacji obsługujących punkty końcowe interfejsu API.

Podczas migracji kodu do architektury bezserwerowej refaktoryzacja Express.js punktów końcowych ma wpływ na następujące obszary:

  • Oprogramowanie pośredniczące: Express.js oferuje niezawodną kolekcję oprogramowania pośredniczącego. Wiele modułów oprogramowania pośredniczącego nie jest już wymaganych w świetle Azure Functions i możliwości usługi Azure API Management. Przed migracją punktów końcowych upewnij się, że można replikować lub zastępować dowolną logikę obsługiwaną przez podstawowe oprogramowanie pośredniczące.

  • Różne interfejsy API: interfejs API używany do przetwarzania żądań i odpowiedzi różni się między Azure Functions i Express.js. Poniższy przykład zawiera szczegółowe informacje o wymaganych zmianach.

  • Trasa domyślna: domyślnie Azure Functions punkty końcowe są widoczne w api trasie. Reguły routingu można konfigurować za pośrednictwem routePrefix pliku host.json.

  • Konfiguracja i konwencje: aplikacja usługi Functions używa pliku function.json do definiowania czasowników HTTP, definiowania zasad zabezpieczeń i może skonfigurować dane wejściowe i wyjściowe funkcji. Domyślnie nazwa folderu, który zawiera pliki funkcji definiuje nazwę punktu końcowego, ale można zmienić nazwę za pomocą route właściwości w pliku function.json .

Przykład

Express.js

W poniższym przykładzie przedstawiono typowy punkt końcowy 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}`);
  }
});

Po wysłaniu GET żądania do /helloelementu HTTP 200 zwracana jest odpowiedź zawierająca Success . Jeśli punkt końcowy napotka błąd, odpowiedź jest HTTP 500 ze szczegółami błędu.

Azure Functions

Azure Functions organizuje pliki konfiguracji i kodu w jednym folderze dla każdej funkcji. Domyślnie nazwa folderu określa nazwę funkcji.

Na przykład funkcja o nazwie hello ma folder z następującymi plikami.

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

Poniższy przykład implementuje ten sam wynik co powyższy punkt końcowy Express.js, ale z 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}`
    };
  }
};

Podczas przechodzenia do usługi Functions są wprowadzane następujące zmiany:

  • Moduł: Kod funkcji jest implementowany jako moduł JavaScript.

  • Obiekt kontekstu i odpowiedzi: umożliwia context komunikację ze środowiskiem uruchomieniowym funkcji. W kontekście można odczytać dane żądania i ustawić odpowiedź funkcji. Kod synchroniczny wymaga wywołania 1.x context.done() w celu ukończenia wykonywania, podczas gdy funkcje 2.x+ async rozpoznają żądanie niejawnie.

  • Konwencja nazewnictwa: nazwa folderu używana do przechowywania plików Azure Functions jest domyślnie używana jako nazwa punktu końcowego (można ją zastąpić w pliku function.json).

  • Konfiguracja: czasowniki HTTP są definiowane w pliku function.json , takim jak POST lub PUT.

Następujący plik function.json zawiera informacje o konfiguracji dla funkcji.

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

Definiując get w tablicy methods , funkcja jest dostępna dla żądań HTTP GET . Jeśli chcesz, aby interfejs API akceptował żądania pomocy technicznej POST , możesz również dodać post do tablicy.

Następne kroki