Arquivos nodejs - LuizTools

Entendendo o Node.js Event Loop

Continuando os estudos de Node.js me deparei com um elemento chave que não temos como ignorar quando o assunto é essa tecnologia. Estou falando do Event Loop.

Grande parte das características e principalmente das vantagens do Node.js se devem ao funcionamento do seu loop single-thread principal e como ele se relaciona com as demais partes do Node, como a biblioteca C++ libuv.

Assim, a ideia deste artigo é ajudar você a entender como o Event Loop do Node.js funciona, o que deve lhe ajudar a entender como tirar o máximo de proveito dele.

Vamos ver neste artigo:

O problema
A solução
Node.js Event Loop
Task/Event/Message Queue
Microtasks e Macrotasks
Conclusões

Você pode acompanhar este conteúdo através do vídeo abaixo, que é parte do meu curso de Node.js e MongoDB:

O problema

Antes de entrar no Event Loop em si, vamos primeiro entender porque o Node.js possui um e qual o problema que ele propõe resolver.

A maioria dos backends por trás dos websites mais famosos não fazem computações complicadas. Nossos programas passam a maior parte do tempo lendo ou escrevendo no disco, ou melhor, esperando a sua vez de ler e escrever, uma vez que é um recurso lento e concorrido. Quando não estamos nesse processo de ir ao disco, estamos enviando ou recebendo bytes da rede, que é outro processo igualmente demorado. Ambos processos podemos resumir como operações de I/O (Input & Output) ou E/S (Entrada & Saída).

Processar dados, ou seja executar algoritmos, é estupidamente mais rápido do que qualquer operação de IO que você possa querer fazer. Mesmo se tivermos um SSD em nossa máquina com velocidades de leitura de 200-730 MB/s fará com que a leitura de 1KB de dados leve 1.4 micro-segundos. Parece rápido? Saiba que nesse tempo uma CPU de 2GHz consegue executar 28.000 instruções.

Isso mesmo. Ler um arquivo de 1KB demora tanto tempo quanto executar 28.000 instruções no processador. É muito lento.

Quando falamos de IO de rede é ainda pior. Faça um teste, abra o CMD e execute um ping no site do google.com, um dos mais rápidos do planeta:

$ ping google.com
64 bytes from 172.217.16.174: icmp_seq=0 ttl=52 time=33.017 ms  
64 bytes from 172.217.16.174: icmp_seq=1 ttl=52 time=83.376 ms  
64 bytes from 172.217.16.174: icmp_seq=2 ttl=52 time=26.552 ms

$ ping google.com

64 bytes from 172.217.16.174: icmp_seq=0 ttl=52 time=33.017 ms

64 bytes from 172.217.16.174: icmp_seq=1 ttl=52 time=83.376 ms

64 bytes from 172.217.16.174: icmp_seq=2 ttl=52 time=26.552 ms

A latência média nesse teste é de 44 milisegundos. Ou seja, enviar um ping para o Google demora o mesmo tempo que uma CPU necessita para executar 88 milhões de operações.

Ou seja, quando estamos fazendo uma chamada a um recurso na Internet, poderíamos estar fazendo cerca de 88 milhões de coisas diferentes na CPU.

É muita diferença!

A solução

A maioria dos sistemas operacionais lhe fornece mecanismos de programação assíncrona, o que permite que você mande executar tarefas concorrentes que não ficam esperando uma pela outra, desde que uma não precise do resultado da outra, é claro.

Esse tipo de comportamento pode ser alcançado de diversas maneiras. Atualmente a forma mais comum de fazer isso é através do uso de threads o que geralmente torna nosso código muito mais complexo. Por exemplo, ler um arquivo em Java é uma operação bloqueante, ou seja, seu programa não pode fazer mais exceto esperar a comunicação com a rede ou disco terminar. O que você pode fazer é iniciar uma thread diferente para fazer essa leitura e mandar ela avisar sua thread principal quando a leitura terminar.

Novas formas e programação assíncrona tem surgido com o uso de interfaces async como em Java e C#, mas isso ainda está evoluindo. Por ora isso é entediante, complicado, mas funciona. Mas e o Node? A característica de single-thread dele obviamente deveria representar um problema uma vez que ele só consegue executar uma tarefa de um usuário por vez, certo? Quase.

O Node usa um princípio semelhante ao da função setTimeout(func, x) do Javascript, onde a função passada como primeiro parâmetro é delegada para outra thread executar após x milisegundos, liberando a thread principal para continuar seu fluxo de execução. Mesmo que você defina x como 0, o que pode parecer algo inútil, isso é extremamente útil pois força a função a ser realizada em outra thread imediatamente.

Vamos falar melhor dessa solução na sequência.

Node.js Event Loop

Sempre que você chama uma função síncrona (i.e. “normal”) ela vai para uma “call stack” ou pilha de chamadas de funções com o seu endereço em memória, parâmetros e variáveis locais. Se a partir dessa função você chamar outra, esta nova função é empilhada em cima da anterior (não literalmente, mas a ideia é essa). Quando essa nova função termina, ela é removida da call stack e voltamos o fluxo da função anterior. Caso a nova função tenha retornado um valor, o mesmo é adicionado à função anterior na call stack.

Mas o que acontece quando chamamos algo como setTimeout, http.get, process.nextTick, ou fs.readFile? Estes não são recursos nativos do V8, mas estão disponíveis no Chrome WebApi e na C++ API no caso do Node.js.

Vamos dar uma olhada em uma aplicação Node.js comum – um servidor escutando em localhost:3000. Após receber a requisição, o servidor vai chamar wttr.in/ para obter informações do tempo e imprimir algumas mensagens no console e depois retorna a resposta HTTP.

