grpc.proto porting

GRPC 서비스로 백엔드를 만들어보고 있다.

 

쿼리 질의를 하고 나온 Map을 proto가 자동으로 만든 객체로 포팅하는 것으로 삽질의 시간이였다.

 

jackson을 사용해서  포팅 하려고 하면 오류가 발생한다.

Map의 Key를 객체로 쓰려고 해서 그런다고 한다.

해당 이슈에 대한 해결을 찾아봐서 테스트해보았지만 또 다른 오류가 발생한다... 오류의 연속성.. 결국 실패 ㅋ

 

 ObjectUtil.getObjectMapper().convertValue(map, ClientGrpc.Client.class);
 
 java.lang.IllegalArgumentException: Cannot find a (Map) Key deserializer for type [simple type, class com.google.protobuf.Descriptors$FieldDescriptor]

 

해서 jackson을 포기하고 다른 라이브러리를 활용해 봤더니 gson은 오류가 발생하지 않는다.

하지만 이 친구는 Map에서 한 번에 객체로 포팅이 안 되고 Json으로 변경을 하고 가야 한다.

(Map -> Json -> klass) 

 

혹시나 라이브러리 변경에 대한 성능적 이슈가 있을지 찾아보니 오히려 나의 환경에서는 gson이 더 좋았다!!.

https://www.yunsobi.com/blog/entry/java-json-%EB%9D%BC%EC%9D%B4%EB%B8%8C%EB%9F%AC%EB%A6%AC-%EB%B3%84-parser-%EC%86%8D%EB%8F%84-%EB%B9%84%EA%B5%90

 

뭔가 복잡스러운것 같아서 최초에 gRPC 객체로 쿼리를 받아 오는 방법으로 Try!!

 

proto에 의해서 만들어진 ClientGrpc.Client 내부.

 

별도 ClientDTO를 만들어서 이것저것 테스트 해 보니 변수 끝 밑줄(_)이 있으면 바인딩이 안되었다. 밑줄 없는 변수 친구들만 바인딩이 되었다. 하악하악

밑줄 없이 만들어지는 법을 찾아봐야겠다.

 

일단 그냥 맵으로 받고 JSON 변경하고 ClientGrpc.Client 변경하잡.

 

물론 애초 resultMap으로 아래와 같이 처리해도 되지만 resultMap을 동적으로 바꿔 보고자 하는 것이 목표였다.

 

select 문 자체를  "전체 공통으로 사용"하고 싶어서 단순 map으로 받고 "도메인 로직"에서 분기를 태워서 각 proto 객체로 포팅하려고 시도 했던 부분이다..

로직만으로 쿼리를 만들어 내는 나름의 jpa를 만들어 보고자 ㅋㅋ ㅠㅠ 

 

일단 불편하게 처리!! map -> json -> class : getMapToObject()

proto 늘때마다... if 문이 늘겠지?...

 

그래도 "보일러 플레이트 코드"를 줄이기 위한 최선이라고 본다.

 

기능적으로 뭔가 하나 추가 한다고 하더라도.. 난 xml을 추가 할 필요가 없다. 공통으로 처리 할 수 있도록 비지니스 로직에서 다 처리 해놓았으니...

 

조회하고자 하는 컬럼과 테이블명과 조건절만 셋팅해서 넘기면 알아서 될 수 있도록 ㅎㅎ. 물론 일단 하드코딩이다.ㅋ

더 깔끔한 코드를 위해서 늘 고민해보자!!!!!!!!

 

뜬금포 .. 아르메리아... 고맙습니다. 네이버 라인 고맙슴당.!!

인증서버의 클라이언트 정보에 대한 CRUD 개발 中. By 아르메리아