Mudar de Express.js para Funções do Azure

  • Artigo

Express.js é uma das arquiteturas de Node.js mais populares para programadores Web e continua a ser uma excelente opção para criar aplicações que servem pontos finais de API.

Ao migrar código para uma arquitetura sem servidor, refatorizar Express.js pontos finais afeta as seguintes áreas:

  • Middleware: Express.js apresenta uma coleção robusta de middleware. Muitos módulos de middleware já não são necessários à luz das capacidades de Funções do Azure e Gestão de API do Azure. Certifique-se de que pode replicar ou substituir qualquer lógica processada pelo middleware essencial antes de migrar pontos finais.

  • APIs diferentes: a API utilizada para processar pedidos e respostas difere entre Funções do Azure e Express.js. O exemplo seguinte detalha as alterações necessárias.

  • Rota predefinida: por predefinição, Funções do Azure pontos finais são expostos na api rota. As regras de encaminhamento são configuráveis através routePrefix do ficheiro host.json.

  • Configuração e convenções: uma aplicação de Funções utiliza o ficheiro function.json para definir verbos HTTP, definir políticas de segurança e pode configurar a entrada e a saída da função. Por predefinição, o nome da pasta que contém os ficheiros de função define o nome do ponto final, mas pode alterar o nome através da route propriedade no ficheiro function.json .

Dica

Saiba mais através do tutorial interativo Refatorizar Node.js e APIs Express para APIs sem servidor com Funções do Azure.

Exemplo

Express.js

O exemplo seguinte mostra um ponto final de Express.js GET típico.

// 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 um GET pedido é enviado para /helloo , é devolvida uma HTTP 200 resposta que Success contém. Se o ponto final encontrar um erro, a resposta será apresentada HTTP 500 com os detalhes do erro.

Funções do Azure

Funções do Azure organiza ficheiros de configuração e código numa única pasta para cada função. Por predefinição, o nome da pasta dita o nome da função.

Por exemplo, uma função com o nome hello tem uma pasta com os seguintes ficheiros.

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

O exemplo seguinte implementa o mesmo resultado que o ponto final Express.js acima, mas com Funções do 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}`
    };
  }
};

Ao mover para Funções, são efetuadas as seguintes alterações:

  • Módulo: O código de função é implementado como um módulo JavaScript.

  • Objeto de contexto e resposta: context permite-lhe comunicar com o runtime da Função. A partir do contexto, pode ler os dados do pedido e definir a resposta da função. O código síncrono requer que chame 1.x context.done() para concluir a execução, enquanto as funções 2.x+ async resolvem o pedido implicitamente.

  • Convenção de nomenclatura: o nome da pasta utilizado para conter os ficheiros Funções do Azure é utilizado como o nome do ponto final por predefinição (pode ser substituído no ficheiro function.json).

  • Configuração: define os verbos HTTP no ficheiro function.json , como POST ou PUT.

O seguinte ficheiro function.json contém informações de configuração para a função.

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

Ao definir get na methods matriz, a função está disponível para pedidos HTTP GET . Se quiser que a sua API aceite pedidos de suporte POST , também pode adicionar post à matriz.

Passos seguintes