Lorawan-stack: Webhook URL에서 사용자 정의 변수 지원

필드가 어떻게 보이는지에 따라 text/template 으로 이것을 구현할 계획이었나 봅니다. 그것이 사실이라면 모든 업링크에서 템플릿 구문 분석 및 실행(특히 기본 URL일 뿐만 아니라 경로인 경우)은 잠재적으로 리소스를 상당히 많이 소모할 수 있다는 사실에 유의하십시오.
또한 템플릿이 실행될 매우 제한된 구조체를 사용해야 합니다. 기본 유형만 사용하고(모든 EUI/DevAddr을 문자열로 변환) 포인터를 사용하지 마십시오.

매번 템플릿을 다시 컴파일하는 것을 피하기 위해 Webhook ID + updated_at 를 사용하여 템플릿 자체를 캐시할 수 있다고 생각합니다. 또한 템플릿 자체에 문자열만 전달해야 하는 경우도 있습니다(식별자 외에 다른 것은 사용하지 않는 것이 좋습니다).

두 가지 옵션이 있다고 생각합니다.

• 이 사용 사례에 특정한 매우 간단한 구조체와 함께 text/template 를 사용하십시오. 즉, *ttnpb.ApplicationUp 가 아니라 WebhookTemplateFields 를 Google에서 지원하는 항목으로만 전달합니다.
• 알려진 필드에서 문자열 바꾸기를 사용하십시오. 초고속, 동일한 결과

두 번째로 넘어가면 Go 템플릿 구문을 전혀 사용하지 않아야 합니다. 왜냐하면 그렇게 하면 사람들이 혼란스러울 수 있기 때문입니다(왜 점은 공백으로 채워져 있나요?).

유효성 검사 규칙을 동일하게 유지하려면 $app_id 와 같은 자리 표시자를 사용할 수 있습니다. 그렇게하면 자리 표시자가 호스트에서 유효하지 않지만 (우리는 원하지 않기 때문에) 경로에서는 유효합니다 ( $ 가 URL 경로에서 허용된다고 생각합니다. 우리는 다음을 확인해야 합니다. ).

$ 는 RFC3986 섹션 2.2 에 따라 호스트 및 경로의 일부로 유효합니다. 즉, 우리는 url.URL 의 호스트 부분을 구문 분석하지 않아도 됩니다.

URI 템플릿에 대한 표준( RFC 6570 에 따라 1.2 및 2.2 참조) 구문은 {[operator]variable-list} 입니다. 우리는 핫스팟에서 작업하고 있기 때문에 이것이 연산자를 삭제하고(확장 처리가 필요하기 때문에) 하나의 변수만 허용하는 것이 타당하다고 생각합니다. 이것은 우리가 바퀴를 재발명하지 않고 string.ReplaceAll 를 사용할 수 있게 합니다.

"하나의 변수 허용"은 무엇을 의미합니까?

또한 사용자 경험 측면에서 성능 저하를 제외하고는 text/template 를 사용하지 않는 것이 더 낫다고 생각합니다. 저는 PHP 스타일의 변수 이름이 좋습니다.

위에서 언급한 표준은 {appEUI,devEUI} 와 같은 표현식을 허용하므로 간단한 문자열 바꾸기를 사용할 수 없습니다. 캡처당 하나의 변수만 있는 {appEUI}/{devEUI} 와 같은 표현식을 허용하지 않았으며 완벽하게 괜찮습니다.

이건 어때?

그 하나는 내부 패키지이고 기본 패키지 외부로 가져올 수 없지만 이렇게 해야 합니다.
편집: 기본 패키지도 기능을 노출합니다.