Lorawan-stack: Suporte a variáveis ​​personalizadas em URLs de webhook

Com base na aparência dos campos, suspeito que você estava planejando implementar isso com text/template . Se esse for realmente o caso, esteja ciente do fato de que analisar e executar modelos (especialmente se não for apenas a URL base, mas também o caminho) em cada uplink pode consumir muitos recursos.
Além disso, certifique-se de usar uma estrutura muito limitada com a qual o modelo será executado. Use apenas tipos primitivos (então converta todos os EUIs/DevAddr em strings), evite ponteiros.

Acho que podemos armazenar em cache o próprio modelo usando o ID do Webhook + updated_at para evitar a recompilação do modelo sempre. Também é verdade que apenas strings devem ser passadas para o próprio modelo (e eu prefiro não usar nada além dos identificadores).

Acho que duas opções;

• Use text/template com uma estrutura muito simples específica para este caso de uso. Ou seja, não passe *ttnpb.ApplicationUp mas WebhookTemplateFields apenas com as coisas que apoiamos
• Use substituição de string nos campos conhecidos. Super rápido, mesmo resultado

Se formos para o segundo, provavelmente não deveríamos usar a sintaxe do modelo Go, porque isso apenas confundiria as pessoas (por que o ponto? está preenchido com espaços?).

Se quisermos manter as mesmas regras de validação, podemos considerar o uso de espaços reservados como $app_id . Dessa forma, os placeholders não serão válidos no host (porque não queremos isso), mas serão válidos no caminho (acho que $ é permitido em caminhos de URL, precisamos verificar isso ).

$ é válido como parte do host e do caminho conforme RFC3986 seção 2.2 . Com isso dito, não somos forçados a analisar a parte do host do url.URL .

A sintaxe padrão (de acordo com RFC 6570 , consulte 1.2 e 2.2) para modelos de URI é {[operator]variable-list} . Como estamos trabalhando em um hot spot, acredito que essa seja uma boa justificativa para descartar os operadores (já que eles exigiriam processamento estendido) e permitir apenas uma variável. Isso nos permite usar string.ReplaceAll sem reinventar a roda.

O que você quer dizer com "permitir uma variável"?

Eu também acho que em termos de experiência do usuário, é melhor não usar text/template , além do impacto no desempenho. Estou bem com nomes de variáveis ​​no estilo PHP.

O padrão mencionado acima permitiria expressões como {appEUI,devEUI} , o que não nos permitiria usar a substituição de string simples. Observe que não permiti expressões como {appEUI}/{devEUI} , que têm apenas uma variável por captura e estão perfeitamente bem.

Que tal este?

Esse é um pacote interno e não pode ser importado fora do pacote principal, mas isso deve ser feito.
Edit: O pacote principal também expõe a função.