Um olhar sobre Node.js

Lado a lado, cá estamos nós novamente para mais um olhar atento sobre outra tecnologia, o Node.js. Eu disse no post anterior que no próximo falaria sobre os principais comandos de MongoDB, mas antes vamos falar um pouco sobre um interpretador bem conceituado no mercado e que hora ou outra aparece como requisito numa vaga de emprego.

O que é Node.js? Onde vive? O que faz?

Node.js é um interpretador de código JavaScript que não depende do browser, pois foi criado para funcionar do lado do servidor e permitir milhares de conexões simultâneas. Não é à toa que Netflix, PayPal, LinkedIn, Walmart, Uber, Groupon, eBay, Nasa…

(Cena do filme Forrest Gump)

e várias outras empresas utilizam Node.js.

Hm… Fale me mais sobre esse tal Node

(Fonte: Wiki Commons)

JavaScript é uma linguagem interpretada, ou seja, existe um motor (JavaScript engine) no seu navegador responsável por traduzir sua gambiarra seu código para um formato capaz de ser executado pela máquina, por exemplo, no Edge temos o Chakra, no Chrome e no Opera temos o V8 e no Firefox o SpiderMonkey. Por isso algumas vezes o JavaScript se comporta de um jeito em um navegador e diferente em outros.

Em 2009 um engenheiro de software bacana chamado Ryan Dahl se perguntou: – Oras! por que não executar JavaScript do lado do servidor? Então, ele pegou o motor V8 usado no Chrome e embutiu em um programa C++ chamado Node. O pequeno Node então se tornou um ambiente de execução para código JavaScript, porém de forma diferente do navegador, com as habilidades de manipular arquivos de sistema e trabalhar com as requisições de rede.

Aplicações Síncronas Vs. Assíncronas

Situação 1

Imagine a seguinte situação: você foi ao médico e ao chegar na recepção foi prontamente atendido. Enquanto isso, chegam mais dois pacientes. A recepcionista diz que eles devem aguardar até que você seja atendido e realize TODOS os exames. Sabendo do caos que isso poderia causar, o hospital resolveu contratar novos médicos para realizar o atendimento, de modo que cada paciente fosse atendido assim que chegasse. Porém essa situação ainda causava problemas…, além dos custos e limite de consultórios, os médicos não podiam atender o próximo paciente até que o atual realizasse os exames e retornasse a ele.

Situação 2

Agora imagine a mesma situação com outra abordagem: você foi ao médico e ao chegar na recepção foi prontamente atendido. Enquanto isso, chegam mais dois pacientes. O médico lhe encaminha para um exame de radiografia e atende o próximo paciente. Ao concluir o exame você volta a recepção e aguarda numa fila até ser atendido novamente e liberado.

Como resultado, veja que na situação 2 o médico não perde tempo aguardando os exames e o próximo paciente não perde tempo aguardando pelo atendimento. Agora vamos trocar as palavras e você verá que o raciocínio é o mesmo.

Situação 1

Imagine a seguinte arquitetura síncrona: uma requisição foi para o servidor e chegando lá uma thread é prontamente alocada para atendê-la. Enquanto isso, chegam mais duas requisições. Mas o sistema informa que elas devem aguardar até que a primeira seja atendida e realize todas as tarefas, como consulta ao banco de dados ou leitura de arquivos no sistema, isto é, ocorre um bloqueio. Sabendo do caos que isso poderia causar, novas threads são alocadas para atender essas requisições, de modo que cada requisição fosse tratada por uma thread. Porém a situação ainda causava problemas…, pois além dos custos com novos servidores para aumentar o número de threads, algumas requisições ainda tinham que aguardar a liberação de recursos.

Situação 2

Agora imagine a mesma situação com a arquitetura assíncrona: uma requisição foi para o servidor e chegando lá uma thread é prontamente alocada para atendê-la. Enquanto isso chegam mais duas requisições. A thread encaminha a primeira requisição para uma consulta ao banco de dados e atende a próxima requisição. Quando o banco conclui a consulta, coloca uma mensagem em uma fila de eventos informando, para que posteriormente esse evento seja analisado e processado.

Aí está, Node.js funciona de maneira assíncrona, ou seja, monitora constantemente a fila de eventos em segundo plano e executa uma única thread com o código JavaScript que lida com a requisição.

Vantagens

Sem bloqueios

Como já dito, o Node.js funciona em um modelo de E/S sem bloqueio que o torna ideal para os aplicativos em tempo real que exigem muitos dados ou que precisam ser executados em tempo real.

Suporte a JavaScript

Banco de dados NoSQL, como o MongoDB e CouchDB oferecem suporte a JavaScript. Os desenvolvedores não precisam lidar com as diferenças de sintaxe ao unir Node.js e NoSQL.

Multiplataforma

Seu código pode ser executado em Windows, Linux e OSX.

NPM

Node possui um gerenciador de pacotes, NPM (Node Package Manager), com milhares de bibliotecas JavaScript prontas para serem utilizadas, para não precisar reinventar a roda.

Desvantagens

Tipagem fraca

Node não possui orientação a objetos e tem tipagem fraca, isto é, não detecta erros em operações do tipo ‘1’ + 1, ‘2’ + true…

Curva de aprendizagem

Nem todo desenvolvedor JavaScript é um desenvolvedor Node.js. Dominar a programação JavaScript do lado do servidor requer uma quantidade de esforço e um certo histórico no desenvolvimento de back-end.

Não é bom com bancos de dados relacionais

Os desenvolvedores apontam que usar o Node.js com bancos de dados relacionais não é uma tarefa fácil. As ferramentas ainda não estão à altura quando comparadas aos concorrentes no mercado.

Chamadas assíncronas podem ser um problema

Dependendo do número de chamadas assíncronas a quantidade de call-backs pode resultar em problemas de depuração.

Enfim, essa foi outra breve introdução, agora sobre Node.js. Pretendo juntar o útil ao agradável unindo Node.js e MongoDB. Espero que você tenha entendido até aqui.

Compartilhe!