'use strict'  
const express = require('express')  
const superagent = require('superagent')  
const app = express()

app.get('/', sendWeatherOfRandomCity)

function sendWeatherOfRandomCity (request, response) {  
  getWeatherOfRandomCity(request, response)
  sayHi()
}

const CITIES = [  
  'london',
  'newyork',
  'paris',
  'budapest',
  'warsaw',
  'rome',
  'madrid',
  'moscow',
  'beijing',
  'capetown',
]

function getWeatherOfRandomCity (request, response) {  
  const city = CITIES[Math.floor(Math.random() * CITIES.length)]
  superagent.get(`wttr.in/${city}`)
    .end((err, res) => {
      if (err) {
        console.log('O snap')
        return response.status(500).send('Erro ao consultar a previsão do tempo.')
      }
      const responseText = res.text
      response.send(responseText)
      console.log('Previsão confirmada!')
    })

  console.log('Obtendo a previsão do tempo, aguarde.')
}

function sayHi () {  
  console.log('Hi')
}

app.listen(3000)

'use strict'

const express = require('express')

const superagent = require('superagent')

const app = express()

app.get('/', sendWeatherOfRandomCity)

function sendWeatherOfRandomCity (request, response) {

getWeatherOfRandomCity(request, response)

sayHi()

}

const CITIES = [

'london',

'newyork',

'paris',

'budapest',

'warsaw',

'rome',

'madrid',

'moscow',

'beijing',

'capetown',

]

function getWeatherOfRandomCity (request, response) {

const city = CITIES[Math.floor(Math.random() * CITIES.length)]

superagent.get(`wttr.in/${city}`)

.end((err, res) => {

if (err) {

console.log('O snap')

return response.status(500).send('Erro ao consultar a previsão do tempo.')

}

const responseText = res.text

response.send(responseText)

console.log('Previsão confirmada!')

})

console.log('Obtendo a previsão do tempo, aguarde.')

}

function sayHi () {

console.log('Hi')

}

app.listen(3000)

O que será impresso quando uma requisição é enviada para localhost:3000?

Se você já mexeu um pouco com Node antes, não ficará surpreso com o resultado, pois mesmo que console.log(‘Obtendo a previsão do tempo, aguarde.’) tenha sido chamado depois de console.log(‘Previsão confirmada!’) no código, o resultado da requisição será como abaixo:

Obtendo a previsão do tempo, aguarde.  
Hi  
Previsão confirmada!

Obtendo a previsão do tempo, aguarde.

Previsão confirmada!

O que aconteceu? Mesmo o V8 sendo single-thread, a API C++ do Node não é. Isso significa que toda vez que o Node for solicitado para fazer uma operação bloqueante, Node irá chamar a libuv que executará concorrentemente com o Javascript em background. Uma vez que esta thread concorrente terminar ou jogar um erro, o callback fornecido será chamado com os parâmetros necessários.

A libuv é um biblioteca C++ open-source usada pelo Node em conjunto com o V8 para gerenciar o pool de threads que executa as operações concorrentes ao Event Loop single-thread do Node. Ela cuida da criação e destruição de threads, semáforos e outras “magias” que são necessárias para que as tarefas assíncronas funcionem corretamente. Essa biblioteca foi originalmente escrita para o Node, mas atualmente outros projetos a usam também.

Task/Event/Message Queue

Javascript é uma linguagem single-thread orientada a eventos. Isto significa que você pode anexar gatilhos ou listeners aos eventos e quando o respectivo evento acontece, o listener executa o callback que foi fornecido.

Toda vez que você chama setTimeout, http.get ou fs.readFile, Node.js envia estas operações para a libuv executá-las em uma thread separada do pool, permitindo que o V8 continue executando o código na thread principal. Quando a tarefa termina e a libuv avisa o Node disso, o Node dispara o callback da referida operação.

No entanto, considerando que só temos uma thread principal e uma call stack principal, onde que os callbacks ficam guardados para serem executados? Na Event/Task/Message Queue, ou o nome que você preferir. O nome ‘event loop’ se dá à esse ciclo de eventos que acontece infinitamente enquanto há callbacks e eventos a serem processados na aplicação.

Em nosso exemplo anterior, de previsão do tempo, nosso event loop ficou assim:

Express registrou um handler para o evento ‘request’ que será chamado quando uma requisição chegar em ‘/’
ele começar a escutar na porta 3000
a stack está vazia, esperando pelo evento ‘request’ disparar
quando a requisição chega, o evento dispara e o Express chama o handler configurado: sendWeatherOfRandomCity
sendWeatherOfRandomCity é empilhado na call stack
getWeatherOfRandomCity é chamado dentro da função anterior e é também empilhado na call stack
Math.floor e Math.random são chamadas, empilhadas e logo desempilhadas, retornando uma cidade à variável city
superagent.get é chamado com o parâmetro ‘wttr.in/${city}’ e definimos o handler/callback para o evento de término da requisição.
a requisição HTTP para http://wttr.in/${city} é enviada para uma thread em background e a execução continua
‘Obtendo a previsão do tempo, aguarde.’é impresso no console e getWeatherOfRandomCity retorna
sayHi é chamada, ‘Hi’ é impresso no console
sendWeatherOfRandomCity retorna, é retirado da call stack, deixando-a vazia
ficamos esperando pela chamada de http://wttr.in/${city} nos responder
uma vez que a resposta chegue, o evento de ‘end’ é disparado
o handler anônimo que passamos para .end() é chamado, é colocado na call stack com todos as variáveis locais, o que significa que ele pode ver e modificar os valores de express, superagent, app, CITIES, request, response, city e todas funções que definimos
response.send() é chamado com um status code de 200 ou 500, mas isso também é executado em uma thread do pool para a stream de respostas não fique bloqueada e o handler anônimo é retirado da pilha.

