Escrito por: Kasper Siig

Introdução

Já tentou configurar algum tipo de servidor em casa, onde você tem que abrir uma nova porta para cada serviço? Já teve que lembrar qual porta vai para qual serviço, e qual é o seu IP doméstico? Isso é definitivamente algo que funciona, e as pessoas fazem isso há muito tempo.

No entanto, não seria bom digitar plex.example.com e ter acesso instantâneo ao seu servidor de mídia? É exatamente isso que um proxy reverso fará por você, e combiná-lo com o Docker está mais fácil do que nunca.

Pré-requisitos

Docker e Docker-Compose

Você deve ter o Docker versão 17.12.0+ e o docker-compose versão 1.21.0+.

Domínio

Você deve ter um domínio configurado e ter um certificado SSL associado a ele. Se você não tiver um, siga meu guia aqui (texto em inglês) sobre como obter um gratuitamente com o LetsEncrypt.

O que este artigo abordará

Acredito firmemente na importância de se entender o que você está fazendo. Houve um tempo em que eu seguia guias e não fazia ideia de como solucionar falhas. Se é assim que você quer fazer isso, aqui está um ótimo tutorial (em inglês), que aborda como configurá-lo. Embora meus artigos sejam longos, você deve acabar entendendo como tudo funciona.

O que você aprenderá aqui: o que é um proxy reverso, como configurá-lo e como protegê-lo. Eu tento, da melhor maneira possível, dividir o assunto em seções, as quais estarão divididas por cabeçalhos. Assim, sinta-se à vontade para pular uma seção, se quiser. Eu recomendo ler o artigo inteiro uma vez primeiro, antes de começar a configuração.

O que é um proxy reverso?

Proxy comum

Vamos começar com o conceito de um proxy comum. Embora este seja um termo muito prevalente na comunidade de tecnologia, não é o único lugar em que é usado. Um proxy significa que a informação está passando por um terceiro, antes de chegar ao local.

Digamos que você não queira que um serviço saiba seu IP. Você pode, nesse caso, usar um proxy. Um proxy é um servidor que foi configurado especificamente para essa finalidade. Se o servidor proxy que você está usando estiver localizado, por exemplo, em Amsterdã, o IP que será mostrado para o mundo externo será o IP do servidor em Amsterdã. Os únicos que saberão seu IP são os que controlam o servidor proxy.

Proxy reverso

Para simplificar, um proxy adicionará uma camada de mascaramento. É o mesmo conceito em um proxy reverso, excetuando o fato de que, em vez de mascarar as conexões de saída (você acessando um servidor web), são as conexões de entrada (pessoas acessando seu servidor web) que serão mascaradas. Você simplesmente fornece um URL como exemplo.com e, sempre que as pessoas acessarem esse URL, seu proxy reverso cuidará para onde vai essa solicitação.

Digamos que você tenha dois servidores configurados em sua rede interna. Server1 está em 192.168.1.10 e Server2 está em 192.168.1.20. No momento, seu proxy reverso está enviando solicitações provenientes de exemplo.com para Server1. Um dia, você tem algumas atualizações para a página da web. Em vez de tirar o site do ar para manutenção, basta fazer a nova configuração no Server2. Feito isso, basta alterar uma única linha em seu proxy reverso e agora as solicitações são enviadas para o Server2. Supondo que o proxy reverso esteja configurado corretamente, você não deve ter absolutamente nenhum tempo de inatividade.

Talvez a maior vantagem de se ter um proxy reverso seja que você pode ter serviços rodando em várias portas, mas só precisa abrir as portas 80 e 443, HTTP e HTTPS, respectivamente. Todas as solicitações chegarão à sua rede nessas duas portas e o proxy reverso cuidará do resto. Tudo isso fará sentido quando começarmos a configurar o proxy.

Configurando o contêiner

O que fazer

docker-compose.yaml:

version: '3'

services:
  reverse:
    container_name: reverse
    hostname: reverse
    image: nginx
    ports:
      - 80:80
      - 443:443
    volumes:
      - <caminho/para/seu/config>:/etc/nginx
      - <caminho/para/seus/certificados>:/etc/ssl/private

Antes de tudo, você deve adicionar um novo serviço ao seu arquivo docker-compose. Você pode chamá-lo como preferir, neste caso eu escolhi "reverse". Aqui, escolhi nginx como a imagem. No entanto, em um ambiente de produção, geralmente é uma boa ideia especificar uma versão caso haja alguma alteração importante em atualizações futuras.

Então você deve vincular duas pastas. /etc/nginx é onde todos os seus arquivos de configuração são armazenados e /etc/ssl/private é onde seus certificados SSL são armazenados. É MUITO importante que sua pasta de configuração NÃO exista em seu host na primeira vez em que você iniciar o contêiner. Quando você inicia seu contêiner por meio do docker-compose, ele criará automaticamente a pasta e a preencherá com o conteúdo do contêiner. Se você criou uma pasta de configuração vazia em seu host, ela será montada e a pasta dentro do contêiner estará vazia.

Por que funciona

Não há muito nesta parte. Principalmente, é como iniciar qualquer outro contêiner com docker-compose. O que você deve observar aqui é que você está vinculando as portas 80 e 443. É aqui que todas as solicitações entrarão e serão encaminhadas para qualquer serviço que você especificar.

Configurando o Nginx

O que fazer

Agora, você deve ter uma pasta de configuração em seu host. Mudando para esse diretório, você deve ver vários arquivos diferentes e uma pasta chamada conf.d. É dentro de conf.d que serão colocados todos os seus arquivos de configuração. No momento, há um único arquivo default.conf. Você pode excluí-lo sem problemas.

Ainda dentro de conf.d, crie duas pastas: sites-available e sites-enabled. Navegue até sites-available e crie seu primeiro arquivo de configuração. Aqui, vamos configurar uma entrada para o Plex, mas sinta-se à vontade para usar outro serviço que você configurou, se desejar. Realmente não importa como o arquivo é chamado. Porém, prefiro chamá-lo de plex.conf.

Abra o arquivo e digite o seguinte:

upstream plex {
  server        plex:32400;
}

server {
  listen        80;
  server_name   plex.exemplo.com;

  location / {
    proxy_pass  http://plex;
  }
}

Entre no diretório sites-enabled e digite o seguinte comando:

ln -s ../sites-available/plex.conf .

Isso criará um link simbólico para o arquivo na outra pasta. Resta apenas uma coisa, que é mudar o arquivo nginx.conf na pasta config. Se você abrir o arquivo, deverá ver o seguinte como a última linha:

