Lorawan-stack: Compatibilidad con variables personalizadas en URL de webhook

Según el aspecto de los campos, sospecho que planeaba implementar esto con text/template . Si ese es realmente el caso, tenga en cuenta el hecho de que analizar y ejecutar plantillas (especialmente si no es solo la URL base sino también la ruta) en cada enlace ascendente puede consumir muchos recursos.
Además, asegúrese de usar una estructura muy limitada con la que se ejecutará la plantilla. Use solo tipos primitivos (así que convierta todos los EUI/DevAddr en cadenas), evite los punteros.

Creo que podemos almacenar en caché la plantilla en sí usando el ID de Webhook + updated_at para evitar volver a compilar la plantilla cada vez. También es cierto que solo se deben pasar cadenas a la plantilla en sí (y preferiría que no usemos nada más fuera de los identificadores).

Pienso en dos opciones;

• Use text/template con una estructura muy simple específica para este caso de uso. Es decir, no pase *ttnpb.ApplicationUp sino WebhookTemplateFields solo con las cosas que admitimos
• Use el reemplazo de cadena en los campos conocidos. Súper rápido, mismo resultado

Si optamos por el segundo, entonces probablemente no deberíamos usar la sintaxis de la plantilla Go en absoluto, porque eso solo confundiría a las personas (¿por qué el punto? ¿Está relleno con espacios?).

Si queremos mantener las mismas reglas de validación, podríamos considerar usar marcadores de posición como $app_id . De esa manera, los marcadores de posición no serán válidos en el host (porque no queremos eso), pero serán válidos en la ruta (creo que $ está permitido en las rutas de URL, debemos verificar que ).

$ es válido tanto como parte del host como de la ruta según RFC3986 sección 2.2 . Dicho esto, no estamos obligados a analizar la parte del host de url.URL .

La sintaxis estándar (según RFC 6570 , consulte 1.2 y 2.2) para las plantillas de URI es {[operator]variable-list} . Dado que estamos trabajando en un punto crítico, creo que esta es una buena justificación para descartar los operadores (ya que requerirían un procesamiento prolongado) y permitir solo una variable. Esto nos permite usar string.ReplaceAll sin reinventar la rueda.

¿Qué quieres decir con "permitir una variable"?

También creo que, en cuanto a la experiencia del usuario, es mejor no usar text/template , aparte del impacto en el rendimiento. Estoy bien con los nombres de variables de estilo PHP.

El estándar mencionado anteriormente permitiría expresiones como {appEUI,devEUI} , lo que no nos permitiría usar el reemplazo de cadena simple. Tenga en cuenta que no deseché expresiones como {appEUI}/{devEUI} , que tienen solo una variable por captura y están perfectamente bien.

¿Que tal este?

Ese es un paquete interno y no se puede importar fuera del paquete principal, pero esto debería hacerlo.
Editar: el paquete principal también expone la función.