Protocolos da internet e scripts do package.json

O que é, de fato, um serviço web? O que tem por trás disso e como a internet funciona de fato?

A resposta começa por protocolos.

Protocolos

Existem vários tipos de protocolos, como, por exemplo, HTTP, FTP, SMTP, cada um com seu objetivo. Por exemplo, HTTP significa Hypertext Transfer Protocol, e o Hypertext ali significa documentos que contêm referências para outros documentos. Então, é um protocolo que define regras para transferência desses documentos.

FTP significa File Transfer Protocol e é um protocolo mais dedicado pra transferência de arquivos. E SMTP significa Simple Mail Transfer Protocol e é um dos padrões utilizados para transferência de mensagens de e-mail.

E um protocolo é só um acordo, um combinado, um padrão que segue regras conhecidas entre as duas partes que estão tentando se comunicar e que definem, por exemplo, como uma conversa começa, em que lugar que eu preencho o que eu quero de informação. E daí, quando a informação volta, como exatamente ela vai voltar, onde que começa, onde é que termina.

E o massa é que você faz isso desde criança, quando brincou de telefone sem fio. Lembra? Um protocolo foi definido entre as crianças, onde especificava que uma informação deveria ser verbalizada de uma criança para outra, sussurrando no ouvido dela, e que esse protocolo deveria ser usado para transmitir a informação até chegar na última criança.

O problema é que esse protocolo não tinha nenhum algoritmo de conferência de erro para se certificar que o payload inicial ia ser transmitido de forma integral entre os proxies, entre as crianças. E essa era a graça da brincadeira.

TCP e UDP

Mas olha que curioso: esse problema de perder informação no meio do caminho acontece na internet também, e nem tudo que é transmitido chega do outro lado. Tanto que um dos protocolos chamado TCP possui um sistema de error recovery para que, caso um pacote de informação não chegue na outra ponta, esse problema seja identificado e corrigido, tentando, por exemplo, enviar esse pacote novamente até os dois lados terem a certeza que a informação foi transmitida com integridade.

E agora que essa história de protocolo começa a ficar interessante, porque um protocolo consegue ser montado em cima do outro. Por exemplo, o HTTP, que define como informações web vão ser trocadas entre um cliente e servidor, pode ser transmitido pelo protocolo TCP, que novamente garante, de forma transparente, que as informações vão chegar do outro lado, e que, para transitar de fato os dados pelos túneis que conectam a internet, é usado um outro protocolo chamado Internet Protocol, ou IP.

flowchart BT
  A["🌐 IP — Internet Protocol"] --> B["🔗 TCP — Transmission Control Protocol"]
  B --> C["📄 HTTP — Hypertext Transfer Protocol"]

  style A fill:#0000ff10,stroke:#58a6ff
  style B fill:#ff880010,stroke:#f0883e
  style C fill:#00ff0010,stroke:#3fb950

E em cima do protocolo IP, você não precisa, mandatoriamente, usar o TCP, porque a garantia que ele traz em ter certeza que a informação chegou do outro lado tem um custo, deixa a transmissão mais devagar. É um seguro, e um seguro tem custo. E tem casos que você quer pagar por esse seguro e tem casos que você não quer.

Um caso no qual você não quer pagar por isso, para que a transmissão dos dados seja mais rápida, é numa ligação em vídeo, no Zoom ou Google Meet, por exemplo, que não importa se um frame do vídeo se perdeu no meio do caminho. Porque é melhor perder e pular alguns frames eventualmente, do que ter que parar tudo para esperar esse frame e sincronizar, pois ele já teria virado uma informação velha.

E, para esse tipo de cenário, é muito mais comum utilizar um protocolo UDP, que é User Datagram Protocol. E datagram significa um pedaço de informação autocontido. Cada pacote enviado é autossuficiente e não depende de uma negociação ou conferência entre as partes envolvidas.

Tanto que, no caso de uma videochamada usando UDP, se um pedaço da transmissão é perdido, sabe quem compensa, como se fosse um TCP? Os dois humanos que estão na ligação. Um lado fala: "Putz, travou aqui. Não deu para entender o que que você falou. Você pode repetir?" Aí o outro lado repete a informação, e essencialmente é isso que o TCP faz.

E jogos multiplayer em tempo real usam muito UDP, como Fortnite, por exemplo, porque não importa tanto se a posição num momento específico de um personagem não chegou. Pula pra próxima posição e interpola, preenchendo esse espaço com posições intermediárias. E é isso que faz alguns jogadores pularem de um lado pro outro do nada, que é o que todo mundo chama de lag.

Scripts do package.json

Mas o nosso interesse aqui é no protocolo HTTP, porque é com esse protocolo que o nosso servidor web vai se comunicar e transmitir os dados das páginas. E é com esse exato mesmo protocolo que o navegador também sabe se comunicar e ler o formato desses dados.

E pra levantar um servidor web num projeto Next.js, por exemplo, existe o comando next dev. Só que, geralmente, dependências como o Next.js não são instaladas de forma global no sistema operacional. Elas são instaladas local ao projeto, e ficam declaradas dentro do package.json.

Por conta disso, não dá pra simplesmente digitar next dev no terminal. A gente precisa de um script, que é um atalho declarado dentro do próprio package.json, e que sabe encontrar onde o next tá instalado de fato para poder executar o comando:

{
  "scripts": {
    "dev": "next dev"
  }
}

Com esse atalho criado, basta rodar npm run seguido do nome do script:

$ npm run dev

E esse padrão de scripts no package.json é universal em projetos Node.js. Você vai encontrar ele em praticamente qualquer repositório, com atalhos como dev, build, test, lint, entre outros. É a forma padrão de organizar e executar comandos dentro de um projeto.

Então, matricule-se no curso.dev para construir um projeto real do zero e ver esses protocolos funcionando na prática, tanto em ambiente de desenvolvimento, usando os scripts do package.json, quanto em produção, quando o projeto estiver hospedado e disponível para o mundo acessar pela internet.