Переход с Express.js на Функции Azure

  • Статья

Express.js — одна из самых популярных платформ Node.js для веб-разработчиков, которая идеально подходит для создания приложений, обслуживающих конечные точки API.

При переносе кода в бессерверную архитектуру рефакторинг конечных точек Express.js влияет на следующие аспекты:

  • ПО промежуточного слоя. Express.js располагает внушительной коллекцией ПО промежуточного слоя. Благодаря возможностям Функций Azure и Azure API Management многие модули ПО промежуточного слоя больше не требуются. Перед миграцией конечных точек убедитесь, что вы можете реплицировать или заменить любую логику, обрабатываемую основным ПО промежуточного слоя.

  • Различные API. Функции Azure и Express.js используют разный API для обработки запросов и ответов. В приведенном ниже примере подробно описаны необходимые изменения.

  • Маршрут по умолчанию. По умолчанию конечные точки Функций Azure предоставляются по маршруту api. Правила маршрутизации можно настроить с помощью routePrefix в файле host.json.

  • Конфигурация и соглашения. Приложение Функций использует файл function.json для определения HTTP-команд и политик безопасности и может настраивать входные и выходные данныефункции. По умолчанию имя папки, которая содержит файлы функции, определяет имя конечной точки, но это имя можно изменить с помощью свойства route в файле function.json.

Совет

Подробнее см. в интерактивном учебнике Рефакторинг API-интерфейсов Node.js и Express в бессерверные API с помощью Функций Azure.

Пример

Express.js

В следующем примере показана типичная конечная точка GET Express.js.

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

При отправке запроса GET в /hello возвращается ответ HTTP 200, содержащий Success. Если в конечной точке возникает ошибка, то ответом будет HTTP 500 со сведениями об ошибке.

Функции Azure

Функции Azure упорядочивают файлы конфигурации и кода, создавая по одной папке для каждой функции. По умолчанию имя папки определяет имя функции.

Например, функция с именем hello имеет папку со следующими файлами.

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

В примере ниже реализуется тот же результат, что и в приведенной выше конечной точке Express.js, но с помощью Функций 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}`
    };
  }
};

При переходе к Функциям вносятся следующие изменения:

  • Модуль. Код функции реализуется как модуль JavaScript.

  • Контекст и объект ответа. context позволяет взаимодействовать со средой выполнения Функции. Из контекста можно считывать данные запроса и задавать ответ функции. Синхронный код требует вызова context.done() версии 1.x для завершения выполнения, тогда как функции async версии 2.x+ обеспечивают неявное разрешение запроса.

  • Соглашение об именовании. Имя папки, используемое для хранения файлов Функций Azure, по умолчанию используется в качестве имени конечной точки (это правило можно переопределить в файле function.json).

  • Конфигурация. HTTP-команды задаются в файле function.json, например POST или PUT.

Следующий файл function.json содержит сведения о конфигурации для функции.

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

Благодаря определению get в массиве methods функция становится доступной для HTTP-запросов GET. Если вы хотите, чтобы ваш API принимал запросы на поддержку POST, можно также добавить post в массив.

Дальнейшие действия