Mudando de Express.js para o Azure Functions

Express.js é uma das estruturas de Node.js mais populares para desenvolvedores Web e continua sendo uma excelente opção para criar aplicativos que atendem a pontos de extremidade de API.

Ao migrar o código para uma arquitetura sem servidor, a refatoração de pontos de extremidade Express.js afeta as seguintes áreas:

  • Middleware: Express.js apresenta uma coleção robusta de middleware. Muitos módulos de middleware não são mais necessários à luz dos recursos do Azure Functions e do Gerenciamento de API do Azure . Verifique se você pode replicar ou substituir qualquer lógica tratada pelo middleware essencial antes de migrar os pontos de extremidade.

  • APIs diferentes: a API usada para processar solicitações e respostas difere entre o Azure Functions e Express.js. O exemplo a seguir detalha as alterações necessárias.

  • Rota padrão: por padrão, os pontos de extremidade do Azure Functions são expostos sob a rota api. As regras de roteamento são configuráveis por meio routePrefix do arquivo host.json.

  • Configuração e convenções: um aplicativo do Functions usa o arquivo 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 padrão, o nome da pasta que contém os arquivos de função define o nome do ponto de extremidade, mas você pode alterar o nome por meio da route propriedade no arquivo function.json .

Dica

Saiba mais por meio do tutorial interativo Refatorar Node.js e AS APIs Expressas para APIs sem servidor com o Azure Functions.

Exemplo

Express.js

O exemplo a seguir mostra um endpoint 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 uma GET solicitação é enviada para /hello, uma HTTP 200 resposta que contém Success é retornada. Se o ponto de extremidade encontrar um erro, a resposta será um HTTP 500 com os detalhes do erro.

Azure Functions

O Azure Functions organiza a configuração e os arquivos de código em uma única pasta para cada função. Por padrão, o nome da pasta determina o nome da função.

Por exemplo, uma função nomeada hello tem uma pasta com os arquivos a seguir.

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

O exemplo a seguir implementa o mesmo resultado do endpoint Express.js acima, mas com 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}`
    };
  }
};

Ao mover para o Functions, as seguintes alterações são feitas:

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

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

  • Convenção de nomenclatura: o nome da pasta usado para conter os arquivos do Azure Functions é usado como o nome do ponto de extremidade por padrão (isso pode ser substituído no function.json).

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

O arquivo function.json a seguir 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 solicitações HTTP GET . Se você quiser que sua API aceite solicitações de suporte POST , você também pode adicionar post à matriz.

Próximas Etapas 

  • Last updated on