NODE OVERVIEW: Criando um servidor node.js do zero. Parte 1

Esse texto é a parte escrita da minha apresentação no Google Developers Group que aconteceu dia 23 de fevereiro em Itabira. Abordarei sobre os princípios de como criar um servidor simples em node.js. O conteúdo está dividido em duas partes, a primeira parte sendo mais teórica e a segunda, uma visão mais prática.

Vamos lá?

Redes

Antes de começarmos, é importante dar uma pincelada no básico sobre como redes de internet funcionam. Começaremos pela camada OSI:

Camada OSI

A camada OSI separa em seções todas as tecnologias dentro de uma comunicação Internet, desde a página HTML enviada via método HTTP que é sua camada de aplicação, até os elétrons dentro de uma fibra óptica na camada física. Um desenvolvedor Web normalmente trabalha nas três camadas superiores, a de Aplicação, gerando métodos HTTP, na de apresentação, e também na de sessão ao trabalhar com websockets, por exemplo.

Só a camada OSI em seus detalhes já é um texto à parte.(Coloquei nas referências, conteúdo sobre OSI para quem quiser se aprofundar).

HTTP

Um método importantíssimo para qualquer desenvolvedor web é o Hyper Text Transfer Protocol, olhe no link que você está acessando, está vendo o https:// ? Isso significa que para que você recebesse essa página do Medium, foi utilizado método HTTPS, um método mais seguro que o HTTP.

Comunicação HTTP

A comunicação HTTP funciona de forma que ao cliente fazer uma requisição para um determinado endereço, o servidor irá interpretar a ação e gerar uma resposta. Cabe ao servidor ficar na escuta, esperando requisições vindas de diversos clientes dando respostas de acordo com a ação feita. É um método estático, o usuário só receberá novas informações caso ele faça uma nova requisição, para fluxos dinâmicos e persistentes de troca de dados, utilizam-se tecnologias como WebSockets, por exemplo.

Post & Get (Métodos de requisição)

Existem diversos métodos HTTP, todas elas geram ações diferentes que um mesmo endereço pode executar. Por exemplo, podemos criar um site chamado https://www.patinetesTOP.com.br/. E seu método Get para o endereço “/” me retorna todos os patinetes do meu banco de dados. Já meu método post recebe informações do body da minha resposta e insere um novo patinete no banco de dados. Usualmente, existem duas formas de passar informação para o servidor em uma requisição: através da URL, e através do body.

Respostas e seus códigos.

Já entendemos como funciona as requisições do cliente, agora vamos ver como um servidor irá responder a elas. A resposta é enviada junto com um código que representa o estado da ação, 200, por exemplo, quer dizer “Ok”, ou seja, a requisição realizada pelo usuário ocorreu conforme esperado, temos também erro 500, que significa que algo de errado aconteceu no servidor. Temos também o famoso 404, “not found”. São muitos códigos e não cabe a esse texto descrever cada um deles (coloquei nas referências um link com todos eles) Para um desenvolvedor, o importante é saber o primeiro digito da resposta:

• 2xx: Tudo ocorreu corretamente e o resultado foi conforme o esperado.
• 3xx: Redirecionamento de requisição.
• 4xx: Erro na requisição do cliente.
• 5xx: Erro no servidor.

API

Application Programming Interface ou API é uma interface de comunicação que disponibiliza dados dependendo das informações inseridas. Normalmente, ao fazer uma requisição em dado endereço web uma API estará na escuta e irá lhe fornecer dados a partir dos que recebeu.

Localização típica de uma API (na nuvem)

Por exemplo, uma API de meteorologia, ao fazer uma requisição get no endereço https://apidemeteorologia.com.br/temp com as coordenadas geográficas ele irá me retornar a temperatura local da região. API’s normalmente funcionam em estado REST, que significa que elas ficam aguardando uma requisição, assim que algum usuário a realizar ela irá trabalhar para entregar os dados desejados pelo cliente.

Node.js

Antes de irmos ao código, vamos explicar um pouco do porquê escolher node.js para seus projetos, suas vantagens e suas desvantagens.

Single Threads e programação assíncrona

A maior diferença do framework node.js e demais tecnologias para o desenvolvimento de servidores é como ele faz o gerenciamento das requisições dos acessos, enquanto a maioria cria uma thread para gerir cada requisição, no node existe apenas uma thread. Essa única thread chamada de Event Loop lida com todas as requisições, para eventos de sistema como consulta de banco de dados e acesso a arquivos ele faz uma chamada e enquanto ela não retorna nada, o servidor gerencia outras pendências.

Isso é incrível, pois, você consegue fazer assincronamente tarefas que realmente demoram mais tempo e com menos custo uma vez que não é aberta uma nova thread para cada requisição.

Nem tudo são flores na tecnologia node.js. Essa arquitetura de gerenciamento de requisições renuncia a criação de threads únicas para cada requisição e com isso, o sistema será sempre muito sobrecarregado toda vez que uma requisição exija muito poder computacional de um sistema uma vez que você terá somente uma thread para lidar com esse processamento.

Outro problema que vejo em Node.js é a própria linguagem, apesar de javascript ser extremamente fácil de escrever e ser totalmente portátil, ela tem seus problemas que deixa qualquer programador irritado. (Why does javascript sucks). Javascript é mais difícil de debugar, menos estruturas, as boas práticas, para mim, não são boas práticas. Infinitas frameworks que leva a diversas formas de implementar o mesmo problema gerando uma difícil comunicação entre desenvolvedores da mesma linguagem.

Essa foi a parte teórica do node.js, na parte 2, vamos criar a nossa própria API a partir dos conhecimentos passados!