E é assim que tudo funciona!

Vale salientar que por padrão o pool de threads da libuv inicia com 4 threads concorrentes e que isso pode ser configurado conforme a sua necessidade.

Microtasks e Macrotasks

Além disso, como se não fosse o bastante, nós temos duas task queues, não apenas uma. Uma task queue para microtasks e outra para macrotasks.

Exemplos de microtasks

process.nextTick
promises
Object.observe

Exemplos de macrotasks

setTimeout
setInterval
setImmediate
I/O

Para mostrar isso na prática, vamos dar uma olhada no seguinte código:

console.log('script iniciando')

const interval = setInterval(() => {  
  console.log('setInterval')
}, 0)

setTimeout(() => {  
  console.log('setTimeout 1')
  Promise.resolve().then(() => {
    console.log('promise 3')
  }).then(() => {
    console.log('promise 4')
  }).then(() => {
    setTimeout(() => {
      console.log('setTimeout 2')
      Promise.resolve().then(() => {
        console.log('promise 5')
      }).then(() => {
        console.log('promise 6')
      }).then(() => {
        clearInterval(interval)
      })
    }, 0)
  })
}, 0)

Promise.resolve().then(() => {  
  console.log('promise 1')
}).then(() => {
  console.log('promise 2')
})

console.log('script iniciando')

const interval = setInterval(() => {

console.log('setInterval')

}, 0)

setTimeout(() => {

console.log('setTimeout 1')

Promise.resolve().then(() => {

console.log('promise 3')

}).then(() => {

console.log('promise 4')

}).then(() => {

setTimeout(() => {

console.log('setTimeout 2')

Promise.resolve().then(() => {

console.log('promise 5')

}).then(() => {

console.log('promise 6')

}).then(() => {

clearInterval(interval)

})

}, 0)

})

}, 0)

Promise.resolve().then(() => {

console.log('promise 1')

}).then(() => {

console.log('promise 2')

})

a saída no console é:

script iniciando  
promise1  
promise2  
setInterval  
setTimeout1  
promise3  
promise4  
setInterval  
setTimeout2  
setInterval  
promise5  
promise6

script iniciando

promise1

promise2

setInterval

setTimeout1

promise3

promise4

setInterval

setTimeout2

setInterval

promise5

promise6

De acordo com a especificação da WHATWG, uma macrotask deve ser processada da macrotask queue em um ciclo do event loop. Depois que essa macrotask terminar, todas as microtasks existentes são processadas dentro do mesmo ciclo. Se durante este processamento de microtasks novas microtasks surgirem, elas são processadas também, até a microtask queue ficar vazia.

Este diagrama do site Rising Stack ilustra bem o event loop completo:

Em nosso caso:

Ciclo 1:

setInterval é agendado como (macro)task
setTimeout 1 é agendado como task
em Promise.resolve 1 ambos thens são agendados como microtasks
a call stack está vazia e as microtasks executam

Task queue: setInterval, setTimeout 1

Ciclo 2:

a microtask queue está vazia, logo o handler setInterval pode executar;
outro setInterval é agendado como task, logo atrás de setTimeout 1

Task queue: setTimeout 1, setInterval

Ciclo 3:

a microtask queue está vazia, logo o handler setTimeout 1 pode executar;
promise 3 e promise 4 são agendadas como microtasks;
handlers de promise 3 e promise 4 são executados
setTimeout 2 é agendado como task

Task queue: setInterval, setTimeout 2

Ciclo 4:

a microtask queue está vazia; logo o handler de setInteval pode executar;
outro setInterval é agendado como task, logo atrás de setTimeout

Task queue: setTimeout 2, setInterval

Ciclo 5:

o handler setTimeout 2 executa;
promise 5 e promise 6 são agendadas como microtasks;
os handlers de promise 5 e promise 6 executam encerrando o programa.

Nota: isso funciona perfeitamente bem no Google Chrome, mas por questões que fogem da minha compreensão, não é regra em todos ambientes de execução. Existem modificações que podemos fazer no código para que o comportamento seja o mesmo em todos ambientes, mas deixam o código terrivelmente feio (i.e. callback hell).

Conclusões

Como você pôde ver, se quisermos ter total controle de nossas aplicações Node.js devemos prestar atenção nestes detalhes de como as tarefas são executadas dentro do event loop, principalmente para não bloquearmos sua execução sem querer.

O conceito do event loop pode ser um tanto complicado no início mas uma vez que você entender sue funcionamento na prática você não conseguirá mais imaginar sua vida sem ele. Obviamente o uso inicial intenso de callbacks é muito chato de gerenciar mas já é possível usar Promises em nossos códigos Javascript que permitem deixar as tarefas assíncronas mais inteligíveis e em breve devemos ter acesso ao recurso async-await com o ES7.

Uma última dica é que você também pode enviar seus processamentos longos (mas que não são operações de IO), que normalmente seriam executados na thread principal para as threads em background usando bibliotecas como async.js.

Recomendo agora colocar a mão na massa com esse tutorial de Node.js com MongoDB que preparei pra você!

Curtiu o post? Então clica no banner abaixo e dá uma conferida no meu livro sobre programação web com Node.js!

Como fazer upload de arquivos para o Google Drive em Node.js

Com meu curso de Node.js e MongoDB chegando aos quase 200 inscritos na data em que escrevo este tutorial, muitas ideias tem me sido enviadas com relação a temas para posts e novas aulas no curso. Recentemente, um aluno estava tentando fazer algo que me chamou a atenção: uma API em Node.js que recebesse um arquivo e o enviasse para o Google Drive.

