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średnictwemroutePrefix
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 .
Porada
Dowiedz się więcej za pomocą interaktywnego samouczka Refaktoryzacja interfejsów API Node.js i Express do bezserwerowych interfejsów API za pomocą Azure Functions.
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 /hello
elementu 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.xcontext.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
lubPUT
.
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
- Dowiedz się więcej na temat interaktywnego samouczka Refaktoryzacja interfejsów API Node.js i Express do bezserwerowych interfejsów API przy użyciu Azure Functions