Lorawan-stack: Prise en charge des variables personnalisées dans les URL Webhook

D'après l'apparence des champs, je soupçonne que vous prévoyiez de l'implémenter avec text/template . Si c'est effectivement le cas, sachez que l'analyse et l'exécution de modèles (surtout s'il ne s'agit pas seulement de l'URL de base mais également du chemin) sur chaque liaison montante peuvent potentiellement nécessiter beaucoup de ressources.
Assurez-vous également d'utiliser une structure très limitée avec laquelle le modèle sera exécuté. N'utilisez que des types primitifs (convertissez donc tous les EUI/DevAddr en chaînes), évitez les pointeurs.

Je pense que nous pouvons mettre en cache le modèle lui-même en utilisant l'ID Webhook + updated_at afin d'éviter de recompiler le modèle à chaque fois. De plus, seules les chaînes doivent être transmises au modèle lui-même (et je préférerais que nous n'utilisions rien d'autre en dehors des identifiants).

Je pense que deux options;

• Utilisez text/template avec une structure très simple spécifique à ce cas d'utilisation. C'est-à-dire, ne passez pas *ttnpb.ApplicationUp mais WebhookTemplateFields avec seulement les trucs que nous supportons
• Utilisez le remplacement de chaîne sur les champs connus. Super rapide, même résultat

Si nous optons pour la seconde, nous ne devrions probablement pas utiliser du tout la syntaxe du modèle Go, car cela ne ferait que semer la confusion dans l'esprit des gens (pourquoi le point ? Est-il rempli d'espaces ?).

Si nous voulons conserver les mêmes règles de validation, nous pourrions envisager d'utiliser des espaces réservés comme $app_id . De cette façon, les espaces réservés ne seront pas valides dans l'hôte (parce que nous ne le voulons pas), mais ils seront valides dans le chemin (je pense que $ est autorisé dans les chemins d'URL, nous devons vérifier que ).

$ est valide à la fois en tant que partie de l'hôte et du chemin conformément à la section 2.2 de RFC3986 . Cela étant dit, nous ne sommes pas obligés d'analyser la partie hôte du url.URL .

La syntaxe standard (selon RFC 6570 , voir 1.2 et 2.2) pour les modèles d'URI est {[operator]variable-list} . Étant donné que nous travaillons dans un point chaud, je pense que c'est une bonne justification pour supprimer les opérateurs (car ils nécessiteraient un traitement prolongé) et n'autoriser qu'une seule variable. Cela nous permet d'utiliser string.ReplaceAll sans réinventer la roue.

Que voulez-vous dire par "autoriser une variable" ?

Je pense aussi que du point de vue de l'expérience utilisateur, il est préférable de ne pas utiliser text/template , à part l'impact sur les performances. Je suis d'accord avec les noms de variables de style PHP.

La norme mentionnée ci-dessus autoriserait des expressions telles que {appEUI,devEUI} , ce qui ne nous permettrait pas d'utiliser la simple chaîne de remplacement. Notez que je n'ai pas interdit les expressions telles que {appEUI}/{devEUI} , qui n'ont qu'une seule variable par capture, et sont parfaitement correctes.

Celui-ci, ça va?

Celui-ci est un package interne et ne peut pas être importé en dehors du package principal, mais cela devrait le faire.
Edit : le package principal expose également la fonction.