#newt $NEWT @NewtonProtocol #Newt
ainda achava que as políticas de protocolo eram basicamente livros de regras estáticos. Você as publica uma vez, audita uma vez e pronto. Quanto mais eu lia sobre o Newton Protocol, mais eu percebia que essa suposição nem de longe estava certa.
O que me chamou a atenção é como o Newton Protocol separa a lógica reutilizável de políticas Rego da configuração dinâmica anexada a um PolicyClient. Em vez de reescrever o código da política para cada caso de uso, a mesma lógica pode ser reutilizada enquanto parâmetros como limites de limiar (thresholds), limites de exposição (exposure limits) e allowlists aprovadas são passados via data.params como JSON simples.
Isso me lembrou de algo simples da vida real. Minha família usa as mesmas regras da casa para todos, mas meu primo mais novo tem limites diferentes dos meus na mesma idade. As regras não mudaram. A configuração mudou. O princípio permaneceu consistente enquanto os limites se adaptavam.
O Newton segue uma filosofia semelhante, mas com garantias bem mais fortes. Um detalhe que achei especialmente interessante é expireAfter. Ele define a janela do bloco de execução para uma atestação, e não quando os próprios parâmetros expiram. Se você definir curto demais, execuções válidas podem falhar porque a janela fecha rápido demais. Se definir longo demais, a oportunidade para replay ou execução atrasada cresce. Nenhuma das escolhas é automaticamente correta. O contexto importa.
Outra escolha de design sutil é que atualizar parâmetros por meio de setPolicy(PolicyConfig) cria um novo policyId. A configuração anterior imediatamente fica obsoleta, criando uma separação limpa entre os estados de política antigo e novo, em vez de simplesmente mutar silenciosamente as suposições de confiança.
Minha principal conclusão não foi flexibilidade. Foi responsabilidade. O Rego define a lógica, mas as pessoas definem os parâmetros, revisam-nos e, por fim, moldam o resultado.
Então, onde os revisores deveriam gastar mais atenção: no código reutilizável da política ou nas configurações escondidas dentro de data.params? Essa arquitetura torna as regras com segurança reutilizáveis, ou transfere as suposições de confiança mais importantes para configurações que muitos usuários não vão inspecionar?
ainda achava que as políticas de protocolo eram basicamente livros de regras estáticos. Você as publica uma vez, audita uma vez e pronto. Quanto mais eu lia sobre o Newton Protocol, mais eu percebia que essa suposição nem de longe estava certa.
O que me chamou a atenção é como o Newton Protocol separa a lógica reutilizável de políticas Rego da configuração dinâmica anexada a um PolicyClient. Em vez de reescrever o código da política para cada caso de uso, a mesma lógica pode ser reutilizada enquanto parâmetros como limites de limiar (thresholds), limites de exposição (exposure limits) e allowlists aprovadas são passados via data.params como JSON simples.
Isso me lembrou de algo simples da vida real. Minha família usa as mesmas regras da casa para todos, mas meu primo mais novo tem limites diferentes dos meus na mesma idade. As regras não mudaram. A configuração mudou. O princípio permaneceu consistente enquanto os limites se adaptavam.
O Newton segue uma filosofia semelhante, mas com garantias bem mais fortes. Um detalhe que achei especialmente interessante é expireAfter. Ele define a janela do bloco de execução para uma atestação, e não quando os próprios parâmetros expiram. Se você definir curto demais, execuções válidas podem falhar porque a janela fecha rápido demais. Se definir longo demais, a oportunidade para replay ou execução atrasada cresce. Nenhuma das escolhas é automaticamente correta. O contexto importa.
Outra escolha de design sutil é que atualizar parâmetros por meio de setPolicy(PolicyConfig) cria um novo policyId. A configuração anterior imediatamente fica obsoleta, criando uma separação limpa entre os estados de política antigo e novo, em vez de simplesmente mutar silenciosamente as suposições de confiança.
Minha principal conclusão não foi flexibilidade. Foi responsabilidade. O Rego define a lógica, mas as pessoas definem os parâmetros, revisam-nos e, por fim, moldam o resultado.
Então, onde os revisores deveriam gastar mais atenção: no código reutilizável da política ou nas configurações escondidas dentro de data.params? Essa arquitetura torna as regras com segurança reutilizáveis, ou transfere as suposições de confiança mais importantes para configurações que muitos usuários não vão inspecionar?