Minificar JSON

O jeito rápido de reduzir JSON é tirar todos os espaços e quebras de linha. É também o jeito errado, porque o espaço dentro de uma string faz parte do dado: um `"Nome e sobrenome"` vira `"Nomeesobrenome"`, e como o resultado continua sendo JSON válido ninguém percebe até muito depois.

Aqui o documento é lido com o parser embutido e reescrito. O que sai é, portanto, a mesma estrutura de dados garantida: não existe entrada para a qual a redução mude o conteúdo, porque em nenhum momento o texto é tratado como texto.

A economia mostrada está em bytes UTF-8, que é o número que conta: um acento ocupa dois bytes, um emoji quatro, um caractere chinês três. Um documento com texto em português é, em bytes, bem maior do que o número de caracteres dele sugere.

Quem mede a economia em caracteres obtém quase o mesmo número com um payload de puro ASCII e um número que desvia bastante com um cheio de texto acentuado. Como aqui sempre se trata de um canal ou de um campo de armazenamento, e os dois contam bytes, a conta é feita em bytes.

Quase toda API responde comprimida, e o Gzip é extraordinariamente bom contra espaço repetido: quatro espaços no começo de uma linha, mil vezes, não custam quase nada depois de comprimir. A economia no canal é, portanto, bem menor do que o número daqui sugere, muitas vezes um percentual de um dígito só.

Onde compensa mesmo é onde nada é comprimido: numa variável de ambiente, num campo de banco com limite de comprimento, num log, numa mensagem enfileirada com teto de tamanho. Ali o número de bytes crus é a fronteira, e ali a diferença é real.

Vale conhecer os números, porque eles são o motivo pelo qual esta página existe. Uma mensagem do Amazon SQS para em 256 KB, um item do DynamoDB em 400 KB, e a configuração padrão do Kafka recusa mensagem acima de cerca de 1 MB. Nenhum desses três comprime por você.

Quando um payload está encostando num desses limites, tirar espaço em branco compra fôlego uma vez e não resolve a tendência. A saída estrutural é outra: guardar o conteúdo grande em outro lugar e passar uma referência, que é o padrão que todo mundo acaba adotando depois de estourar o teto uma vez.

Objetos JSON não têm ordem definida, então dois serviços podem devolver os mesmos dados em ordens diferentes. Uma comparação de texto aponta então uma diferença onde não há nenhuma — o motivo habitual de um teste de contrato ficar vermelho embora os dois lados digam a mesma coisa.

Minificar os dois documentos com as chaves ordenadas produz uma forma em que uma comparação literal dá a resposta certa. O mesmo procedimento está por trás de chaves de cache e de assinaturas sobre JSON: o que vai virar hash precisa de uma forma canônica, senão o hash depende do humor do serializador.

Para assinatura existe uma especificação de verdade, a RFC 8785, e ela regula mais do que a ordem: como os números são escritos, como os caracteres especiais são escapados e como a ordenação é feita — por unidades de código UTF-16 e não pelo que um idioma considere alfabético.

A ordenação daqui é a variante prática para comparação e diff, não a normativa para assinatura criptográfica. Para um diff ela basta de sobra; quem assina JSON deveria ler a especificação, porque ali a diferença é feita justamente pelos detalhes que no dia a dia não chamam a atenção de ninguém.

O JSON escreve números como texto e o JavaScript os lê como ponto flutuante de precisão dupla. Inteiros acima de cerca de nove quatrilhões perdem dígitos: um identificador de 19 dígitos sai diferente, e como o resultado continua parecendo um número válido ninguém percebe.

Isso atinge qualquer processamento que passe por um parser de JavaScript, este incluído. O gatilho de sempre são os identificadores tipo snowflake e algumas sequências de banco de dados. A solução está em quem os gera: esses valores devem viajar como string, e aí atravessam qualquer etapa sem mudar.

A redução acontece só no espaço em branco, e num documento com muitos objetos pequenos o espaço em branco não é a maior parte. Se um payload repete `identificadorDoUsuario` dez mil vezes, o que pesa são os nomes das chaves, e nenhum minificador toca neles — mudá-los mudaria o dado.

Quando é o volume que dói de verdade, as saídas reais são outras: nomes de campo curtos combinados entre as duas pontas, ou um formato binário como Protobuf, MessagePack ou CBOR, que não escrevem os nomes das chaves a cada registro. Minificar é o passo barato; ele não substitui essa decisão.

JSON minificado dentro de um arquivo versionado transforma qualquer mudança em uma linha alterada. O diff vira tudo ou nada, a revisão fica impossível e um conflito de merge atinge o documento inteiro em vez dos dois campos de que ele tratava.

A divisão que funciona: formatado no repositório, minificado na hora de servir. A página de formatar faz o caminho de volta, e entre as duas está exatamente o passo que um processo de build deveria dar sozinho.

A saída daqui termina sem quebra de linha, porque ela é uma linha e não um arquivo. Quem for gravar isso num arquivo deveria acrescentar uma: o POSIX define uma linha de texto como algo que termina em quebra, e as ferramentas, do `cat` ao Git, se comportam de forma estranha com arquivos que não têm.

Isso fica relevante ao comparar checksums. O hash de um arquivo com quebra final difere por completo do de um sem ela, mesmo que os dois contenham o mesmo JSON — uma das razões pelas quais dois valores que deveriam coincidir não coincidem.

Aparece de vez em quando a ideia de que um JSON em uma linha só é mais difícil de bisbilhotar. Não é: o conteúdo é exatamente o mesmo, e qualquer pessoa cola aquilo na página de formatar e lê tudo em dois segundos.

Isso importa porque a confusão leva a decisões ruins, como mandar para o navegador uma configuração com credencial dentro achando que estar minificada resolve alguma coisa. O que decide o que é visível é onde o valor está, e não como ele foi escrito. Minificar é uma questão de tamanho, e nunca foi uma questão de segredo.

Um payload JSON contém com frequência justamente o que não convém mover: cadastro de cliente, dados de pedido, um webhook com endereços dentro. Como aqui ele passa por parse e é reescrito na própria página, não há compartilhamento conosco nem operação de tratamento nossa sobre esse conteúdo.

Isso se demonstra no painel de rede: enquanto você usa, nenhuma requisição sai levando o seu documento. É a razão pela qual esta ferramenta pode ser usada onde uma versão com servidor esbarraria numa política interna, e conferir custa um minuto.