#dusk $DUSK
Ao documentar os nós do Dusk, notei um design pouco discutido por quase ninguém: as respostas dos nós incluem a Rusk-Version, e o cliente também pode declarar antecipadamente quais versões aceita. Se habilitar também o Rusk-Version-Strict, quaisquer versões incompatíveis farão a solicitação ser recusada diretamente. Acho que esse mecanismo é mais importante do que “se a interface antiga ainda vai funcionar”, porque compatibilidade nunca é um compromisso permanente. Agora a documentação já marca 3 rotas rápidas antigas entrando em fase de descontinuação; continuar acessível apenas dá aos desenvolvedores um tempo para migração, e não diz às pessoas que isso vai continuar funcionando indefinidamente.$BTC
Na prática, o Dusk já delimitou muito bem os novos caminhos. Consultas como cadeia, blocos, transações, mempool e arquivamento devem, gradualmente, migrar para /graphql; chamadas de contratos seguem para /on/contracts/… A negociação de versões resolve “se o cliente consegue entender corretamente os dados do nó”; a migração de rotas resolve “de onde, no futuro, buscar os dados”. Vendo essas duas coisas em conjunto, eu realmente acho que falhar com erro estrito é uma forma de proteção. Em vez de permitir que clientes antigos obtenham dados que eles interpretam errado e continuem operando, é melhor expor o problema já na fase da requisição, forçando os integradores a atualizar o quanto antes.@Dusk
Usuários comuns normalmente não percebem essas interfaces no dia a dia, mas o saldo da carteira, o histórico de transações, o status de recarga e as consultas no navegador — tudo isso depende de o cliente conseguir ler corretamente os dados do nó. Por isso, agora eu concluo que, ao avaliar a maturidade da infraestrutura, $DUSK não é só verificar se o nó está gerando blocos normalmente; também é preciso ver se a carteira, o indexador e vários tipos de pontos de integração conseguem concluir a migração de versões a tempo. O que realmente vale observar é: quando as rotas antigas forem removidas oficialmente, os clientes mais comuns já terão feito a troca com antecedência? Se, no final, forem os usuários que primeiro encontrarem falhas nas consultas e isso só então forçar o projeto a corrigir o problema, isso mostra que a gestão de compatibilidade ainda não é suficientemente madura.#dusk
Ao documentar os nós do Dusk, notei um design pouco discutido por quase ninguém: as respostas dos nós incluem a Rusk-Version, e o cliente também pode declarar antecipadamente quais versões aceita. Se habilitar também o Rusk-Version-Strict, quaisquer versões incompatíveis farão a solicitação ser recusada diretamente. Acho que esse mecanismo é mais importante do que “se a interface antiga ainda vai funcionar”, porque compatibilidade nunca é um compromisso permanente. Agora a documentação já marca 3 rotas rápidas antigas entrando em fase de descontinuação; continuar acessível apenas dá aos desenvolvedores um tempo para migração, e não diz às pessoas que isso vai continuar funcionando indefinidamente.$BTC
Na prática, o Dusk já delimitou muito bem os novos caminhos. Consultas como cadeia, blocos, transações, mempool e arquivamento devem, gradualmente, migrar para /graphql; chamadas de contratos seguem para /on/contracts/… A negociação de versões resolve “se o cliente consegue entender corretamente os dados do nó”; a migração de rotas resolve “de onde, no futuro, buscar os dados”. Vendo essas duas coisas em conjunto, eu realmente acho que falhar com erro estrito é uma forma de proteção. Em vez de permitir que clientes antigos obtenham dados que eles interpretam errado e continuem operando, é melhor expor o problema já na fase da requisição, forçando os integradores a atualizar o quanto antes.@Dusk
Usuários comuns normalmente não percebem essas interfaces no dia a dia, mas o saldo da carteira, o histórico de transações, o status de recarga e as consultas no navegador — tudo isso depende de o cliente conseguir ler corretamente os dados do nó. Por isso, agora eu concluo que, ao avaliar a maturidade da infraestrutura, $DUSK não é só verificar se o nó está gerando blocos normalmente; também é preciso ver se a carteira, o indexador e vários tipos de pontos de integração conseguem concluir a migração de versões a tempo. O que realmente vale observar é: quando as rotas antigas forem removidas oficialmente, os clientes mais comuns já terão feito a troca com antecedência? Se, no final, forem os usuários que primeiro encontrarem falhas nas consultas e isso só então forçar o projeto a corrigir o problema, isso mostra que a gestão de compatibilidade ainda não é suficientemente madura.#dusk