Lorawan-stack: gogo proto 플러그인 미래 조사

GoGo에 대한 지원 중단을 사용하고 있는 유효성 검사 플러그인
https://github.com/envoyproxy/protoc-gen-validate/pull/340

앞으로 가는 가장 좋은 방법은 생태계를 따르고 gogo/protobuf에서 멀리 마이그레이션하는 것입니다. 우리의 다른 종속성이 점점 더 gogo에서 멀어짐에 따라 계속 사용하기가 점점 더 어려워질 것이라고 생각합니다. 물론 마이그레이션하려면 많은 작업이 필요할 것이므로 마이그레이션할 경우 좋은 계획을 세워야 합니다.

@rvolosatovs는 아마도 우리의 gogottn 생성기에 설정된 사용자 지정 옵션에 대해 더 많이 알고 있을 것입니다. 그러나 여기 proto 파일에서 명시적 옵션에 대해 찾은 내용이 있습니다.

• gogoproto.customname , gogoproto.stdtime 및 gogoproto.stdduration 및 goproto_enum_prefix 옵션을 제거하여 시작할 수 있습니다. Go 컴파일러는 결과 문제에 대해 즉시 불평할 것이기 때문에 제거하기가 비교적 쉽습니다.
• gogoproto.embed 옵션을 제거하면 포함된 필드에 더 이상 액세스할 수 없으며(Go 컴파일러가 해당 필드를 찾는 데 도움이 됨) 메시지가 더 이상 일부 인터페이스를 충족하지 않음(이는 더 어려울 수 있음)을 의미합니다.
• gogoproto.nullable 옵션은 훨씬 더 많은 작업이 필요합니다. 왜냐하면 getter 사용을 시작하고 nil-checks를 추가해야 하기 때문입니다. 결과 문제는 Go 컴파일러에서 포착하지 못할 수 있습니다. 가능한 해결 방법은 해당 필드를 일시적으로 비공개로 만든 다음 getter/setter로 다시 작성하고 마지막으로 필드를 다시 공개로 만드는 것입니다.
• 상당히 문제가 되는 것은 gogoproto.customtype 를 사용하는 필드와 gogoproto.enum_stringer 옵션을 사용하는 열거형입니다. 이를 위해 JSON으로 마샬링/비정렬화되는 방식을 자주 변경했습니다. EUI, DevAddr 등과 같은 사용자 정의 bytes 필드의 경우 유형(프로토 메시지에서)을 string (바이너리 호환 가능)로 변경할 수 있습니다. 열거 형을 사용하면 이제 (UnmarshalJSON에서) 문자열과 정수로 모두 허용되기 때문에 JSON API가 깨질 것 같습니다.

어쩌면 이것은 우리의 v4 API에 대해 생각하기 시작하기에 좋은 시간이기도 합니다. 왜냐하면 우리가 더 많은 (API 깨는) 놀라움을 발견할 수 있다고 상상할 수 있기 때문입니다.

가장 좋은 방법은 먼저 https://github.com/alta/protopatch를 사용해 보는 것