include /etc/nginx/conf.d/*.conf;

Altere isso para:

include /etc/nginx/conf.d/sites-enabled/*.conf;

Para que o proxy reverso realmente funcione, precisamos recarregar o serviço nginx dentro do contêiner. No host, execute docker exec <nome-do-contêiner> nginx -t. Isso executará um verificador de sintaxe em seus arquivos de configuração. Isso deve mostrar que a sintaxe está correta. Agora, execute docker exec <nome-do-contêiner> nginx -s reload. Isso enviará um sinal para o processo nginx de que ele deve recarregar. Parabéns! Agora você tem um proxy reverso em execução e deve conseguir acessar seu servidor em plex.exemplo.com (assumindo que você encaminhou a porta 80 para seu host em seu roteador).

Mesmo que seu proxy reverso esteja funcionando, você está executando em HTTP, que não fornece criptografia alguma. A próxima parte será como proteger seu proxy e obter uma pontuação perfeita no SSL Labs.

Por que funciona

O arquivo de configuração

Como você pode ver, o arquivo plex.conf consiste em duas partes. Uma parte upstream e uma parte server. Vamos começar com a parte server. É aqui que você está definindo a porta em que recebe as solicitações de entrada, qual domínio essa configuração deve corresponder e para onde deve ser enviada.

Da forma como este servidor está sendo configurado, você deve criar um arquivo para cada serviço para o qual deseja fazer solicitações de proxy. Então, obviamente, você precisa de alguma maneira de distinguir qual arquivo receberá cada solicitação. É isso que a diretiva server-name faz. Abaixo disso, temos a diretiva location.

No nosso caso, só precisamos de uma location, mas você pode ter quantas diretivas location quiser. Imagine que você tenha um site com um front-end e um back-end. Dependendo da infraestrutura que estiver usando, você terá o front-end como um contêiner e o back-end como outro contêiner. Você poderia então ter location / {}, que enviará solicitações para o front-end, e location /api/ {}, que enviará solicitações para o back-end. De repente, você tem vários serviços em execução em um único domínio memorável.

Quanto à parte de upstream, ela pode ser usada para balanceamento de carga. Se você estiver interessado em saber mais sobre como isso funciona, consulte a documentação oficial aqui. Para o nosso caso simples, você apenas define o nome do host ou endereço IP do serviço para o qual deseja fazer proxy, e qual porta deve ser a proxy. Em seguida, direcione ao nome do upstream na diretiva location.

Nome do host x endereço IP

Para entender o que é um hostname, vamos pensar em um exemplo. Digamos que você esteja em sua rede doméstica 192.168.1.0. Você, então, configura um servidor em 192.168.1.10 e executa o Plex nele. Agora, você pode acessar o Plex em 192.168.1.10:32400, desde que ainda esteja na mesma rede. Outra possibilidade é dar ao servidor um nome de host. Nesse caso, daremos o nome de host plex. Agora, você pode acessar o Plex digitando plex:32400 no seu navegador!

Esse mesmo conceito foi introduzido no docker-compose na versão 3. Se você observar o arquivo docker-compose anteriormente neste artigo, notará que dei a ele uma diretiva hostname: reverse. Agora todos os outros contêineres podem acessar meu proxy reverso por seu nome de host. Uma coisa que é muito importante observar é que o nome do serviço deve ser o mesmo que o nome do host. Isso é algo que os criadores do docker-compose escolheram impor.

Outra coisa realmente importante a ser lembrada é que, por padrão, os contêineres do docker são colocados em sua própria rede. Isso significa que você não poderá acessar seu contêiner pelo nome do host, se estiver usando o laptop na rede do host. São apenas os contêineres que podem acessar uns aos outros por meio de seu nome de host.

Então, para resumir e deixar bem claro. Em seu arquivo docker-compose, adicione a diretiva hostname aos seus serviços. Na maioria das vezes, seus contêineres receberão um novo IP toda vez que você reiniciar o contêiner. Portanto, referir-se a ele por meio do nome do host significa que não importa qual IP seu contêiner está recebendo.

sites-available e sites-enabled

Por que estamos criando os diretórios sites-available e sites-enabled? Isso não é algo da minha criação. Se você instalar o Nginx em um servidor, verá que ele vem com essas pastas. No entanto, como o Docker é construído com microsserviços em mente, onde um contêiner deve fazer apenas uma coisa, essas pastas são omitidas no contêiner. Estamos recriando-as novamente, por causa da maneira como estamos usando o contêiner.

E, sim, você definitivamente pode criar uma pasta sites-enabled ou hospedar diretamente seus arquivos de configuração em conf.d. Fazendo desta forma, você pode ter uma configuração passiva. Digamos que você está fazendo a manutenção e não quer ter o serviço ativo; você simplesmente remove o link simbólico e o coloca de volta quando quiser que o serviço fique ativo novamente.

Links simbólicos

Links simbólicos são um recurso muito poderoso do sistema operacional. Eu pessoalmente nunca os usei antes de configurar um servidor Nginx, mas desde então os tenho usado em todos os lugares que posso. Digamos que você esteja trabalhando em 5 projetos diferentes, mas todos esses projetos usam o mesmo arquivo de alguma forma. Você pode copiar o arquivo em cada projeto e consultá-lo diretamente, ou pode colocar o arquivo em um local e, nesses 5 projetos, criar links simbólicos para esse arquivo.

Isso oferece duas vantagens: você ocupa 4 vezes menos espaço do que teria de outra forma e - o motivo mais poderoso de todos: muda o arquivo em um só lugar e ele muda em todos os 5 projetos de uma vez! Isso não tem muito a ver com o tópico do artigo, mas acho que vale a pena mencionar.

Protegendo o proxy Nginx

O que fazer

Vá para sua pasta de configuração, crie 3 arquivos e preencha-os com o seguinte :

common.conf:

add_header Strict-Transport-Security    "max-age=31536000; includeSubDomains" always;
add_header X-Frame-Options              SAMEORIGIN;
add_header X-Content-Type-Options       nosniff;
add_header X-XSS-Protection             "1; mode=block";

common_location.conf:

proxy_set_header    X-Real-IP           $remote_addr;
proxy_set_header    X-Forwarded-For     $proxy_add_x_forwarded_for;
proxy_set_header    X-Forwarded-Proto   $scheme;
proxy_set_header    Host                $host;
proxy_set_header    X-Forwarded-Host    $host;
proxy_set_header    X-Forwarded-Port    $server_port;

ssl.conf:

ssl_protocols               TLSv1 TLSv1.1 TLSv1.2;
ssl_ecdh_curve              secp384r1;
ssl_ciphers                 "ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384 OLD_TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 OLD_TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256";
ssl_prefer_server_ciphers   on;
ssl_dhparam                 /etc/nginx/dhparams.pem;
ssl_certificate             /etc/ssl/private/fullchain.pem;
ssl_certificate_key         /etc/ssl/private/privkey.pem;
ssl_session_timeout         10m;
ssl_session_cache           shared:SSL:10m;
ssl_session_tickets         off;
ssl_stapling                on;
ssl_stapling_verify         on;

Agora, abra o arquivo plex.conf e altere-o para o seguinte (observe as linhas 6, 9, 10 e 14):

upstream plex {
  server        plex:32400;
}

server {
  listen        443 ssl;
  server_name   plex.example.com;

  include       common.conf;
  include       /etc/nginx/ssl.conf;

  location / {
    proxy_pass  http://plex;
    include     common_location.conf;
  }
}

Agora, volte para a raiz da sua pasta de configuração e execute o seguinte comando:

openssl dhparam -out dhparams.pem 4096

Isso levará muito tempo para ser concluído (até uma hora, em alguns casos).

Se você seguiu meu artigo sobre como obter um certificado SSL LetsEncrypt, seus certificados devem estar localizados em </caminho/para/seu/letsencrypt/config>/etc/letsencrypt/live/<domínio>/.

Quando ajudei um amigo a configurar isso em seu sistema, tivemos alguns problemas em que não foi possível abrir os arquivos quando eles estavam localizados nesse diretório. Provavelmente, a causa disso foram alguns problemas de permissões. A solução fácil para isso é criar um diretório SSL, como </caminho/para/seu/nginx/config>/certs, e montá-lo na pasta /etc/ssl/private do contêiner Nginx. Na pasta recém-criada, você deve criar links simbólicos para os certificados na pasta de configuração do LetsEncrypt.

Quando o comando openssl terminar de ser executado, você deve executar o docker exec <nome-do-contêiner> nginx -t para se certificar de que toda a sintaxe está correta e, em seguida, recarregá-lo executando docker exec <nome-do-contêiner> nginx -s reload. Neste ponto, tudo deve estar funcionando e, agora, você tem um proxy reverso funcionando e perfeitamente seguro!

Por que funciona

Olhando no arquivo plex.conf, há apenas uma grande mudança - em qual porta o proxy reverso está escutando e informando que é uma conexão SSL. Depois, há 3 lugares onde estamos incluindo os outros 3 arquivos que criamos. Embora o SSL seja, de certo modo, seguro por si só, esses outros arquivos o tornam ainda mais seguro. No entanto, se por algum motivo você não quiser incluir esses arquivos, será necessário mover o ssl-certificate e ssl-certificate-key dentro do  arquivo.conf. Eles são necessários para que uma conexão HTTPS funcione.

Common.conf

Olhando no arquivo common.conf, adicionamos 4 cabeçalhos diferentes. Os cabeçalhos são algo que o servidor envia ao navegador em cada resposta. Esses cabeçalhos dizem ao navegador para agir de uma determinada maneira e, então, cabe ao navegador impor esses cabeçalhos.

Strict-Transport-Security (HSTS)

Este cabeçalho informa ao navegador que as conexões devem ser feitas por HTTPS. Quando esse cabeçalho for adicionado, o navegador não permitirá que você faça uma conexão HTTP simples com o servidor, garantindo que toda a comunicação seja segura.

X-Frame-Options

Ao especificar esse cabeçalho, você especifica se outros sites podem ou não incorporar seu conteúdo em seus sites. Isso pode ajudar a evitar ataques de clickjacking.

X-Content-Type-Options

Digamos que você tenha um site onde os usuários possam fazer upload de arquivos. Não há validação suficiente nos arquivos, então um usuário carrega com sucesso um arquivo php para o servidor, onde o servidor espera que uma imagem seja carregada. O invasor pode então acessar o arquivo carregado. Agora, o servidor responde com uma imagem, porém o tipo MIME do arquivo é text/plain. O navegador fará o 'sniffing' do arquivo e renderizará o script php, permitindo que o invasor faça RCE (Remote Code Execution).

Com este cabeçalho definido como 'nosniff', o navegador não examinará o arquivo e simplesmente o renderizará como o que o servidor disser ao navegador que ele é.

X-XSS-Protection

Embora esse cabeçalho fosse mais necessário em navegadores mais antigos, é tão fácil de adicionar que você também pode. Alguns ataques XSS (Cross-site Scripting) podem ser muito inteligentes, enquanto alguns são muito rudimentares. Este cabeçalho dirá aos navegadores para verificar as vulnerabilidades simples e bloqueá-las.

Common_location.conf

X-Real-IP

Como seus servidores estão atrás de um proxy reverso, se você tentar ver o IP solicitante, sempre verá o IP do proxy reverso. Este cabeçalho é adicionado para que você possa ver qual IP está realmente solicitando seu serviço.

X-Forwarded-For

Às vezes, uma solicitação de usuário passará por vários clients antes de chegar ao seu servidor. Este cabeçalho inclui um array de todos esses clients.

X-Forwarded-Proto

Este cabeçalho mostrará qual protocolo está sendo usado entre client e servidor.

Host

Isso garante que seja possível fazer uma pesquisa de DNS reversa no nome de domínio. É usado quando a diretiva server_name é diferente daquela para a qual você está fazendo proxy.

X-Forwarded-Host

Mostra qual é o host real da solicitação em vez do proxy reverso.

X-Forwarded-Port

Ajuda a identificar em qual porta o client solicitou o servidor.

SSL.conf

SSL é um tópico enorme por si só, e grande demais para começar a explicar neste artigo. Existem muitos tutoriais excelentes sobre como os handshakes de SSL funcionam e assim por diante. Se você quiser examinar esse arquivo específico, sugiro examinar os protocolos e cifras que estão sendo usados ​​e qual a diferença que eles fazem.

Redirecionando HTTP para HTTPS

Os observadores talvez tenham notado que estamos ouvindo apenas na porta 443 nesta versão segura. Isso significaria que qualquer pessoa que tentasse acessar o site via https://* passaria, mas tentar se conectar através de http://* receberia apenas um erro. Felizmente, há uma solução muito fácil para isso. Crie um arquivo redirect.conf com o seguinte conteúdo:

server {
  listen        80;

  server_name   _;

  return 301 https://$host$request_uri;
}

Agora, apenas certifique-se de que ele apareça em sua pasta sites-enabled e, quando você recarregar o processo Nginx no contêiner, todas as solicitações para a porta 80 serão redirecionadas para a porta 443 (HTTPS).

Pensamentos finais

Agora que seu site está funcionando, você pode acessar o SSL Labs e fazer um teste para ver o nível de segurança de seu site. No momento em que escrevo isso, você deve obter uma pontuação perfeita. No entanto, há algo importante a se notar sobre isso.

Sempre haverá um equilíbrio entre segurança e conveniência. Neste caso, os pesos estão muito do lado da segurança. Se você executar o teste no SSL Labs e rolar para baixo, verá que há vários dispositivos que não poderão se conectar ao seu site porque não suportam novos padrões.

Portanto, tenha isso em mente quando estiver fazendo essa configuração. No momento, estou apenas executando um servidor em casa, onde não preciso me preocupar com tantas pessoas podendo acessá-lo. Mas se você fizer uma varredura no Facebook, verá que o site não terá uma pontuação tão boa, porém pode ser acessado por mais dispositivos.

O Vim é um editor de código poderoso. Tão poderoso que tanto o Linux quanto o Mac o têm instalado por padrão.

Mas se você estiver usando o Windows como sistema operacional, precisará instalar o Vim separadamente.

Felizmente, a Microsoft torna muito fácil instalar o Vim e executá-lo no seu PC.

Como baixar o Vim

Você pode baixar a versão mais recente do Vim Text Editor diretamente do próprio Vim.

Eles criaram um instalador autoexecutável especial, que o orienta no processo de instalação do Vim no local certo em seu disco rígido.

Como instalar o Vim

Observe que, para o Windows, você tecnicamente baixará algo chamado gVim, que é uma versão do Vim que inclui uma interface gráfica de usuário básica (GUI). Você pode instalá-la baixando este instalador executável .

Depois de baixar o arquivo, basta executá-lo e você verá um assistente de instalação idêntico ao mostrado abaixo:

Eles têm uma instalação "típica" recomendada. mas se você tiver um disco rígido razoavelmente grande, não há mal nenhum em prosseguir com a instalação de tudo escolhendo a opção "completo":

Como executar o Vim no PowerShell

Então, depois de instalar o Vim, você poderá iniciá-lo no prompt de comando do Windows.

Observe que, a partir de 2020, o PowerShell tem todas as mesmas funcionalidades do CMD, além de muito mais. Eu recomendo usar o PowerShell para tudo.

Você pode abrir o PowerShell na barra de menus do Windows digitando "powershell" no campo de pesquisa na barra inicial.

O Windows abrirá o PowerShell e você receberá um prompt de comando semelhante a este:

Veja aqui como executar o Vim quando estiver no PowerShell. Tudo o que você precisa fazer é digitar "vim" e pressionar Enter. Isso abrirá o Vim. Uma vez que o Vim estiver aberto, isto é o que você deve ver:

Parabéns – agora você tem o Vim instalado.

Como executar o Vim dentro do VS Code

Se você já está usando o VS Code, e quer a grande velocidade do Vim sem perder a funcionalidade do VS Code, tenho boas notícias. É possível executar uma experiência semelhante ao Vim diretamente no VS Code.

Aqui está um plug-in do Vim para o VS Code que o ajudará a fazer isso. No momento em que escrevi este artigo, o plug-in já havia sido instalado quase 2 milhões de vezes.

Como aprender a usar o Vim corretamente

O Vim é um editor de código poderoso e você precisará de muita prática para se acostumar com ele.

Aqui estão alguns tutoriais do Vim que realmente ajudarão você a entender rapidamente o básico e fazer seus dedos voarem rapidamente.

Para começar, uma maneira que o Vim é diferente de outros editores de código é que o Vim tem "modos". Aqui estão todos os modos do Vim explicados, com exemplos (texto em inglês).

O Vim pode ser intimidante. Há muito o que aprender. Mas este guia mostrará como não ter mais medo do Vim (texto em inglês).

Se você já estiver usando o VS Code e quiser mudar completamente para o Vim, este artigo explicará como você pode fazer isso (texto em inglês).

E aqui estão 7 dicas do Vim que mudaram a vida do criador do #100DaysOfCode, Alex Kallaway (texto em inglês). Neste artigo, ele não apenas explica isso, mas mostra demonstrações dessas dicas em ação.

Vim: aprenda, viva, ame.

Nos 30 anos desde que Bram Moolenaar criou o Vim, sua influência se espalhou por toda parte. Ainda hoje, o projeto Vim é mantido ativamente e melhorando constantemente.

Eu conheci tantos desenvolvedores ao longo dos anos que botam a mão no fogo pelo Vim.

Espero que este guia tenha ajudado você a executar o Vim no seu PC com Windows. E espero que esses outros tutoriais que compartilhei com você aqui ajudem você a ir do zero à prática nos próximos meses.

A chave é continuar praticando e não desanimar com a quantidade de atalhos a serem lembrados no Vim. Eventualmente, tudo isso se tornará memória muscular, e você estará voando de um arquivo para outro, acabando com qualquer código, feito um exterminador.

Não há sensação tão legal quanto a de ser capaz de entrar em uma base de código e começar imediatamente a fazer alterações sem sequer pegar um mouse ou trackpad. Esse é o poder que o Vim promete e entrega com sobras.

SQL significa Linguagem de Consulta Estruturada (Structured Query Language em inglês). Os comandos SQL são as instruções usadas para se comunicar com um banco de dados para executar tarefas, funções e consultas com dados.

Os comandos do SQL podem ser usados ​​para pesquisar o banco de dados e realizar outras funções, como criar tabelas, adicionar dados a tabelas, modificar dados e descartar tabelas.

Aqui está uma lista de comandos SQL básicos (às vezes chamados de instruções) que você deve saber se vai trabalhar com SQL.

SELECT e FROM

A parte SELECT (selecionar, em inglês) de uma consulta determina quais colunas dos dados serão exibidas nos resultados. Também há opções que você pode aplicar para mostrar dados que não são uma coluna da tabela.

O exemplo abaixo mostra três colunas selecionadas na tabela "student" (aluno, em inglês), para isso usamos o comando FROM (vindo de, em inglês) e uma coluna calculada. O banco de dados armazena o studentID, FirstName e LastName do aluno (id do aluno, nome e sobrenome em inglês, respectivamente). Podemos combinar as colunas FirstName e LastName para criar a coluna calculada FullName. (nome completo, em inglês)‌.

SELECT studentID, FirstName, LastName, FirstName + ' ' + LastName AS FullName
FROM student;

+-----------+-------------------+------------+------------------------+
| studentID | FirstName         | LastName   | FullName               |
+-----------+-------------------+------------+------------------------+
|         1 | Monique           | Davis      | Monique Davis          |
|         2 | Teri              | Gutierrez  | Teri Gutierrez         |
|         3 | Spencer           | Pautier    | Spencer Pautier        |
|         4 | Louis             | Ramsey     | Louis Ramsey           |
|         5 | Alvin             | Greene     | Alvin Greene           |
|         6 | Sophie            | Freeman    | Sophie Freeman         |
|         7 | Edgar Frank "Ted" | Codd       | Edgar Frank "Ted" Codd |
|         8 | Donald D.         | Chamberlin | Donald D. Chamberlin   |
|         9 | Raymond F.        | Boyce      | Raymond F. Boyce       |
+-----------+-------------------+------------+------------------------+
9 rows in set (0.00 sec)

CREATE TABLE

CREATE TABLE (criar tabela, em inglês) faz exatamente o que parece: cria uma tabela no banco de dados. Você pode especificar o nome da tabela e as colunas que devem estar nela.

CREATE TABLE nome_da_tabela (
    coluna_1 tipo_de_dados,
    coluna_2 tipo_de_dados,
    coluna_3 tipo_de_dados
);

ALTER TABLE

ALTER TABLE (alterar tabela, em inglês) altera a estrutura de uma tabela. Aqui está demonstrado como você adicionaria uma coluna a um banco de dados:

ALTER TABLE nome_da_tabela
ADD coluna tipo_de_dados;

CHECK

A instrução CHECK (verificar, em inglês) é usada para limitar o intervalo de valores que pode ser colocado em uma coluna.

Se você definir uma instrução CHECK em uma única coluna, ela permitirá apenas determinados valores para essa coluna. Se você definir uma instrução CHECK em uma tabela, ela poderá limitar os valores em determinadas colunas com base nos valores de outras colunas dessa linha.

O SQL a seguir cria uma instrução CHECK na coluna "Age" (idade, em inglês) quando a tabela "Persons" (pessoas, em inglês) é criada. CHECK garante que você não tenha pessoas com menos de 18 anos.‌

CREATE TABLE Persons (
    ID int NOT NULL,
    LastName varchar(255) NOT NULL,
    FirstName varchar(255),
    Age int,
    CHECK (Age>=18)
);

Para permitir a nomeação de uma instrução CHECK e para definir uma instrução CHECK em várias colunas, use a seguinte sintaxe no SQL:

CREATE TABLE Persons (
    ID int NOT NULL,
    LastName varchar(255) NOT NULL,
    FirstName varchar(255),
    Age int,
    City varchar(255),
    CONSTRAINT CHK_Person CHECK (Age>=18 AND City='Sandnes')
);

‌WHERE

(AND ,OR , IN, BETWEEN e LIKE)

A instrução WHERE (onde, em inglês) é usada para limitar o número de linhas retornadas.

Como exemplo, primeiro mostraremos uma instrução SELECT e resultados sem declaração WHERE. Em seguida, adicionaremos uma instrução WHERE que usa todos os cinco qualificadores acima.‌  

SELECT studentID, FullName, sat_score, rcd_updated FROM student;

+-----------+------------------------+-----------+---------------------+
| studentID | FullName               | sat_score | rcd_updated         |
+-----------+------------------------+-----------+---------------------+
|         1 | Monique Davis          |       400 | 2017-08-16 15:34:50 |
|         2 | Teri Gutierrez         |       800 | 2017-08-16 15:34:50 |
|         3 | Spencer Pautier        |      1000 | 2017-08-16 15:34:50 |
|         4 | Louis Ramsey           |      1200 | 2017-08-16 15:34:50 |
|         5 | Alvin Greene           |      1200 | 2017-08-16 15:34:50 |
|         6 | Sophie Freeman         |      1200 | 2017-08-16 15:34:50 |
|         7 | Edgar Frank "Ted" Codd |      2400 | 2017-08-16 15:35:33 |
|         8 | Donald D. Chamberlin   |      2400 | 2017-08-16 15:35:33 |
|         9 | Raymond F. Boyce       |      2400 | 2017-08-16 15:35:33 |
+-----------+------------------------+-----------+---------------------+
9 rows in set (0.00 sec)

Agora, repetiremos a consulta SELECT, mas limitaremos as linhas retornadas usando uma instrução WHERE.

STUDENT studentID, FullName, sat_score, recordUpdated
FROM student
WHERE (studentID BETWEEN 1 AND 5 OR studentID = 8)
        AND
        sat_score NOT IN (1000, 1400);

+-----------+----------------------+-----------+---------------------+
| studentID | FullName             | sat_score | rcd_updated         |
+-----------+----------------------+-----------+---------------------+
|         1 | Monique Davis        |       400 | 2017-08-16 15:34:50 |
|         2 | Teri Gutierrez       |       800 | 2017-08-16 15:34:50 |
|         4 | Louis Ramsey         |      1200 | 2017-08-16 15:34:50 |
|         5 | Alvin Greene         |      1200 | 2017-08-16 15:34:50 |
|         8 | Donald D. Chamberlin |      2400 | 2017-08-16 15:35:33 |
+-----------+----------------------+-----------+---------------------+
5 rows in set (0.00 sec)

UPDATE

Para atualizar um registro em uma tabela, você usa a instrução UPDATE (atualizar, em inglês).

Use a instrução WHERE para especificar quais registros você deseja atualizar. É possível atualizar uma ou mais colunas por vez. A sintaxe é:‌

UPDATE nome_da_tabela
SET coluna1 = valor1, 
    coluna2 = valor2, ...
WHERE condição;

Aqui está um exemplo atualizando Name (nome, em inglês) do registro com Id 4:‌  

UPDATE Person
SET Name = "Elton John"
WHERE Id = 4;

Você também pode atualizar colunas em uma tabela usando valores de outras tabelas. Use a instrução JOIN (unir, em inglês) para obter dados de várias tabelas. A sintaxe é:

UPDATE nome_da_tabela1
SET nome_da_tabela1.coluna1 = nome_da_tabela2.colunaA
    nome_da_tabela1.coluna2 = nome_da_tabela2.colunaB
FROM nome_da_tabela1
JOIN nome_da_tabela2 ON nome_da_tabela1.ChaveEstrangeira = nome_da_tabela2.Chave

Aqui está um exemplo de atualização de Manager (gerenciador, em inglês) de todos os registros:‌      

UPDATE Person
SET Person.Manager = Department.Manager
FROM Person
JOIN Department ON Person.DepartmentID = Department.ID

GROUP BY

GROUP BY (agrupar por, em inglês) permite combinar linhas e agregar dados.

Aqui está a sintaxe de GROUP BY:‌    

SELECT nome_da_coluna, COUNT(*)
FROM nome_da_tabela
GROUP BY nome_da_coluna;

HAVING

HAVING (contendo, em inglês) permite filtrar os dados agregados pela instrução GROUP BY para que o usuário obtenha um conjunto limitado de registros para visualização.

Aqui está a sintaxe de HAVING:‌  

SELECT nome_da_coluna, COUNT(*)
FROM nome_da_tabela
GROUP BY nome_da_coluna
HAVING COUNT(*) > valor;

AVG()

"Average" (média, em inglês) é usado para calcular a média de uma coluna numérica do conjunto de linhas retornado por uma instrução SQL.

Aqui está a sintaxe para usar a função:‌

SELECT campoAgrupamento, AVG(num_campo)
FROM tabela1
GROUP BY campoAgrupamento

Aqui está um exemplo usando a tabela de alunos:‌  

SELECT studentID, FullName, AVG(sat_score) 
FROM student 
GROUP BY studentID, FullName;

AS

AS (como, em inglês - similar a like, que vemos posteriormente) permite renomear uma coluna ou tabela usando um alias.‌  

SELECT user_only_num1 AS AgeOfServer, (user_only_num1 - warranty_period) AS NonWarrantyPeriod FROM server_table

Isso resulta na saída abaixo.‌

+-------------+------------------------+
| AgeOfServer | NonWarrantyPeriod      | 
+-------------+------------------------+
|         36  |                     24 |
|         24  |                     12 | 
|         61  |                     49 |
|         12  |                      0 | 
|          6  |                     -6 |
|          0  |                    -12 | 
|         36  |                     24 |
|         36  |                     24 | 
|         24  |                     12 | 
+-------------+------------------------+

Você também pode usar AS para atribuir um nome a uma tabela para facilitar a referência em junções.‌  

SELECT ord.product, ord.ord_number, ord.price, cust.cust_name, cust.cust_number FROM customer_table AS cust

JOIN order_table AS ord ON cust.cust_number = ord.cust_number

Isso resulta na saída como abaixo.

+-------------+------------+-----------+-----------------+--------------+
| product     | ord_number | price     | cust_name       | cust_number  |
+-------------+------------+-----------+-----------------+--------------+
|     RAM     |   12345    |       124 | John Smith      |  20          |
|     CPU     |   12346    |       212 | Mia X           |  22          |
|     USB     |   12347    |        49 | Elise Beth      |  21          |
|     Cable   |   12348    |         0 | Paul Fort       |  19          |
|     Mouse   |   12349    |        66 | Nats Back       |  15          |
|     Laptop  |   12350    |       612 | Mel S           |  36          |
|     Keyboard|   12351    |        24 | George Z        |  95          |
|     Keyboard|   12352    |        24 | Ally B          |  55          |
|     Air     |   12353    |        12 | Maria Trust     |  11          |
+-------------+------------+-----------+-----------------+--------------+

ORDER BY

ORDER BY (ordenar por, em inglês) nos dá uma maneira de classificar o conjunto de resultados por um ou mais itens na seção SELECT. Aqui está um SQL classificando os alunos por FullName em ordem decrescente. A ordem de classificação padrão é crescente (ASC), mas, para classificar na ordem oposta (decrescente), você usa DESC.‌  

SELECT studentID, FullName, sat_score
FROM student
ORDER BY FullName DESC;

COUNT

COUNT (contar, em inglês) contará o número de linhas e retornará essa contagem como uma coluna no conjunto de resultados.

Aqui estão alguns exemplos onde você usaria COUNT:

• Para contar todas as linhas em uma tabela (GROUP BY não é obrigatório)
• Para contar os totais de subconjuntos de dados (requer um GROUP BY na instrução)

Essa instrução SQL fornece uma contagem de todas as linhas. Observe que você pode dar um nome à coluna COUNT resultante usando "AS".‌  

SELECT count(*) AS studentCount FROM student; 

DELETE

DELETE (excluir, em inglês) é usado para excluir um registro em uma tabela.

Tome cuidado. Você pode excluir todos os registros da tabela ou apenas alguns deles. Use a condição WHERE para especificar quais registros você deseja excluir. A sintaxe é:‌

DELETE FROM table_name
WHERE condition;

Aqui está um exemplo de exclusão do registro com Id 3 na tabela Person:‌

DELETE FROM Person
WHERE Id = 3;

INNER JOIN

JOIN (junção, em inglês), também chamado de inner join (junção interna, em inglês), seleciona registros que têm valores correspondentes em duas tabelas.‌  

SELECT * FROM A x JOIN B y ON y.aId = x.Id

LEFT JOIN

A LEFT JOIN (junção à esquerda, em inglês) retorna todas as linhas da tabela da esquerda e as linhas correspondentes da tabela da direita. As linhas na tabela da esquerda serão retornadas mesmo que não haja correspondência na tabela da direita. As linhas da tabela à esquerda sem correspondência na tabela à direita terão os valores da tabela à direita null.‌

SELECT * FROM A x LEFT JOIN B y ON y.aId = x.Id

‌RIGHT JOIN

A RIGHT JOIN (junção à direita, em inglês) retorna todas as linhas da tabela da direita e as linhas correspondentes da tabela da esquerda. Ao contrário de uma junção à esquerda, isso retornará todas as linhas da tabela à direita, mesmo quando não houver correspondência na tabela à esquerda. As linhas na tabela à direita que não têm correspondência na tabela à esquerda terão valores null para as colunas da tabela à esquerda.‌

SELECT * FROM A x RIGHT JOIN B y ON y.aId = x.Id

FULL OUTER JOIN

A FULL OUTER JOIN (junção externa completa, em inglês) retorna todas as linhas para as quais haja uma correspondência em qualquer uma das tabelas. Portanto, se houver linhas na tabela da esquerda que não tenham correspondência na tabela da direita, elas serão incluídas. Além disso, se houver linhas na tabela à direita que não tenham correspondência na tabela à esquerda, elas também o serão.‌

SELECT Customers.CustomerName, Orders.OrderID
FROM Customers
FULL OUTER JOIN Orders
ON Customers.CustomerID=Orders.CustomerID
ORDER BY Customers.CustomerName

INSERT

INSERT (inserir, em inglês) é uma maneira de inserir dados em uma tabela.‌

INSERT INTO nome_da_tabela (coluna_1, coluna_2, coluna_3) 
VALUES (valor_1, 'valor_2', valor_3);

LIKE

LIKE  (como, em inglês - comparar com "as" acima) é usado em uma instrução com WHERE ou HAVING(como parte de GROUP BY) para limitar as linhas selecionadas aos itens quando uma coluna possui um determinado padrão de caracteres contido nela.

Este SQL selecionará os alunos que tem FullName começando com "Monique" ou que terminam com "Greene".‌    

SELECT studentID, FullName, sat_score, rcd_updated
FROM student 
WHERE 
    FullName LIKE 'Monique%' OR 
    FullName LIKE '%Greene'; 

+-----------+---------------+-----------+---------------------+
| studentID | FullName      | sat_score | rcd_updated         |
+-----------+---------------+-----------+---------------------+
|         1 | Monique Davis |       400 | 2017-08-16 15:34:50 |
|         5 | Alvin Greene  |      1200 | 2017-08-16 15:34:50 |
+-----------+---------------+-----------+---------------------+
2 rows in set (0.00 sec)

Você pode colocar NOT antes de LIKE para excluir as linhas com o padrão de string em vez de selecioná-las. Esse SQL exclui registros que contenham "encer Pauti" e "Ted" na coluna FullName.‌    

SELECT studentID, FullName, sat_score, rcd_updated
FROM student 
WHERE FullName NOT LIKE '%encer Pauti%' AND FullName NOT LIKE '%"Ted"%';

+-----------+----------------------+-----------+---------------------+
| studentID | FullName             | sat_score | rcd_updated         |
+-----------+----------------------+-----------+---------------------+
|         1 | Monique Davis        |       400 | 2017-08-16 15:34:50 |
|         2 | Teri Gutierrez       |       800 | 2017-08-16 15:34:50 |
|         4 | Louis Ramsey         |      1200 | 2017-08-16 15:34:50 |
|         5 | Alvin Greene         |      1200 | 2017-08-16 15:34:50 |
|         6 | Sophie Freeman       |      1200 | 2017-08-16 15:34:50 |
|         8 | Donald D. Chamberlin |      2400 | 2017-08-16 15:35:33 |
|         9 | Raymond F. Boyce     |      2400 | 2017-08-16 15:35:33 |
+-----------+----------------------+-----------+---------------------+
7 rows in set (0.00 sec)

‌Atualização: este artigo agora faz parte do livro do autor, "Node.js Beyond The Basics". Leia a versão atualizada deste conteúdo (em inglês) e mais sobre o Node em jcomplete.com/node-beyond-basics .

O Node usa dois módulos principais para gerenciar as dependências de módulos:

• O módulo require, que parece estar disponível no escopo global — não há necessidade de require('require').
• O módulo module, que também parece estar disponível no escopo global — não há necessidade de require('module').

Você pode pensar no módulo require como um comando e no módulo module como um organizador de todos os módulos necessários.

Requisitar um módulo no Node não é um conceito tão complicado.

const config = require('/path/to/file');

‌O objeto principal exportado pelo módulo require é uma função (conforme usado no exemplo acima). Quando o Node invoca essa função require() com um caminho de arquivo local como único argumento da função, o Node passa pela seguinte sequência de etapas:

• Resolver: para encontrar o caminho absoluto do arquivo.
• Carregar: para determinar o tipo de conteúdo do arquivo.
• Envolver (Wrapping): para dar ao arquivo seu escopo privado. Isso é o que torna os objetos locais require e module para cada arquivo que precisamos.
• Avaliar: isso é o que a VM eventualmente faz com o código carregado.
• Colocar em cache: para que, quando precisarmos desse arquivo novamente, não passemos por todas as etapas outra vez.

Neste artigo, tentarei explicar com exemplos esses diferentes estágios e como eles afetam a maneira como escrevemos módulos no Node.

Deixe-me primeiro criar um diretório para hospedar todos os exemplos usando meu terminal:

mkdir ~/learn-node && cd ~/learn-node

‌Todos os comandos no restante deste artigo serão executados de dentro do diretório ~/learn-node.

Resolvendo um caminho local

Quero apresentá-lo ao objeto module. Você pode verificá-lo em uma sessão simples do REPL:

~/learn-node $ node
> module
Module {
  id: '<repl>',
  exports: {},
  parent: undefined,
  filename: null,
  loaded: false,
  children: [],
  paths: [ ... ] }

‌Cada objeto de módulo recebe uma propriedade id para identificá-lo. Este id é geralmente o caminho completo para o arquivo, mas, em uma sessão REPL, ele é simplesmente <repl>.  

Os módulos do Node têm uma relação de um-para-um com arquivos no sistema de arquivos. Requisitamos um módulo carregando o conteúdo de um arquivo na memória.

No entanto, como o Node permite muitas maneiras de requisitar um arquivo (por exemplo, com um caminho relativo ou um caminho pré-configurado), antes de podermos carregar o conteúdo de um arquivo na memória, precisamos encontrar a localização absoluta desse arquivo.

Quando requisitamos um módulo 'find-me', sem especificar um caminho:

require('find-me');

O Node procurará find-me.js em todos os caminhos especificados por module.paths— em ordem.

~/learn-node $ node
> module.paths
[ '/Users/samer/learn-node/repl/node_modules',
  '/Users/samer/learn-node/node_modules',
  '/Users/samer/node_modules',
  '/Users/node_modules',
  '/node_modules',
  '/Users/samer/.node_modules',
  '/Users/samer/.node_libraries',
  '/usr/local/Cellar/node/7.7.1/lib/node' ]

A lista de caminhos é basicamente uma lista de diretórios node_modules que se encontra em cada diretório, começando do diretório atual e chegando até o diretório raiz. Ela também inclui alguns diretórios legados, cujo uso não é recomendado.

Se o Node não puder encontrar find-me.js em nenhum desses caminhos, ele lançará um erro dizendo que o módulo não foi encontrado.

~/learn-node $ node
> require('find-me')
Error: Cannot find module 'find-me'
    at Function.Module._resolveFilename (module.js:470:15)
    at Function.Module._load (module.js:418:25)
    at Module.require (module.js:498:17)
    at require (internal/module.js:20:19)
    at repl:1:1
    at ContextifyScript.Script.runInThisContext (vm.js:23:33)
    at REPLServer.defaultEval (repl.js:336:29)
    at bound (domain.js:280:14)
    at REPLServer.runBound [as eval] (domain.js:293:12)
    at REPLServer.onLine (repl.js:533:10)

Se você agora criar um diretório local node_modules e colocar um find-me.js lá, a linha require('find-me') o encontrará.

~/learn-node $ mkdir node_modules 

~/learn-node $ echo "console.log('I am not lost');" > node_modules/find-me.js

~/learn-node $ node
> require('find-me');
I am not lost
{}
>

‌Se existir outro arquivo find-me.js em qualquer um dos outros caminhos – por exemplo, se tivermos um diretório node_modules no diretório inicial e se tivermos um arquivo find-me.js diferente lá:

$ mkdir ~/node_modules
$ echo "console.log('I am the root of all problems');" > ~/node_modules/find-me.js

Quando usamos require('find-me') dentro do diretório learn-node, que tem seu próprio node_modules/find-me.js, o arquivo find-me.js no diretório inicial não será carregado:

~/learn-node $ node
> require('find-me')
I am not lost
{}
>

‌Se removermos o diretório local node_modules de ~/learn-node e se tentarmos solicitar find-me mais uma vez, o arquivo no node_modules diretório home será usado:

~/learn-node $ rm -r node_modules/
~/learn-node $ node
> require('find-me')
I am the root of all problems
{}
>

Solicitando uma pasta

Os módulos não precisam ser arquivos. Também podemos criar uma pasta find-me em node_modules e colocar um arquivo index.js lá. A linha require('find-me') usará o arquivo index.js dessa pasta:

~/learn-node $ mkdir -p node_modules/find-me

~/learn-node $ echo "console.log('Found again.');" > node_modules/find-me/index.js

~/learn-node $ node
> require('find-me');
Found again.
{}
>

Observe como ele ignorou o caminho do diretório inicial node_modules novamente, pois agora temos um local.

Um arquivo index.js será usado por padrão quando precisarmos de uma pasta, mas podemos controlar com qual nome de arquivo começar na pasta usando a propriedade main no package.json. Por exemplo, para fazer com que a linha require('find-me') resolva para um arquivo diferente na pasta find-me, tudo o que precisamos fazer é adicionar um arquivo package.json e especificar qual arquivo deve ser usado para resolver esta pasta:

~/learn-node $ echo "console.log('I rule');" > node_modules/find-me/start.js

~/learn-node $ echo '{ "name": "find-me-folder", "main": "start.js" }' > node_modules/find-me/package.json

~/learn-node $ node
> require('find-me');
I rule
{}
>

‌require.resolve

Se você quiser apenas resolver o módulo e não executá-lo, você pode usar a função require.resolve. Ela se comporta exatamente da mesma forma que a função principal require, mas não carrega o arquivo. Ela ainda lançará um erro se o arquivo não existir e retornará o caminho completo para o arquivo quando encontrado.

> require.resolve('find-me');
'/Users/samer/learn-node/node_modules/find-me/start.js'
> require.resolve('not-there');
Error: Cannot find module 'not-there'
    at Function.Module._resolveFilename (module.js:470:15)
    at Function.resolve (internal/module.js:27:19)
    at repl:1:9
    at ContextifyScript.Script.runInThisContext (vm.js:23:33)
    at REPLServer.defaultEval (repl.js:336:29)
    at bound (domain.js:280:14)
    at REPLServer.runBound [as eval] (domain.js:293:12)
    at REPLServer.onLine (repl.js:533:10)
    at emitOne (events.js:101:20)
    at REPLServer.emit (events.js:191:7)
>

Isso pode ser usado, por exemplo, para verificar se um pacote opcional está instalado ou não e só usá-lo quando estiver disponível.

Caminhos relativos e absolutos

Além de resolver módulos de dentro dos diretórios node_modules, também podemos colocar o módulo em qualquer lugar que quisermos e requisitá-lo com os caminhos relativos ( ./e ../) ou com caminhos absolutos começando com /.

Se, por exemplo, o arquivo find-me.js estiver em uma pasta lib em vez da pasta node_modules, podemos requisitá-lo com:

require('./lib/find-me');

Relação pai-filho entre arquivos

Crie um arquivo lib/util.js e adicione uma linha console.log para identificá-lo. Além disso, faça um console.log com o próprio objeto module:

~/learn-node $ mkdir lib
~/learn-node $ echo "console.log('In util', module);" > lib/util.js

‌Faça o mesmo para um arquivo index.js, que executaremos com o comando node. Faça este arquivo index.js requisitar lib/util.js:

~/learn-node $ echo "console.log('In index', module); require('./lib/util');" > index.js

‌Agora execute o arquivoindex.js com o node:

~/learn-node $ node index.js
In index Module {
  id: '.',
  exports: {},
  parent: null,
  filename: '/Users/samer/learn-node/index.js',
  loaded: false,
  children: [],
  paths: [ ... ] }
In util Module {
  id: '/Users/samer/learn-node/lib/util.js',
  exports: {},
  parent:
   Module {
     id: '.',
     exports: {},
     parent: null,
     filename: '/Users/samer/learn-node/index.js',
     loaded: false,
     children: [ [Circular] ],
     paths: [...] },
  filename: '/Users/samer/learn-node/lib/util.js',
  loaded: false,
  children: [],
  paths: [...] }

‌Observe como o módulo index principal (id: '.')agora está listado como pai do módulo lib/util. No entanto, o módulo lib/util não foi listado como filho do módulo index. Em vez disso, temos o valor [Circular] lá porque esta é uma referência circular. Se o Node imprimir o objeto lib/util do módulo, ele entrará em um loop infinito. É por isso que ele simplesmente substitui a referência a lib/util por [Circular].

Mais importante agora, o que acontece se o módulo lib/util requisitar o módulo index principal? É aqui que entramos no que é conhecido como dependência modular circular, que é permitida no Node.

Para entender melhor, vamos primeiro entender alguns outros conceitos sobre o objeto módulo.

exports, module.exports e carregamento síncrono de módulos

Em qualquer módulo, as exportações são um objeto especial. Se você notou acima, toda vez que imprimimos um objeto de módulo,  até agora, ele tinha uma propriedade de exportação que era um objeto vazio. Podemos adicionar qualquer atributo a este objeto especial de exportação. Por exemplo, vamos exportar um atributo id para index.js e lib/util.js:

// Adicione a linha a seguir na parte superior do lib/util.js
exports.id = 'lib/util';

// Adicione a linha a seguir na parte superior do index.js
exports.id = 'index';

‌Quando executarmos index.js, veremos esses atributos gerenciados no objeto module de cada arquivo:

~/learn-node $ node index.js
In index Module {
  id: '.',
  exports: { id: 'index' },
  loaded: false,
  ... }
In util Module {
  id: '/Users/samer/learn-node/lib/util.js',
  exports: { id: 'lib/util' },
  parent:
   Module {
     id: '.',
     exports: { id: 'index' },
     loaded: false,
     ... },
  loaded: false,
  ... }

Eu removi alguns atributos na saída acima para mantê-la pequena, mas observe como o objeto exports agora tem os atributos que definimos em cada módulo. Você pode colocar quantos atributos quiser nesse objeto de exportação e, na verdade, pode alterar todo o objeto para outra coisa. Por exemplo, para alterar o objeto de exportação para que seja uma função em vez de um objeto, fazemos o seguinte:

// Adicione a linha a seguir no index.js antes do console.log

module.exports = function() {};

Ao executar index.js agora, você verá como o objeto exports é uma função:

~/learn-node $ node index.js
In index Module {
  id: '.',
  exports: [Function],
  loaded: false,
  ... }

‌Observe como não fizemos exports = function() {} para transformar o objeto exports em uma função. Na verdade, não podemos fazer isso porque a variável exports dentro de cada módulo é apenas uma referência à module.exports que gerencia as propriedades exportadas. Quando atribuímos novamente a variável exports, essa referência é perdida e estaríamos introduzindo uma nova variável em vez de alterar o objeto module.exports.

O objeto module.exports em cada módulo é o que a função require retorna quando precisamos desse módulo. Por exemplo, altere a linha require('./lib/util') no index.js para:

const UTIL = require('./lib/util');

console.log('UTIL:', UTIL);

‌O código acima vai capturar as propriedades exportadas lib/util para a constante UTIL. Quando executarmos index.js agora, a última linha produzirá:

UTIL: { id: 'lib/util' }

Vamos também falar sobre o atributo loaded em cada módulo. Até agora, toda vez que imprimimos um objeto de módulo, vimos um atributo loaded nesse objeto com um valor de false.

O módulo module usa o atributo loaded para rastrear quais módulos foram carregados (valor true) e quais módulos ainda estão sendo carregados (valor false). Podemos, por exemplo, ver o módulo index.js totalmente carregado se imprimirmos seu objeto module no próximo ciclo do loop de eventos usando uma chamada a setImmediate:

// No index.js
setImmediate(() => {
  console.log('The index.js module object is now loaded!', module)
});

‌A saída disso seria:

The index.js module object is now loaded! Module {
  id: '.',
  exports: [Function],
  parent: null,
  filename: '/Users/samer/learn-node/index.js',
  loaded: true,
  children:
   [ Module {
       id: '/Users/samer/learn-node/lib/util.js',
       exports: [Object],
       parent: [Circular],
       filename: '/Users/samer/learn-node/lib/util.js',
       loaded: true,
       children: [],
       paths: [Object] } ],
  paths:
   [ '/Users/samer/learn-node/node_modules',
     '/Users/samer/node_modules',
     '/Users/node_modules',
     '/node_modules' ] }

Observe como neste console.log posterior lib/util.js e index.js estão totalmente carregados.

O objeto exports fica completo quando o Node termina de carregar o módulo (e o rotula assim). Todo o processo de solicitação/carregamento de um módulo é síncrono. É por isso que conseguimos ver os módulos totalmente carregados após um ciclo do loop de eventos.

Isso também significa que não podemos alterar o objeto exports de forma assíncrona. Não podemos, por exemplo, fazer o seguinte em nenhum módulo:

fs.readFile('/etc/passwd', (err, data) => {
  if (err) throw err;
  
  exports.data = data; // Will not work.
});

Dependência do módulo circular

Vamos agora tentar responder a uma questão importante sobre dependência circular no Node: o que acontece quando o módulo 1 requer o módulo 2 e o módulo 2 requer o módulo 1?

Para descobrir, vamos criar os dois arquivos a seguir em lib/, module1.js e module2.js, e fazer com que eles solicitem um ao outro:

// lib/module1.js

exports.a = 1;

require('./module2');

exports.b = 2;
exports.c = 3;

// lib/module2.js

const Module1 = require('./module1');
console.log('Module1 is partially loaded here', Module1);

Quando rodamos module1.js vemos o seguinte:

~/learn-node $ node lib/module1.js
Module1 is partially loaded here { a: 1 }

‌Requisitamos module2 antes que module1 fosse totalmente carregado e, como module2 solicitou module1 enquanto não estava totalmente carregado, o que obtemos do objeto exports nesse ponto são todas as propriedades exportadas antes da dependência circular. Apenas a propriedade a foi informada, pois tanto b quanto c foram exportadas após module2 ter solicitado e mostrado o resultado de module1.

O Node mantém isso muito simples. Durante o carregamento de um módulo, ele constrói o objeto exports. Você pode requisitar o módulo antes de terminar de carregar e obterá apenas um objeto de exportação parcial com o que foi definido até agora.

Complementos JSON e C/C++

Podemos requisitar nativamente arquivos JSON e arquivos de complemento C++ com a função require. Você nem precisa especificar uma extensão de arquivo para fazer isso.

Se uma extensão de arquivo não foi especificada, a primeira coisa que o Node tentará resolver é um arquivo .js. Se não encontrar um arquivo .js, ele tentará achar um arquivo .json e analisará o arquivo .json se o encontrar como um arquivo de texto JSON. Depois disso, ele tentará encontrar um arquivo .node binário. No entanto, para remover a ambiguidade, você provavelmente deve especificar uma extensão de arquivo ao requisitar algo além de arquivos .js.

A exigência de arquivos JSON é útil se, por exemplo, tudo o que você precisa para gerenciar nesse arquivo são alguns valores de configuração estática ou alguns valores que você lê periodicamente de uma fonte externa. Por exemplo, se tivéssemos o seguinte arquivo config.json:

{
  "host": "localhost",
  "port": 8080
}

Podemos solicitá-lo diretamente assim:

const { host, port } = require('./config');

console.log(`Server will run at http://${host}:${port}`);

‌A execução do código acima terá esta saída:

Server will run at http://localhost:8080

‌Se o Node não encontrar um arquivo .js ou um arquivo .json, ele procurará um arquivo .node e interpretará o arquivo como um módulo complementar compilado.

O site de documentação do Node tem um arquivo complementar de exemplo escrito em C++. É um módulo simples que expõe uma função hello() e a função hello gera “world”.

Você pode usar o pacote node-gyp para compilar e criar o arquivo .cc em um arquivo .node. Você só precisa configurar um arquivo binding.gyp para dizer ao node-gyp o que fazer.

Depois de ter o arquivo addon.node (ou qualquer nome que você especificar em binding.gyp), você poderá requisitá-lo nativamente como qualquer outro módulo:

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

console.log(addon.hello());

‌Na verdade, podemos ver o suporte das três extensões olhando para require.extensions.

‌ ‌Observando as funções de cada extensão, você pode ver claramente o que o Node fará com cada uma. Ele usa module._compile para arquivos .js, JSON.parse para arquivos .json e process.dlopen para arquivos .node.

Todo o código que você escreve no Node será envolvido por funções

O encapsulamento de módulos do Node geralmente é mal compreendido. Para entendê-lo, deixe-me lembrá-lo sobre a relação exports/module.exports.

Podemos usar o objeto exports para exportar propriedades, mas não podemos substituir o objeto exports diretamente, porque é apenas uma referência a module.exports.

exports.id = 42; // Isto está ok.

exports = { id: 42 }; // Isso não funcionará.

module.exports = { id: 42 }; // Isto está ok.

‌Como exatamente esse objeto exports, que parece ser global para cada módulo, é definido como uma referência no objeto module?

Deixe-me fazer mais uma pergunta antes de explicar o processo de encapsulamento do Node.

Em um navegador, quando declaramos uma variável em um script como este:

var answer = 42;

‌Essa variável answer estará disponível globalmente em todos os scripts após o script que a definiu.

Este não é o caso do Node. Quando definimos uma variável em um módulo, os outros módulos do programa não terão acesso a essa variável. Então, como as variáveis ​​no Node têm escopo mágico?

A resposta é simples. Antes de compilar um módulo, o Node envolve o código do módulo em uma função, que podemos inspecionar usando a propriedade wrapper (que poderia ser traduzida como "invólucro", ou "envelope") do módulo module.

~ $ node
> require('module').wrapper
[ '(function (exports, require, module, __filename, __dirname) { ',
  '\n});' ]
>

O Node não executa nenhum código que você escreve em um arquivo diretamente. Ele executa esta função wrapper que terá seu código em seu corpo. Isso é o que mantém as variáveis ​​de nível superior definidas em qualquer módulo com escopo para esse módulo.

Esta função wrapper tem 5 argumentos: exports, require, module, __filename e __dirname. É isso que os faz parecerem globais quando na verdade são específicos para cada módulo.

Todos esses argumentos obtêm seus valores quando o Node executa a função wrapper. exports é definida como uma referência a module.exports antes disso. require e module são específicas para a função a ser executada, enquanto as variáveis __filename/__dirname conterão o nome de arquivo absoluto do módulo encapsulado e o caminho do diretório.

Você pode ver esse encapsulamento em ação se executar um script com um problema em sua primeira linha:

~/learn-node $ echo "euaohseu" > bad.js

~/learn-node $ node bad.js
~/bad.js:1
(function (exports, require, module, __filename, __dirname) { euaohseu
                                                              ^
ReferenceError: euaohseu is not defined

‌Observe como a primeira linha do script, conforme relatado acima, era a função wrapper, não a referência incorreta.

Além disso, como cada módulo é envolvido em uma função, podemos acessar os argumentos dessa função com a palavra-chave arguments:

~/learn-node $ echo "console.log(arguments)" > index.js

~/learn-node $ node index.js
{ '0': {},
  '1':
   { [Function: require]
     resolve: [Function: resolve],
     main:
      Module {
        id: '.',
        exports: {},
        parent: null,
        filename: '/Users/samer/index.js',
        loaded: false,
        children: [],
        paths: [Object] },
     extensions: { ... },
     cache: { '/Users/samer/index.js': [Object] } },
  '2':
   Module {
     id: '.',
     exports: {},
     parent: null,
     filename: '/Users/samer/index.js',
     loaded: false,
     children: [],
     paths: [ ... ] },
  '3': '/Users/samer/index.js',
  '4': '/Users/samer' }

‌O primeiro argumento é o objeto exports, que começa vazio. Então temos os objetos require/module, que são instâncias associadas ao arquivo index.js em execução. Não são variáveis ​​globais. Os últimos 2 argumentos são o caminho do arquivo e o caminho do diretório.

O valor de retorno da função de encapsulamento é module.exports. Dentro da função encapsulada, podemos usar o objeto exports para alterar as propriedades de module.exports, mas não podemos reatribuir as próprias exportações porque é apenas uma referência.

O que acontece equivale aproximadamente a:

function (require, module, __filename, __dirname) {
  let exports = module.exports;
  
  // Seu código aqui...
  
  return module.exports;
}

Se alterarmos o objeto exports inteiro, ele não será mais uma referência a module.exports. É assim que os objetos de referência do JavaScript funcionam em todos os lugares, não apenas neste contexto.

O objeto necessário

Não há nada de especial em require. É um objeto que atua principalmente como uma função que recebe um nome de módulo ou caminho e retorna o objeto module.exports. Podemos simplesmente substituir o objeto require com nossa própria lógica, se quisermos.

Por exemplo, talvez para fins de teste, queremos que cada chamada de require seja simulada por padrão e apenas retorne um objeto falso em vez do objeto de exportação de módulo necessário. Essa simples reatribuição de require resolverá o problema:

require = function() {

  return { mocked: true };
  
}

Depois de fazer a reatribuição de require, cada chamada a require('something') no script retornará apenas o objeto simulado.

O objeto require também possui propriedades próprias. Vimos a propriedade resolve, que é uma função que executa apenas a etapa de resolução do processo require. Também vimos require.extensions acima.

Há também require.main, que pode ser útil para determinar se o script está sendo necessário ou executado diretamente.

Digamos, por exemplo, que temos esta função simples printInFrame em print-in-frame.js:

// Em print-in-frame.js

const printInFrame = (size, header) => {
  console.log('*'.repeat(size));
  console.log(header);
  console.log('*'.repeat(size));
};

A função recebe um argumento numérico size e um argumento string header e imprime esse cabeçalho em um quadro de estrelas controlado pelo tamanho que especificamos.

Queremos usar este arquivo de duas maneiras:

1. A partir da linha de comando diretamente, assim:

~/learn-node $ node print-in-frame 8 Hello

‌Passando 8 e Hello como argumentos de linha de comando para imprimir "Hello" em um quadro de 8 estrelas.

2. Com require. Supondo que o módulo necessário exportará a função printInFrame, podemos simplesmente chamá-la:

const print = require('./print-in-frame');

print(5, 'Hey');

Para imprimir o cabeçalho "Hey" em um quadro de 5 estrelas.

São dois usos diferentes. Precisamos de uma maneira de determinar se o arquivo está sendo executado como um script autônomo ou se está sendo requisitado por outros scripts.

É aqui que podemos usar esta instrução if simples:

if (require.main === module) {
  // O arquivo está sendo executado diretamente (sem o require)
}

Assim, podemos usar esta condição para satisfazer os requisitos de uso acima invocando a função printInFrame de forma diferente:

// Em print-in-frame.js

const printInFrame = (size, header) => {
  console.log('*'.repeat(size));
  console.log(header);
  console.log('*'.repeat(size));
};

if (require.main === module) {
  printInFrame(process.argv[2], process.argv[3]);
} else {
  module.exports = printInFrame;
}

‌Quando o arquivo não está sendo requerido, apenas chamamos a função printInFrame com elementos process.argv. Caso contrário, apenas alteramos o module.exports para ser a própria função printInFrame.

Todos os módulos serão armazenados em cache

O cache é importante para entender. Deixe-me usar um exemplo simples para demonstrá-lo.

Digamos que você tenha o seguinte arquivo ascii-art.js que imprime um cabeçalho:

‌Queremos exibir esse cabeçalho toda vez que precisarmos do arquivo. Então, quando requisitamos o arquivo duas vezes, queremos que o cabeçalho apareça duas vezes.

require('./ascii-art') // mostrará o cabeçalho.
require('./ascii-art') // não mostrará o cabeçalho.

‌O segundo require não mostrará o cabeçalho devido ao cache dos módulos. O Node armazena em cache a primeira chamada e não carrega o arquivo na segunda chamada.

Podemos ver esse cache imprimindo require.cache após o primeiro require. O registro de cache é simplesmente um objeto que possui uma propriedade para cada módulo necessário. Esses valores de propriedades são os objetos module usados ​​para cada módulo. Podemos simplesmente excluir uma propriedade desse objeto require.cache para invalidar esse cache. Se fizermos isso, o Node recarregará o módulo para recarregá-lo em cache.

No entanto, esta não é a solução mais eficiente para este caso. A solução simples é envolver a linha de log ascii-art.js com uma função e exportar essa função. Dessa forma, quando solicitamos o arquivo ascii-art.js, obtemos uma função que podemos executar para invocar a linha de log todas as vezes:

require('./ascii-art')() // mostrará o cabeçalho.
require('./ascii-art')() // também mostrará o cabeçalho.

Isso era o que eu tinha para falar sobre este tópico. Obrigado pela leitura e até a próxima!

Aprendendo React ou Node? Confira os livros do autor (em inglês):

• Learn React.js by Building Games
• Node.js Beyond the Basics

Um sistema operacional (SO) é o software de baixo nível que gerencia recursos, controla periféricos e fornece serviços básicos para outros softwares. No Linux, existem 6 estágios distintos no processo de inicialização típico.

1. BIOS

BIOS significa Basic Input/Output System. Em termos simples, o BIOS carrega e executa o carregador de inicialização Master Boot Record (MBR).

Quando você liga o computador pela primeira vez, a primeira coisa que o BIOS faz é executar algumas verificações de integridade do HDD ou SSD.

Em seguida, o BIOS procura, carrega e executa o programa carregador de inicialização, que pode ser encontrado no Master Boot Record (MBR). O MBR às vezes está em um pendrive ou CD-ROM, como em uma instalação em formato live-USB do Linux.

Uma vez que o programa carregador de inicialização é detectado, ele é carregado na memória e o BIOS dá o controle do sistema a ele.

2. MBR

MBR significa Master Boot Record e é responsável por carregar e executar o carregador de inicialização GRUB.

O MBR está localizado no 1º setor do disco inicializável, que normalmente é /dev/hda ou /dev/sda, dependendo do seu hardware. O MBR também contém informações sobre o GRUB, ou LILO em sistemas muito antigos.

3. GRUB

Às vezes chamado de GNU GRUB, que é a abreviação de GNU GR e Unified Bootloader, é o carregador de inicialização típico para a maioria dos sistemas Linux modernos.

A tela inicial do GRUB geralmente é a primeira coisa que você vê quando inicializa seu computador. Tem um menu simples onde você pode selecionar algumas opções. Se você tiver várias imagens de kernel instaladas, poderá usar o teclado para selecionar aquela com a qual deseja que seu sistema inicialize. Por padrão, a imagem do kernel mais recente é selecionada.

A tela inicial aguarda alguns segundos para você selecionar uma opção. Se você não fizer isso, ele carregará a imagem padrão do kernel.

Em muitos sistemas, você pode encontrar o arquivo de configuração do GRUB em /boot/grub/grub.conf ou /etc/grub.conf. Aqui está um exemplo de um arquivo grub.conf simples:

#boot=/dev/sda
default=0
timeout=5
splashimage=(hd0,0)/boot/grub/splash.xpm.gz
hiddenmenu
title CentOS (2.6.18-194.el5PAE)
      root (hd0,0)
      kernel /boot/vmlinuz-2.6.18-194.el5PAE ro root=LABEL=/
      initrd /boot/initrd-2.6.18-194.el5PAE.img

4. Núcleo

O kernel é muitas vezes referido como o núcleo de qualquer sistema operacional, incluindo o Linux. Ele tem controle total sobre tudo em seu sistema.

Neste estágio do processo de inicialização, o kernel que foi selecionado pelo GRUB primeiro monta o sistema de arquivos raiz especificado no arquivo grub.conf. Em seguida, executa o programa /sbin/init, que é sempre o primeiro programa a ser executado. Você pode confirmar isso com seu ID de processo (PID), que deve ser sempre 1.

O kernel então estabelece um sistema de arquivos raiz temporário usando o disco RAM inicial (initrd) até que o sistema de arquivos real seja montado.

5. Iniciar

Neste ponto, seu sistema executa programas de nível de execução. Em um ponto, ele procuraria um arquivo init, geralmente encontrado em /etc/inittabpara decidir o nível de execução do Linux.

Os sistemas Linux modernos usam o systemd para escolher um nível de execução. De acordo com a TecMint , estes são os níveis de execução disponíveis:

O nível de execução 0 é correspondido por poweroff.target (e runlevel0.target é um link simbólico para poweroff.target ).
         
         O nível de execução 1 é correspondido por rescue.target (e runlevel1.target é um link simbólico para rescue.target ).
         
         O nível de execução 3 é emulado por multi-user.target (e runlevel3.target é um link simbólico para multi-user.target ).
         
         O nível de execução 5 é emulado por graphical.target(e runlevel5.target é um link simbólico para graphical.target ).
         
         O nível de execução 6 é emulado por reboot.target (e runlevel6.target é um link simbólico para reboot.target ).
         
         Emergency é correspondido por Emergency.target .

O systemd então começará a executar programas de nível de execução.

6. Programas de nível de execução

Dependendo de qual distribuição Linux você instalou, você poderá ver diferentes serviços sendo iniciados. Por exemplo, você pode pegar starting sendmail …. OK.

Eles são conhecidos como programas de nível de execução e são executados a partir de diretórios diferentes, dependendo do nível de execução. Cada um dos 6 níveis de execução descritos acima tem seu próprio diretório:

• Nível de execução 0 –/etc/rc0.d/
• Nível de execução 1 –/etc/rc1.d/
• Nível de execução 2 –/etc/rc2.d/
• Nível de execução 3 –/etc/rc3.d/
• Nível de execução 4 –/etc/rc4.d/
• Nível de execução 5 –/etc/rc5.d/
• Nível de execução 6 –/etc/rc6.d/

Observe que a localização exata desses diretórios varia de distribuição para distribuição.

Se você procurar nos diferentes diretórios de nível de execução, encontrará programas que começam com "S" ou "K" para inicialização e eliminação, respectivamente. Os programas de inicialização são executados durante a inicialização do sistema e eliminam os programas durante o desligamento.

Isso é tudo que você precisa saber sobre o processo de inicialização do Linux. Agora vá lá e deixe Tux orgulhoso.