Executando verificação de segurança...
4

A simplicidade do JSON e sua integração perfeita com objetos e arrays JavaScript são, de fato, muito belas. No entanto, é aqui que reside um problema fundamental. Frequentemente usamos o JSON não apenas como um meio de transmitir dados, mas também como um veículo para carregar instruções sobre o processamento destes.

Esse duplo propósito desfoca a linha entre a representação de dados e as regras para a transformação de dados, normalmente definidas em uma linguagem de domínio específico. Já que na maioria dos casos ninguém lê ativamente o JSON, como mencionado, uma abordagem mais eficiente seria simplemente transferir os dados em formatos binários e oferecer uma interface para acessar estes dados mantendo garantindo que todas as regras são mantidas.

Essa abordagem pode parecer arcaica ou excessivamente complexa para alguns, sugerindo uma mentalidade antiquada em uma era de desenvolvimento rápido e práticas de codificação '"agéis"', mas é crucial abordar o JSON com um senso de cautela. Enquanto é inegavelmente universal e conveniente, especialmente em JavaScript, há momentos em que outras alternativas podem ser mais apropriadas.

O XML, por exemplo, apesar de ser considerado por muitos como ultrapassado, ainda tem um papel crucial em sistemas onde a estrutura de dados é complexa e a definição de regras e esquemas é essencial e é uma escolha robusta para interoperabilidade e validação rigorosa de dados.

Protobufs, por outro lado, oferece uma abordagem eficiente e compacta para a serialização de dados estruturados. Sua natureza binária o torna particularmente adequado para comunicação entre serviços em ambientes de distribuidos, onde a eficiência é uma prioridade.

Mas eis que surge jq, realocando o JSON de volta ao seu lugar como texto, mais especificamente como pate da strem de texto no pipeline do Unix. jq permite a manipulação elegante e eficiente de dados JSON diretamente da linha de comando, transformando JSON não apenas em um formato de dados, mas em um terreno de brincadeiras (e soluçoões robustas) baseadas na arte do processamento de stream no pipeline do unix. Estou me divertindo com isso e volto para contar as aventuras!

Carregando publicação patrocinada...
3

Eu não toquei nesse ponto porque achei que ia desviar do assunto principal (entender o formato), e também porque o texto está quase no limite de caracteres que o site permite, mas enfim, concordo com vc :-)

De fato existe um abuso de JSON. Usa-se pra tudo, mas nem sempre ele é a melhor opção (e não duvido que tenha gente que ache que é a única).

Aliás, incrível como isso é recorrente na nossa área. Qualquer coisa que se populariza começa a ser usada pra tudo, até pra casos em que não serve e para os quais existem soluções melhores. Infelizmente também ocorreu isso com JSON.

Nem tudo precisa ser "human readable" (uma das supostas vantagens do JSON, que pra mim é um grande "depende"). Muitas vezes um formato binário, como o protobuf que vc citou, é mais adequado. O ideal seria que todos conhecessem diferentes formatos, seus prós e contras, em quais casos um faz mais sentido que outro e escolher o mais adequado de acordo com o contexto (como aliás, deveria ser pra tudo em computação).

2

Na verdade quase nunca precisa ser legível, e em alguns casos, nem deveria (ainda que não pode ser confundido com dar segurança).

Eu acho incrível especialmente pessoas experientes adotando algo para tudo e/ou sem questionar. Inexperientes isso é normal, ainda que não desejável. Daí começo questionar a experiência delas.