• 우리의 모든 요구 사항이 포함된 경우 -> 마이그레이션하고 이에 대해 잊어버리십시오( api 디렉토리에서 검색 및 바꾸기
• 우리의 요구 사항 중 일부만 포함되고 플러그인에서 다루지 않는 사용자 지정 옵션이 있는 경우 -> 옵션별로 평가하고 이러한 사용자 지정 옵션을 제거하거나 아마도 protopatch 기여해야 합니다. 노력이 적은 기능. 이것은 옵션에 따라 다르지만 - customtype 에 대해 이야기하는 경우 IMO는 확실히 기여를 정당화하지만 stdtime 와 같은 것은 그다지 많지 않습니다.

앞으로는 런타임에 내부적으로 구성 요소에서 기본 protobuf protos를 직접 사용해서는 안 된다고 생각합니다(오늘 제공된 protobuf 기능 세트를 감안할 때).
(역)직렬화를 위해서만 protobuf를 사용하는 것이 합리적입니다. 그러나 내부적으로 일반 바닐라 생성 Go 프로토스를 사용하는 것은 나에게 의미가 없습니다.
예를 들어 NS:

1. 레지스트리에서 *ttnpb.EndDevice (바닐라 생성 Go 유형) 가져오기, 저장된 바이너리 데이터에서 역직렬화
2. *ttnpb.EndDevice 를 T_device . (참고: 아마도 처음에 또는 영원히 래퍼일 수 있음)
3. NS에서 내부적으로 T_device
4. T_device 을 *ttnpb.EndDevice (참고: 래퍼를 사용하는 경우 이 작업은 간단하고 매우 빠른 작업일 수 있습니다. 변경된 필드만 수정하면 되고 바이너리에서도 수행할 수 있기 때문입니다. 데이터 직접)
5. *ttnpb.EndDevice , 바이너리 데이터로 직렬화

참조 https://github.com/TheThingsNetwork/lorawan-stack/issues/342 (생성된 인구)

나는 gogo에 대한 (작은) 대안에 찬성하지 않습니다. 캔을 밀어내는 느낌입니다. 특히 우리가 가장 좋은 방법이 무엇인지 다시 결정해야 할 때 가능한 한 바닐라로 유지합시다.

생성된 프로토스에 모든 곳에서 의존하는 대신 일부 장소에서 중개 유형을 사용하는 것을 고려할 수 있다는 데 동의합니다. 기본적으로 데이터 액세스 개체(DAO: 사용 방법)에서 데이터 전송 개체(DTO: proto, 저장용)를 분리합니다. 그것이 주로 읽기라면 인터페이스를 선언하고 얼마나 멀리 있는지 확인할 수도 있습니다.

즉, T_device 를 사용하도록 전체 NS 를 변경하지 않고 필요에 따라 특정 구조체 및/또는 인터페이스를 사용하도록 하겠습니다.

이 토론을 11월로 옮기자

@rvolosatovs 사용자 지정 JSON 마샬러를 사용하여 바닐라로 전환하는 것에 대한 반대 의견은 무엇입니까?

바닐라 프로토스를 직접 사용하게 되면 막대한 마이그레이션 부담과 상용구의 부하가 발생합니다.
저는 그것에 대해 반대하지 않습니다. 제 생각에는 우리가 먼저 간단하고 방해가 되지 않는 대안을 찾아야 한다고 생각합니다. 그것이 가능하지 않다면 이 모든 것을 재작업하는 데 의지해야 합니다.

우리가 의존하기 시작한 플러그인이 어느 시점에서 유지 관리되지 않는 상태로 끝날까봐 두렵습니다. 일반적으로 말해서, 나는 가능한 한 바닐라에 가깝게 유지하는 것에 찬성합니다. 그것이 nil 우리가 원하는 것보다 더 자주 확인한다는 것을 의미한다면 그렇게 하십시오. 또한 초기화된 구조체 대신 설정되지 않은 항목을 알고 있다는 점에서 유리하게 작동할 수 있습니다.

전체 코드베이스를 리팩토링하는 것은 우리가 어떻게 하든 고통스러울 것입니다. 우리의 (gogo 생성) proto 구조체는 지금 모든 곳에서 사용됩니다(gRPC API, HTTP API, 이벤트, 오류, 내부적으로, Redis DB 등). 우리 코드베이스의 거의 모든 것과 현재의 모습을 동시에 볼 수 있습니다.

어려운 요구 사항은 v3 API의 호환성을 손상시키지 않는 것입니다. 이 상황을 v4 API(적어도 내부적으로) 작업을 시작하는 순간으로 사용하기로 결정하더라도 기존 사용자를 위해 해당 v3 API를 계속 지원해야 합니다.

장기적으로 (버전이 있는, 주요 내 안정) 외부 API를 내부(버전이 지정되지 않은, 부 내 안정) API와 (버전이 지정된, 안정적인) 데이터베이스 문서에서 분리함으로써 우리 스스로에게 큰 도움이 될 것이라고 생각합니다. . 그런 다음 내부 API와 다른 API 간에 변환하는 함수를 작성하거나 생성할 수 있습니다.

하지만 우리가 지금 취할 수 있는 몇 가지 단계가 있다고 생각합니다.

JSON

v3 JSON API 호환성을 유지하기 위해 첫 번째 TODO는 사용자 지정 유형을 마샬링/마샬링 해제하는 방법을 이해하는 JSON 마샬러 및 언마샬러를 생성하는 것입니다. Go의 프로토콜 버퍼용 JSON 형식 구현에 대한 안정성 약속이 없기 때문에 이 작업을 수행하는 것이 현명하다고 생각 grpc-gateway 런타임에서 코덱을 등록할 수 있으므로 {gogo,golang}/protobuf의 jsonpb 대신 자체 (생성된) (un) 마샬러를 호출하는 코덱을 작성할 수 있습니다.

이전 프로토타입 _옆에_ 새 프로토타입 생성

나는 이미 그것을 시도했다: https://github.com/TheThingsNetwork/lorawan-stack/commit/a41f62d98ae7ee719b576e6fcd2009a79cd38f4c

이것은 protobuf가 유형 레지스트리에 대해 불평하게 만들므로 이 작업을 수행하려면 이전 proto에서 golang_proto.RegisterType 를 제거해야 할 수 있습니다. 이를 제거하면 잠재적으로 google.protobuf.Any 해결이 중단될 수 있지만 오류 및 이벤트에서만 사용하므로 특정 경우에 대한 해결 방법을 찾을 수 있습니다.

이전 프로토타입과 새 프로토타입 간에 변환하는 함수 생성

이것은 전환 기간 동안에만 해당되지만 장기적 솔루션을 위해 유사한 변환기를 생성하고자 합니다.

서비스를 하나씩 업데이트

https://github.com/TheThingsNetwork/lorawan-stack/commit/cd7d75c8b42ad15eee1ac594ff6d0f2d5a75eb67 에서 간단한 서비스로 이미 시도했지만 더 복잡한 서비스의 경우 확실히 이러한 변환기가 필요합니다.

이것은 grpc 서비스 자체만 변경합니다. grpc-gateway는 여전히 JSON 측에서 이전 gogo 항목을 사용하고 내부 gRPC 서버를 호출한 다음 새 구현을 실행합니다.

여기에 일부 초기 종속성 업데이트 및 이전 버전과의 호환성 해결 방법을 푸시했습니다. https://github.com/TheThingsNetwork/lorawan-stack/compare/issue/2798-codec

점점 더 많은 종속성이 protobuf 1.4 및 V2 API로 업그레이드되고 있으며, 이를 더 오래 유지할수록 종속성을 업그레이드하려고 할 때 더 많은 문제가 발생합니다.

우리는 이 문제에 더 우선 순위를 부여하고 이 모든 것에 대해 우리가 할 일에 대한 결정을 내려야 합니다.

오프라인에서 논의할 수 있도록 다음 주에 통화를 계획하세요.

이 고통의 과정을 거쳐 1~2주 안에 해결하는 데 집중해야 한다고 생각합니다. 그리고 우리가 다른 일을 하는 것을 피하기 위해 그렇지 않으면 많은 갈등을 일으킬 것입니다. 가능한 한 많은 손을 가지려면 어떤 경우에 우리가 무엇을 할 것인지 정확히 알고, 가능한 한 많은 작업을 나누고, 상을 주시해야 합니다.

다음 단계:

1. @rvolosatovs 는 도구를 "바닐라"에 최대한 가깝게 업데이트합니다.
   
   
   
   • unconvert , gofumpt 및 protoc 위에서 수행 중인 기타 작업을 제거합니다.
   
   
   • protoc-gen-gogottn 에서 protoc-gen-gofast (또는 바닐라에 가장 가까운 것)으로 전환
   
   
   • proto 파일에 (gogoproto.*) 옵션을 명시적으로 추가하여 현재와 동일하게 렌더링합니다.
   
   
2. 직접 필드 액세스 대신 Getters를 사용하도록 코드를 리팩토링해야 합니다. gopls 및 rf 와 같은 도구가 도움이 될 수 있습니다.
3. (gogoproto.*) 옵션을 하나씩 제거하기 시작하고 이를 사용하는 코드를 업데이트합니다. gopls 및 rf 와 같은 도구가 도움이 될 수 있습니다.
   
   
   
   • gogoproto.populate 제거 및 테스트 업데이트 (https://github.com/TheThingsNetwork/lorawan-stack/issues/342)
   
   
   • gogoproto.customname 제거 및 EUI -> Eui 등
   
   
   • gogoproto.embed 제거 . 메시지가 ValidateContext(context.Context) error 및 ExtractRequestFields(m map[string]interface{}) 와 같은 인터페이스를 계속 구현하는지 확인해야 합니다.
   
   
   • gogoproto.nullable 제거하고 가능한 경우 Getters를 사용하도록 하고 그렇지 않으면 nil 검사를 수행합니다.
   
   
   • ...
   
   

@rvolosatovs v3.11.3 의 첫 번째 단계를 만들어 보겠습니다. 완료되면 다른 담당자를 다시 추가하고 다시 논의합시다.