Assim, no artigo de hoje quero mostrar como você pode criar uma integração do Node.js com o Google Drive facilmente. Vamos enviar imagens, mas você pode facilmente adaptar o código para enviar outro tipo de arquivo.

Vamos lá!

Google Drive

Obviamente para que você consiga acompanhar este tutorial você deve ter uma conta no Google Drive. Se você possui um Gmail, automaticamente possui uma pois seus emails são armazenados na mesma que, em seu nível gratuito, fornece 15GB de armazenamento na nuvem. Por cerca de R$70/ano você faz um upgrade para 100GB o que lhe permite salvar muita coisa de maneira rápida e segura.

Caso não possua uma, crie em drive.google.com

Surpreendentemente, existe todo um suporte do Google à tecnologia Node.js, que você confere neste painel do Google Drive APIs. Acesse o painel e clique no botão “Enable Drive API” para que seja possível se integrar com a sua conta do GDrive, conforme a imagem abaixo.

Ao ativar a API, você receberá um Client ID e um Client Secret, que serão necessários para a autenticação na aplicação Node.js.Guarde-os consigo, pois eu não vou fornecer os meus, hehehe. Também lhe é oferecido um arquivo de credenciais (credentials.json), baixe e salve-o na pasta do projeto que vamos criar a seguir.

Criando o projeto em Node

Crie uma pasta na sua máquina chamada gdrive-node e navegue até ela via terminal. Crie um gdrive-auth.js vazio e rode um ‘npm init’ para criar uma aplicação. Depois instale a biblioteca do GDrive usando o comando abaixo:

npm install googleapis@27 --save

1	npm install googleapis@27 --save

Lembre-se de ter o seu arquivo credentials.json dentro da pasta do projeto, pois agora vamos carregá-lo na nossa aplicação. Abra o gdrive-auth.js e inclua o seguinte código, adaptado da documentação do Google Drive APIs:

//index.js
const fs = require('fs');
const readline = require('readline');
const {google} = require('googleapis');

// If modifying these scopes, delete token.json.
const SCOPES = ['https://www.googleapis.com/auth/drive.metadata.readonly'];
// The file token.json stores the user's access and refresh tokens, and is
// created automatically when the authorization flow completes for the first
// time.
const TOKEN_PATH = 'token.json';

function callGDriveApi(callback){
    // Load client secrets from a local file.
    fs.readFile('credentials.json', (err, content) => {
    if (err) return console.log('Error loading client secret file:', err);
    // Authorize a client with credentials, then call the Google Drive API.
        if(callback)
            authorize(JSON.parse(content), callback);
        else
            authorize(JSON.parse(content), listFiles);//default
    });
}

/**
 * Create an OAuth2 client with the given credentials, and then execute the
 * given callback function.
 * @param {Object} credentials The authorization client credentials.
 * @param {function} callback The callback to call with the authorized client.
 */
function authorize(credentials, callback) {
  const {client_secret, client_id, redirect_uris} = credentials.installed;
  const oAuth2Client = new google.auth.OAuth2(
      client_id, client_secret, redirect_uris[0]);

  // Check if we have previously stored a token.
  fs.readFile(TOKEN_PATH, (err, token) => {
    if (err) return getAccessToken(oAuth2Client, callback);
    oAuth2Client.setCredentials(JSON.parse(token));
    callback(oAuth2Client);
  });
}

/**
 * Get and store new token after prompting for user authorization, and then
 * execute the given callback with the authorized OAuth2 client.
 * @param {google.auth.OAuth2} oAuth2Client The OAuth2 client to get token for.
 * @param {getEventsCallback} callback The callback for the authorized client.
 */
function getAccessToken(oAuth2Client, callback) {
  const authUrl = oAuth2Client.generateAuthUrl({
    access_type: 'offline',
    scope: SCOPES,
  });
  console.log('Authorize this app by visiting this url:', authUrl);
  const rl = readline.createInterface({
    input: process.stdin,
    output: process.stdout,
  });
  rl.question('Enter the code from that page here: ', (code) => {
    rl.close();
    oAuth2Client.getToken(code, (err, token) => {
      if (err) return console.error('Error retrieving access token', err);
      oAuth2Client.setCredentials(token);
      // Store the token to disk for later program executions
      fs.writeFile(TOKEN_PATH, JSON.stringify(token), (err) => {
        if (err) return console.error(err);
        console.log('Token stored to', TOKEN_PATH);
      });
      callback(oAuth2Client);
    });
  });
}

/**
 * Lists the names and IDs of up to 10 files.
 * @param {google.auth.OAuth2} auth An authorized OAuth2 client.
 */
function listFiles(auth) {
  const drive = google.drive({version: 'v3', auth});
  drive.files.list({
    pageSize: 10,
    fields: 'nextPageToken, files(id, name)',
  }, (err, res) => {
    if (err) return console.log('The API returned an error: ' + err);
    const files = res.data.files;
    if (files.length) {
      console.log('Files:');
      files.map((file) => {
        console.log(`${file.name} (${file.id})`);
      });
    } else {
      console.log('No files found.');
    }
  });
}

callGDriveApi();

module.exports = callGDriveApi;

100

//index.js

const fs = require('fs');

const readline = require('readline');

const {google} = require('googleapis');

// If modifying these scopes, delete token.json.

const SCOPES = ['https://www.googleapis.com/auth/drive.metadata.readonly'];

// The file token.json stores the user's access and refresh tokens, and is

// created automatically when the authorization flow completes for the first

// time.

const TOKEN_PATH = 'token.json';

