Lorawan-stack: Поддержка пользовательских переменных в URL-адресах Webhook

Судя по тому, как выглядят поля, я подозреваю, что вы планировали реализовать это с помощью text/template . Если это действительно так, имейте в виду, что анализ и выполнение шаблонов (особенно если это не только базовый URL-адрес, но и путь) на каждом восходящем канале потенциально могут быть довольно ресурсоемкими.
Кроме того, обязательно используйте очень ограниченную структуру, с которой будет выполняться шаблон. Используйте только примитивные типы (поэтому преобразуйте все EUI/DevAddr в строки), избегайте указателей.

Я думаю, мы можем кэшировать сам шаблон, используя Webhook ID + updated_at , чтобы каждый раз не перекомпилировать шаблон. Кроме того, в самом шаблоне действительно должны передаваться только строки (и я бы предпочел, чтобы мы не использовали ничего, кроме идентификаторов).

Я думаю два варианта;

• Используйте text/template с очень простой структурой, характерной для этого варианта использования. Т.е. не передавать *ttnpb.ApplicationUp , а WebhookTemplateFields только с тем, что мы поддерживаем
• Используйте замену строки в известных полях. Супер быстро, тот же результат

Если мы выберем второе, то нам, вероятно, вообще не следует использовать синтаксис шаблона Go, потому что это только запутает людей (почему точка? она дополнена пробелами?).

Если мы хотим сохранить правила проверки прежними, мы могли бы рассмотреть возможность использования заполнителей, таких как $app_id . Таким образом, заполнители не будут действительны на хосте (потому что мы этого не хотим), но они будут действительны в пути (я думаю, что $ разрешено в URL-путях, нам нужно проверить это ).

$ допустим как часть хоста, так и путь в соответствии с RFC3986, раздел 2.2 . При этом мы не обязаны анализировать хост-часть url.URL .

Стандартный (согласно RFC 6570 , см. 1.2 и 2.2) синтаксис для шаблонов URI — {[operator]variable-list} . Поскольку мы работаем в горячей точке, я считаю, что это хорошее оправдание для отказа от операторов (поскольку они потребуют расширенной обработки) и разрешения только одной переменной. Это позволяет нам использовать string.ReplaceAll не изобретая велосипед.

Что вы имеете в виду под «разрешить одну переменную»?

Я также думаю, что с точки зрения пользовательского опыта лучше не использовать text/template , за исключением снижения производительности. Я в порядке с именами переменных в стиле PHP.

Упомянутый выше стандарт допускал такие выражения, как {appEUI,devEUI} , что не позволяло бы нам использовать простую замену строки. Обратите внимание, что я не запрещал такие выражения, как {appEUI}/{devEUI} , которые имеют только одну переменную для каждого захвата и прекрасно подходят.

Как насчет этого?

Это внутренний пакет, и его нельзя импортировать за пределы основного пакета, но это должно сработать.
Изменить: основной пакет также предоставляет функцию.