Notei um pequeno detalhe, mas muito útil, na documentação da interface do node do @Dusk para wallets e exchanges: as respostas do node incluem uma Rusk-Version, e os clientes também podem informar ao node quais versões eles aceitam. Se Rusk-Version-Strict estiver incluído, o node rejeitará imediatamente a solicitação quando as versões não corresponderem.
Muitas pessoas veem uma interface antiga ainda funcionando e pensam que “compatibilidade” significa que ela vai funcionar para sempre. Mas a documentação também lista três rotas antigas de atalho que estão depreciadas e serão removidas no futuro.
Vejo isso em duas partes.
A primeira é a verificação de versão. O cliente não precisa esperar a interface mudar e então descobrir um problema. Ele pode informar ao node, com antecedência, qual versão do Rusk aceita. A verificação estrita é útil porque é melhor rejeitar claramente uma solicitação do que deixar um cliente antigo receber dados que ele possa interpretar incorretamente.
A segunda é a migração de rotas. Novas integrações devem usar /graphql para consultas de cadeia (chain), bloco (block), transação (transaction), mempool e archive. Métodos de contrato devem mudar para /on/contracts/.... As rotas antigas são apenas para o período de transição.
Isso também importa para usuários comuns. Depósitos em exchanges, saldos de wallets e histórico do navegador dependem de os clientes entenderem corretamente os dados do node.
Para o $DUSK , acho que maturidade não é apenas manter a cadeia online. Também significa que wallets, exchanges e indexers precisam acompanhar as mudanças na interface.
A pergunta real é: os clientes mais populares vão migrar antes de as rotas antigas serem removidas, ou apenas depois que os usuários começarem a ver falhas?
#dusk $DUSK
Muitas pessoas veem uma interface antiga ainda funcionando e pensam que “compatibilidade” significa que ela vai funcionar para sempre. Mas a documentação também lista três rotas antigas de atalho que estão depreciadas e serão removidas no futuro.
Vejo isso em duas partes.
A primeira é a verificação de versão. O cliente não precisa esperar a interface mudar e então descobrir um problema. Ele pode informar ao node, com antecedência, qual versão do Rusk aceita. A verificação estrita é útil porque é melhor rejeitar claramente uma solicitação do que deixar um cliente antigo receber dados que ele possa interpretar incorretamente.
A segunda é a migração de rotas. Novas integrações devem usar /graphql para consultas de cadeia (chain), bloco (block), transação (transaction), mempool e archive. Métodos de contrato devem mudar para /on/contracts/.... As rotas antigas são apenas para o período de transição.
Isso também importa para usuários comuns. Depósitos em exchanges, saldos de wallets e histórico do navegador dependem de os clientes entenderem corretamente os dados do node.
Para o $DUSK , acho que maturidade não é apenas manter a cadeia online. Também significa que wallets, exchanges e indexers precisam acompanhar as mudanças na interface.
A pergunta real é: os clientes mais populares vão migrar antes de as rotas antigas serem removidas, ou apenas depois que os usuários começarem a ver falhas?
#dusk $DUSK