function callGDriveApi(callback){

// Load client secrets from a local file.

fs.readFile('credentials.json', (err, content) => {

if (err) return console.log('Error loading client secret file:', err);

// Authorize a client with credentials, then call the Google Drive API.

if(callback)

authorize(JSON.parse(content), callback);

else

authorize(JSON.parse(content), listFiles);//default

});

}

/**

* Create an OAuth2 client with the given credentials, and then execute the

* given callback function.

* @param {Object} credentials The authorization client credentials.

* @param {function} callback The callback to call with the authorized client.

function authorize(credentials, callback) {

const {client_secret, client_id, redirect_uris} = credentials.installed;

const oAuth2Client = new google.auth.OAuth2(

client_id, client_secret, redirect_uris[0]);

// Check if we have previously stored a token.

fs.readFile(TOKEN_PATH, (err, token) => {

if (err) return getAccessToken(oAuth2Client, callback);

oAuth2Client.setCredentials(JSON.parse(token));

callback(oAuth2Client);

});

}

/**

* Get and store new token after prompting for user authorization, and then

* execute the given callback with the authorized OAuth2 client.

* @param {google.auth.OAuth2} oAuth2Client The OAuth2 client to get token for.

* @param {getEventsCallback} callback The callback for the authorized client.

function getAccessToken(oAuth2Client, callback) {

const authUrl = oAuth2Client.generateAuthUrl({

access_type: 'offline',

scope: SCOPES,

});

console.log('Authorize this app by visiting this url:', authUrl);

const rl = readline.createInterface({

input: process.stdin,

output: process.stdout,

});

rl.question('Enter the code from that page here: ', (code) => {

rl.close();

oAuth2Client.getToken(code, (err, token) => {

if (err) return console.error('Error retrieving access token', err);

oAuth2Client.setCredentials(token);

// Store the token to disk for later program executions

fs.writeFile(TOKEN_PATH, JSON.stringify(token), (err) => {

if (err) return console.error(err);

console.log('Token stored to', TOKEN_PATH);

});

callback(oAuth2Client);

});

}

/**

* Lists the names and IDs of up to 10 files.

* @param {google.auth.OAuth2} auth An authorized OAuth2 client.

function listFiles(auth) {

const drive = google.drive({version: 'v3', auth});

drive.files.list({

pageSize: 10,

fields: 'nextPageToken, files(id, name)',

}, (err, res) => {

if (err) return console.log('The API returned an error: ' + err);

const files = res.data.files;

if (files.length) {

console.log('Files:');

files.map((file) => {

console.log(`${file.name} (${file.id})`);

});

} else {

console.log('No files found.');

}

});

}

callGDriveApi();

module.exports = callGDriveApi;

Basicamente o que temos aqui é o código que implementa a autenticação OAuth offline. Ou seja, a sua aplicação vai solicitar um token para a sua conta do Google Drive, que vai ser utilizada pela sua aplicação. Mais tarde usaremos este módulo para chamar a API do GDrive.

Ao executar esse código pela primeira vez no console (node gdrive-auth) você receberá uma URL que deve ser acessada. Copie a URL e ao acessar a página no navegador, você verá a sua conta do Google e ela vai lhe questionar se você quer conceder acesso à essa aplicação Node (Quickstart). Fornecendo a permissão você receberá o token que deve ser informado no terminal novamente, para que seja gravado.

Se tudo ocorrer bem, um teste deve ser realizado automaticamente listando os 10 últimos arquivos adicionados na sua conta do GDrive. Com isso temos um projeto configurado e autenticado para acessar as APIs do Google Drive (essa autenticação é feita apenas uma vez, para obter o arquivo token.json, que fica na raiz da sua aplicação).

Atenção: o escopo da permissão que solicitamos é para gerenciar pastas e arquivos enviados pela própria aplicação. Sendo assim, no primeiro teste não será listado nenhum arquivo pois a aplicação não criou nada ainda. Nos testes subsequentes, no console serão listados os arquivos que já fizemos upload.

Se precisar mudar o escopo de permissão (na variável SCOPES), certifique-se também de excluir o arquivo token.json para que o processo de autenticação reinicie corretamente e ele seja criado com as permissões corretas.

Enviando uma imagem

Agora vamos criar outro módulo no nosso projeto, em um arquivo gdrive.js, com o seguinte conteúdo, adaptado também da documentação oficial:

const fs = require("fs");
const {google} = require('googleapis');

function imageUpload(fileName, filePath, callback){
    require("./gdrive-auth")((auth) => {
        const fileMetadata = {
            name: fileName
        };

        const media = {
            mimeType: "image/jpeg",
            body: fs.createReadStream(filePath)
        }
        
        const drive = google.drive({version: 'v3', auth});
        drive.files.create({
            resource: fileMetadata,
            media: media,
            fields: 'id'
          }, function (err, file) {
            if (err) {
              // Handle error
              console.error(err);
            } else {
              callback(file.data.id);
            }
          });
    });
}

module.exports = { imageUpload };

const fs = require("fs");

const {google} = require('googleapis');

function imageUpload(fileName, filePath, callback){

require("./gdrive-auth")((auth) => {

const fileMetadata = {

name: fileName

};

const media = {

mimeType: "image/jpeg",

body: fs.createReadStream(filePath)

}

const drive = google.drive({version: 'v3', auth});

drive.files.create({

resource: fileMetadata,

media: media,

fields: 'id'

}, function (err, file) {

if (err) {

// Handle error

console.error(err);

} else {

callback(file.data.id);

}

});

}

module.exports = { imageUpload };

Neste módulo nós usamos o módulo anterior, de autenticação, e depois enviamos uma imagem passada como argumento para o GDrive criar ela idêntica na nuvem. O argumento fileName é apenas o nome da imagem enquanto que o filePath é o caminho relativo ou literal. Após a criação, será executado um callback com o ID do arquivo no GDrive que acabamos de criar.

Caso queira fazer upload de outros arquivos que não sejam imagens JPG, basta trocar o mime-type.

Agora que temos um módulo de autenticação e um de upload de imagem, vamos criar um index.js para realizar alguns testes:

//index.js
const gdrive = require("./gdrive");
gdrive.imageUpload("imagem.jpg", "./imagem.jpg", (id) => {
    console.log(id);
});

//index.js

const gdrive = require("./gdrive");

gdrive.imageUpload("imagem.jpg", "./imagem.jpg", (id) => {

console.log(id);

});

Aqui estou considerando que você tem um arquivo chamado imagem.jpg dentro da pasta do projeto, no mesmo nível dos módulos. Rode essa aplicação com “node index” e você deve encontrar o novo arquivo na sua conta do GDrive, na raiz do mesmo.

Agora, com as adaptações certas, você pode usar esse módulo em uma web API Express ou mesmo com algum outro framework do Node, para compor uma solução de verdade.

Espero que tenha gostado!

Curtiu o tutorial? Para mais conteúdos bacanas em texto e videoaulas, conheça o meu curso de Node.js e MongoDB clicando no banner abaixo.

Autorização em Node.js com Passport – Parte 4

Esse tutorial é uma continuação de uma série de artigos sobre segurança em Node.js que iniciei há algum tempo, usando o módulo Passport, o mais popular para autenticação em Node.js. Nas etapas anteriores nós criamos o login, o cadastro, a recuperação de senha e o logout. Hoje vamos criar a camada de autorização, ou seja, uma vez que o usuário esteja autenticado, devemos permitir ou não que ele faça determinadas operações no sistema conforme o seu perfil de acesso.

Atenção: para que possa acompanhar este tutorial é necessário que tenha realizado as etapas anteriores ou ao menos baixado o zip do tutorial anterior, disponível via formulário sempre ao final dos tutoriais. Note que mesmo baixando o zip, você terá de ter o Node.js e o MongoDB instalados na sua máquina (este último rodando) e tem de revisar o arquivo .env para configurar ele com os seus dados (email, string de conexão do banco, etc). Sugiro cadastrar também alguns usuários no seu Mongo para poder usar o sistema corretamente.

Vale salientar que este artigo possui uma versão em videoaula, disponível aos inscritos em meu curso de Node.js e MongoDB.

Vamos lá!

O tripé de segurança

Os elementos mais básicos de segurança em sistemas são o tripé AAA: Autenticação, Autorização e Auditoria. Já falamos extensivamente sobre autenticação nos artigos anteriores e nesse vamos falar de autorização.

A diferença mais básica é que autenticação se resume a dizer quem pode ou não entrar. Já autorização, é o que cada usuário que entrou, pode fazer no sistema.

Existem várias maneiras de implementar isso, das mais elaboradas (usando recursos dedicados de infraestrutura como Active Directory ou LDAP, por exemplo) às mais simples, ter perfis no seu banco de dados e dar match com eles na hora de ver se o usuário pode ou não fazer algo que ele quer. Eu irei neste tutorial pela segunda abordagem.

Espero em artigos futuros falar do terceiro A do tripé: a auditoria, que nada mais é do que o registro das atividades dos usuários no sistema, para consulta futura.

Autorização com ExpressJS e Passport

Como já foi implementado nos tutoriais anteriores e extensivamente explicado, o Passport é um framework genérico para construir de maneira modular a segurança do seu sistema. Nos tutoriais passados usamos ele em conjunto com um conector de MongoDB, pra usar o respectivo banco como sendo a verdade em termos de autenticação do sistema.

Assim, a cada requisição do ExpressJS, usamos o middleware para chamar uma função de verificação e dizer se o usuário pode ou não continuar fazendo aquela requisição ou se deve ser jogado para a tela de login. O que iremos fazer aqui são três coisas:

fornecer funções genéricas para que possa ser verificado a autorização do usuário para determinada operação;
aplicar tais funções no middleware do Express para, nas chamadas do Passport, avaliar não apenas a autenticação, mas também a autorização;
chamar tais funções também na renderização da interface, para garantir que ela atenda às necessidades de segurança conforme usuário autenticado;

Com isso, você não terá um sistema completo, mas um overview de como aplicar tais conceitos e códigos em um sistema real.

Adaptando o cadastro

A primeira coisa que vamos fazer é adaptar a nossa tela de signup para incluir a informação de perfil do usuário. Aqui faremos algo super simples: ao cadastrar um novo usuário, você vai selecionar entre os perfis de administrador e de usuário.

Modifique a view signup.ejs para incluir um select de perfil, como abaixo:

<!doctype html>
<html>
  <body>
    <h1>Signup</h1>
    <form action="/users/signup" method="POST">
      Username: <input name="username" type="text" /><br />
      Password: <input name="password" type="password" /><br />
      E-mail: <input name="email" type="text" /><br />
      Perfil: <select name="profile">
        <option value="1">Usuário</option>
        <option value="2">Administrador</option>
      </select><br />
      <input type="submit" value="Save" />
    </form>
    <% if(message) { %>
      <p>
        <label style="color:Red"><%= message %></label>
      </p>
    <%}%>
  </body>
</html>

<!doctype html>

<html>

<body>

<h1>Signup</h1>

Username: <input name="username" type="text" /><br />

Password: <input name="password" type="password" /><br />

E-mail: <input name="email" type="text" /><br />

Perfil: <select name="profile">

<option value="1">Usuário</option>

<option value="2">Administrador</option>

</select><br />

</form>

<% if(message) { %>

<p>

</p>

<%}%>

</body>

</html>

O que vai resultar em uma tela renderizada assim:

O usuário é salvo no banco de dados através de uma função createUser que fica no nosso módulo db.js. Assim, vamo nesse módulo alterar a respectiva função:

function createUser(username, password, email, profile, callback){
    const cryptoPassword = bcrypt.hashSync(password, 10);
    global.db.collection("users").insertOne({username, password: cryptoPassword, email, profile}, callback);
}

function createUser(username, password, email, profile, callback){

const cryptoPassword = bcrypt.hashSync(password, 10);

global.db.collection("users").insertOne({username, password: cryptoPassword, email, profile}, callback);

}

Note que você já tem usuários cadastrados no sistema, eles não terão a informação de profile (perfil) salva neles. Aí você tem duas opções: tratar quem não tem perfil como sendo um usuário padrão (que não é administrador), ou fazer um script para alterar todos os usuários já cadastrados no MongoDB para terem a informação de profile também.

Eu vou de primeira opção, vou considerar que por padrão os usuários sem profile NÃO são administradores.

Agora, para fazer o botão Save voltar a funcionar, vamos na rota users.js e vamos editar o código que trata requisições POST no endpoint /signup para que ele espere e salve o dado do perfil também, usando a função que acabamos de alterar, como abaixo:

/* POST users */
router.post('/signup', function(req, res, next){
  const db = require('../db');
  db.createUser(req.body.username, req.body.password, req.body.email, req.body.profile, (err, result) => {
    if(err) return res.redirect('/users/signup?fail=true');
    else{
      var text = 'Obrigado por se cadastrar {fulano}, sua senha é {senha}';
      text = text.replace('{fulano}', req.body.username).replace('{senha}', req.body.password);

      require('../mail')(req.body.email, 'Cadastro realizado com sucesso!', text);
      res.redirect('/');
    }
  })
})

