É até engraçado pensar que a computação vive de ciclos e que conceitos antigos são aplicados a novos ecossistemas. Enquanto caminhamos para o futuro da web, cada vez mais estamos voltando aos anos 90 e entender e implementar protocolos binários está voltando com tudo na tal da Web3.
Por que caralhos usar binários?
Simples, pequeno gafanhoto, protocolos binários são ordens de grandeza mais rápidos e escaláveis do que aplicações com cabeçalhos enormes e JSON como base. Até hoje grande parte dos MMORPG utiliza protocolos binários pra criar seus servidores e suportar milhões de jogadores simultâneos. Uma evolução no modelo que temos hoje custaria trilhões de dólares para aumentar, cada vez mais, a capacidade de transmissão de dados da Internet. Quem já teve curiosidade de analisar o fluxo de uma requisição HTTP sabe que temos fases bem definidas da requisição, passando pelo DNS Lookup, SSL Checker, Request sent, TTFB, até de fato chegar ao download do conteúdo. Pegando como exemplo uma request simples do site da Amazon, observe:
O tempo que demora entre a conexão do socket e o servidor, verificação do certificado de segurança, até o momento que o servidor web da Amazon processa a requisição e envia o conteúdo são 667ms dos 676ms do total da requisição. Então estamos falando que de fato entre requerimento e resposta temos 2.09ms, adicionando ao tempo de processamento do servidor web o total de 158ms. Perceba que essa requisição poderia ser reduzida em 518ms reduzindo o tempo de conexão, procura do DNS, validação de certificado. Isso o HTTP/2 já está tentando resolver, usando Websocket esse processo ocorre apenas uma vez por acesso, assim todos os request subsequentes utilizando o mesmo socket não vão mais ter a latência da primeira requisição.
Ok, no do site da Amazon a primeira requisição redireciona para “www.”, por isso o Content veio tão pequeno, analisando o segundo request:
Percebe-se que agora não existe mais SSL Checker ou DNS Lookup, que já foram realizados no request anterior, mas ainda temos uma latência de 200ms para receber o primeiro byte do servidor e, aí sim, vem um conteúdo em HTML, utilizando Gzip para compactar.
Ok, mas 600ms parece um tempo razoável, não é mesmo? Um estudo da própria Amazon feito nos anos 2000 afirma que 100ms de latência em uma requisição representa uma perda de 1% das vendas. O Google ainda complementa que existe uma progressão de bounce da aplicação à medida que o tempo de carregamento pula, principalmente em acessos mobile:
Caso queira se aprofundar em aspectos relevantes sobre performance web, recomendo estudar a fundo os padrões do Google em https://web.dev/ (que você provavelmente nem sabia que existia kkk… brincadeira…)
Sendo assim, faz sentido procurar soluções que possam reduzir o custo de atraso entre as requisições, tanto nos processos de request em si, criando socket bidirecionais em caso de múltiplos conteúdos do mesmo domínio, como é o caso do HTTP/2 e, por que não, reduzir o tamanho do conteúdo trafegando pelo protocolo utilizando um padrão de contratos como o Protobuf? É bem provável que, se você for engenheiro da Amazon e criar uma solução que aumente 1% das vendas, um bônus milionário esteja a caminho, não acham?
Protobuf / gRPC
Oh! Que surpresa! De quem é essa idéia de usar binário como uma alternativa ao XML e ao JSON? Sim, do Google. Originalmente concebido para facilitar trafego de dados entre aplicações, com suporte nativo ao C++, C#, Go, Java e Python, usando contratos bem definidos de dados e gerando indexadores binários, quando juntamos o Protobuf + RPC, nasce então o gRPC. E sim, o “g” é de Google. Excelente alternativa para comunicação entre microserviços, é, inclusive, suportada nativamente por frameworks como Nestjs (vou deixar um post que fiz recentemente sobre esse projeto incrível).
Pois bem, com o conceito testado em microserviços, com grandes quantidades de dados em um gigante como o Google, parece interessante entender a fundo o uso do Protobuf e gRPC, não é mesmo ?
E foi exatamente o que eu fiz. Realizei testes com gRPC e Protobuf em um cenário um pouco atípico: desenvolvimento de MMORPG. E devo dizer que obtive resultados interessantes, porém, no final, voltamos ao processo mais rudimentar de uso binário, devido à necessidade extrema de redução do tamanho dos pacotes em uma aplicação onde milhões de dados são distribuídos simultaneamente a milhares de jogadores com o mínimo de latência possível, pois quem joga sabe que 100ms de ping faz MUITA diferença. Mas os testes me deram uma ideia, a possibilidade de usar o conceito na web aplicando Protobuf em um Websocket e, assim, nasceu o projeto UCS.js. Vou deixar alguns posts falando sobre o projeto para quem se interessar:
Web 3
Ok, mas o que isso tem a ver com Web3? Bom, quem já teve curiosidade de olhar os códigos de uma Blockchain e dos serviços derivados, por exemplo, da rede Ethereum, sabe que muita coisa nesse ecossistema usa informações binárias, os próprios Smart Contracts são armazenados em formato binário dentro da Blockchain.
Honestamente eu acredito que isso será recorrente quando falamos de serviços descentralizados, já que precisamos atualizar milhares de Nodes no menor tempo possível. Inclusive, a rede ETH possui suporte nativo a RPC e Websocket, portanto, amigos, o padrão para Web 3 será BINÁRIO.
“Meu Deus, mas eu acabei de sair do JavaScript Vanilla, com meu incrível website em React, o que eu vou fazer da minha vida?” Pode chorar…
Esta na hora de voltar a ler os livros da faculdade que você negligenciou, não é mesmo?
