드리프트 인터페이스는 여러 언어로 컴파일 될 수 있습니다. 텍스트 파일 일 뿐이며, 스 거거 허브와 같은 온라인 도구가없는 이유는 무엇입니까? 해당 인터페이스를 사용하는 프로젝트간에 붙여 넣기 인터페이스를 복사하고 싶지 않습니다.드리프트 또는 grpc 인터페이스를 저장할 위치는 어디입니까?
jvm 언어 만 인터페이스를 해결할 수 있고 사용자 친화적 인 방법이 아니기 때문에 jar 파일과 인터페이스를 패키지화하는 것이 유용하지 않습니다. 그것은 절약에 관한 것이 아니라 grpc에 관한 것입니다. 이 질문에 관심이있는 문서를 찾지 못했고 모범 사례를 찾을 수 없었습니다.
인터페이스가있는 .proto 파일이 있다고 가정 할 때 각 하위 프로젝트는 파일에 대해 알아야합니다. 이 문제의 주요 접근 방법은 두 가지가 있습니다. 파일을 공급하거나 파일을 복사합니다.
, 당신은 모든 인터페이스 정의를 저장 (A 자식의 repo 같은) 부가 사업을합니다. 인터페이스에 대해 알아야하는 각 프로젝트에는 인터페이스 프로젝트가 포함 된 참조 (자식 서브 모듈 또는 자식 서브 트리)가 포함됩니다. 프로젝트를 빌드 할 때 인터페이스를 동기화 한 다음 필요한 코드를 생성하는 데 사용해야합니다.
이 방법의 단점은 git 하위 트리와 하위 모듈 (또는 사용하는 버전 제어)이 사용하기가 더 어려워 코드 작성자가 추가 작업을해야한다는 것입니다. 하위 프로젝트의 인터페이스를 변경하면 해당 변경 사항을 업스트림으로 인터페이스 프로젝트에 적용하기가 어려울 수 있습니다.
, 당신은 수동으로 프로젝트 사이에 주위에 파일을 복사하고, 수동으로 동기화에 보관하십시오. 변경할 때마다 해당 변경 사항을 인터페이스에 따라 다른 모든 프로젝트에 적용해야합니다. Protobuf를 사용할 때 에는이 없다는 점에 유의해야합니다. Protos는 고도로 하위 호환이 가능하도록 설계되었습니다.
예를 들어, 프로토 타입 정의를 한 양식에서 다른 양식으로 변경하는 코드는 실제로 두 양식을 모두 사용할 수 있습니다. 이전 코드는 이전 양식을보고 새 코드는 이전 양식이나 새 양식을 볼 수 있습니다. 모든 사용자가 업그레이드되면 이전 양식을 제거 할 수 있습니다.
이 접근법의 단점은 복잡성을 코드의 디코딩 부분으로 푸시한다는 점입니다. 당신은 구형 클라이언트의 알려지지 않은 숫자와 하위 호환이 필요하게됩니다. 모든 프로젝트가 인터페이스 정의와 동기화되지는 않으므로 인터페이스의 모든 사용자는보다 유연해야합니다. 이 문제는 Proto에만 국한된 것이 아니라 자연스럽게 발생합니다. 그것은 모든 사람에게 일어난다.
두 번째 단점은 수동으로 변경 사항을 복사해야한다는 것입니다. 필드 번호 나 이름을 절대 재사용하지 마십시오. 인터페이스에 의존하는 프로젝트가 많으면 더 많은 일을합니다.
어느 방법도 다른 것보다 객관적으로 우수하지 않습니다. 각각은 복잡성을 빌드의 다른 부분으로 푸시합니다. 내가 본 것으로부터, 대부분의 사람들은 고급 자식 명령을 배우는 것보다 파일을 복사하는 것을 선호합니다.
Github? 예를 들어, ProtoBuf 파일 ... https://github.com/AeonLucid/POGOProtos –
gRPC 인터페이스는 무엇을 의미합니까? Protobuf 정의 파일 (들)? –
@ ɐuıɥɔɐɯ, 맞습니다. 현재 나는 구현과 동일한에 그들을 저장 –