/* POST users */

router.post('/signup', function(req, res, next){

const db = require('../db');

db.createUser(req.body.username, req.body.password, req.body.email, req.body.profile, (err, result) => {

if(err) return res.redirect('/users/signup?fail=true');

else{

var text = 'Obrigado por se cadastrar {fulano}, sua senha é {senha}';

text = text.replace('{fulano}', req.body.username).replace('{senha}', req.body.password);

require('../mail')(req.body.email, 'Cadastro realizado com sucesso!', text);

res.redirect('/');

}

})

Com isso, seu cadastro já deve estar funcionando novamente e sugiro que cadastre um novo usuário como sendo administrador, já que os anteriores vão ser todos considerados comuns.

Está curtindo o post? Para uma formação ainda mais completa como programador web recomendo meu livro sobre programação web com Node.js clicando no banner abaixo!

Inserindo autorização por página

Agora que você tem a informação de perfil junto ao usuário cadastrado e cadastrou um usuário administrador, vamos dar alguns privilégios apenas para administradores. Que tal criar uma página que somente eles podem acessar?

Vamos criar uma nova view chamada views/reports.ejs com um conteúdo bem simples, só pra testarmos o conceito:

<h1>Só administradores conseguem ver isso</h1>

1	<h1>Só administradores conseguem ver isso</h1>

E vamos criar um novo arquivo de rota em routes/reports.js com apenas o tratamento de um GET, como abaixo:

var express = require('express');
var router = express.Router();

/* GET reports page */
router.get('/', global.authenticationMiddleware(), function(req, res, next) {
    res.render('reports', { });
});

module.exports = router;

var express = require('express');

var router = express.Router();

/* GET reports page */

router.get('/', global.authenticationMiddleware(), function(req, res, next) {

res.render('reports', { });

});

module.exports = router;

Note como o global.autheticationMiddeware() é chamado, não apenas nesta, mas em todas rotas do sistema. Isso garante uma centralização das regras de segurança de acesso, que vamos modificar depois.

Registre essa nova rota no app.js como abaixo:

var reportsRouter = require('./routes/reports');
app.use('/reports', reportsRouter);

1 2	var reportsRouter = require('./routes/reports'); app.use('/reports', reportsRouter);

Se você rodar essa aplicação agora e tentar acessar digitando a URL http://localhost:3000/reports no seu navegador, conseguirá acessar normalmente esta página com qualquer usuário devidamente autenticado, mas não conseguirá acessar antes de fazer login (o servidor vai te redirecionar pra página de login se tentar fazer isso).

Mas e se quisermos restringir o acesso a essa página somente a administradores?

Existem várias maneiras de fazer isso. Vou te mostrar uma possibilidade que é centralizando em um módulo a estrutura de decisão para acesso às páginas. Certamente você deve ter várias ideias de como fazer melhor isso, mas essa é a mais simples e didática que consegui imaginar.

Crie na raiz do seu projeto um arquivo permissions.js e vamos criar nele uma lógica que, dada uma requisição, verificamos o usuário autenticado e que página ele está tentando acessar. Batemos essas informações com um switch/case e concedemos ou não a autorização para aquela página.

const ADMIN_PROFILE = '2';

function isAdmin(profile){
    return profile === ADMIN_PROFILE;
}

module.exports = (request) => {

    const user = request.user;
    if (!user) return false; // usuário anônimo

    const originalUrl = request.originalUrl;
    const profile = request.user.profile;
    //no futuro, você pode restringir de maneira diferente por method (GET,POST, etc)
    const method = request.method;

    console.log(originalUrl);
    //switch/case para tomada de decisão sobre autorizações
    switch(originalUrl){
        case '/': return true;
        case '/index': return true;
        case '/login': return true;
        case '/signup': return true;
        case '/reports': { return isAdmin(profile); }
        default: return false;
    }

}

const ADMIN_PROFILE = '2';

function isAdmin(profile){

return profile === ADMIN_PROFILE;

}

module.exports = (request) => {

const user = request.user;

if (!user) return false; // usuário anônimo

const originalUrl = request.originalUrl;

const profile = request.user.profile;

//no futuro, você pode restringir de maneira diferente por method (GET,POST, etc)

const method = request.method;

console.log(originalUrl);

//switch/case para tomada de decisão sobre autorizações

switch(originalUrl){

case '/': return true;

case '/index': return true;

case '/login': return true;

case '/signup': return true;

case '/reports': { return isAdmin(profile); }

default: return false;

}

Note que eu inicio o código criando uma constante e uma função muito simples para dizer se um perfil é ou não é admin. Mas é no module.exports que realmente programo algo de valor pois, dado uma request, eu pego as informações que me interessam e confronto elas com as URLs e suas lógicas de autorização.

Essa é uma abordagem centralizada em um módulo para as regras de autorização. Assim fica bem fácil de manter a aplicação com as regras necessárias. Outra abordagem que já usei no passado era de fazer isso em cada página, ao invés de fazer centralizado e ficou bem ruim de dar manutenção pois era fácil de esquecer de adicionar as regras certas. Aqui, do jeito que está, caso você se esquecer, ao testar já não vai abrir a página e você vai lembrar que deve permitir no arquivo permissions.js.

Mas como fazer esse código de fato passar a valer?

Volte ao app.js e você vai encontrar o código que configura o global.authenticationMiddleware. Você vai modificá-lo para, além de verificar se o usuário está autenticado, verificar se ele tem a permissão necessária para acessar aquela rota, usando o módulo que acabamos de criar, assim:

global.authenticationMiddleware = () => {  
  return function (req, res, next) {
    if (req.isAuthenticated() && require("./permissions")(req))
        return next()
    res.redirect('/login?fail=true')
  }
}

global.authenticationMiddleware = () => {

return function (req, res, next) {

if (req.isAuthenticated() && require("./permissions")(req))

return next()

res.redirect('/login?fail=true')

}

Agora, toda vez que uma rota for acionada, além de verificar se o usuário está autenticado ou não, vai ser verificado se ele possui permissão para acessar aquela rota. Eu deixei um comentário no código do permissions.js que lhe sugere no futuro verificar o method da request também. Assim, você pode diferenciar tentativas de acesso de tentativas de submissão de formulários, por exemplo.

Esse código, do jeito que está, já funciona e se você acessar sua aplicação e se autenticar, dependendo do usuário que utilizou vai conseguir ou não acessar a página /reports.

Customizando a interface pelo perfil

Para finalizar esse artigo, outra coisa bem comum de ser utilizado em sistemas são as interfaces customizadas conforme a permissão do usuário. Por exemplo, um botão pode ser visto apenas um perfil específico, pois é um botão importante.

Claro, você nunca deve confiar apenas em esconder elementos de interface, mas considerando que já garantimos na seção anterior a segurança por acesso, independente se foi feito digitando a URL ou clicando em links, agora vamos fazer um exemplo bem simples de esconder ou mostrar um elemento de interface baseado no perfil autenticado.

Primeiro, vamos na rota index.js e vamos mudar o código levemente, para informar o perfil do usuário autenticado no model que enviaremos pra view, como abaixo:

/* GET home page. */
router.get('/:pagina?', global.authenticationMiddleware(), function(req, res, next) {
  const pagina = parseInt(req.params.pagina || "1");
  db.countAll((err, qtd) => {
    if(err) return console.log(err);
    const qtdPaginas = Math.ceil(qtd / db.TAMANHO_PAGINA);

    db.findAllUsers(pagina, (err, docs) => {
      if(err) return console.log(err);
      res.render('index', { title: req.user.username, docs, qtd, qtdPaginas, pagina, profile: req.user.profile });
    })
  })
});

/* GET home page. */

router.get('/:pagina?', global.authenticationMiddleware(), function(req, res, next) {

const pagina = parseInt(req.params.pagina || "1");

db.countAll((err, qtd) => {

if(err) return console.log(err);

const qtdPaginas = Math.ceil(qtd / db.TAMANHO_PAGINA);

db.findAllUsers(pagina, (err, docs) => {

if(err) return console.log(err);

res.render('index', { title: req.user.username, docs, qtd, qtdPaginas, pagina, profile: req.user.profile });

})

});

Note que a única linha que mexi foi aquela do profile, para passá-lo para a view.

Agora, na view views/index.ejs, vamos editar o código HTML para, baseado no perfil do usuário, exibir ou não um link para a página de relatórios. Basta inserir esse trecho em qualquer parte da página:

    <p>
      <%
        if(profile === '2'){
      %>
          <a href="/reports">reports para admins</a>
      <% } %>
    </p>

<p>

if(profile === '2'){

<a href="/reports">reports para admins</a>

<% } %>

</p>

Com isso, você pode testar sua aplicação com diferentes usuários e verificar que somente quando se autentica com os administradores é que consegue ver o dito-cujo link que acabou de adicionar.

O mais legal é que, independente do usuário ver ou não o link, se ele tentar burlar acessando diretamente a página de reports, a nossa segurança que está no middleware vai barrar ele também.

E por hoje é isso, espero que tenha gostado, deixe suas dúvidas nos comentários. Você pode baixar os fontes usando o formulário que pede seu e-mail e, se quiser participar do meu curso de Node.js e MongoDB, além de fazer parte do meu grupo online de Whatsapp com mais de 100 estudantes de Node, clique no banner abaixo.

Este artigo tem uma versão em videoaula em uma das aulas do meu curso de Nodejs e MongoDB que você confere clicando no banner abaixo.