대머리개발자

메시지 proto 하나 수정했는데 java.lang.IllegalArgumentException : jsonMarshaller must be non-null when serializationFormat is JSON. 다른 곳에서 삽질 할 뻔 했다. 휴~ message ScopeMapping { string scope_id=1; string client_id=2; common.ExecuteEventType executeEvent=30; int32 code = 31; string message = 32; repeated ScopeMapping list=33; int32 list_count=34; } 문제의 원인은 변수 네이밍이다. mapping_list을 단순 list로 했더니.. 그래 늘 풀네임으로 그냥..

설치는 도커를 통해 쉽게 진행할 수 있다. 그리고 도커 때문에 그냥 거침 없이 진행할 수 도 있다.. 잘 못 설치(?) 하더라도 도커만 지우면 되니깐. 예전 기억에 오라클등등..OS레벨로 설치하다가. 중간에 실패하면 레지 등이꼬여서 OS부터 다시 설치했던 기억이....ㅎㄷㄷ 추억이다 추억!! 설정을 물고 가야하기 때문에 도커 컴포즈로 진행한다. 적당한 위치에서 vi로 docker-compose.yml 파일을 만들어서 내용 복붙 더보기 version: '3.0' services: redis: hostname: redis container_name: redis image: redis:7.0.7 command: redis-server --requirepass 111111 --port 6379 ports: - ..

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.pro..

인증서버를 구축했고인증서버를 통해서 보호 받아야 하는 "리소스 서버"들에 대한 역할과 권한을 어떻게 설계를 해야 하는지에 대한 주저리!! 결론부터 작성하고 주저리 해보자. 역할과 권한은 개념적으로만 카테고리화 한다. 즉 1depth (역할) - 2depth(권한) 이렇게 생각하면 될 듯 한 실제 역할 & 권한에 대한 체크 로직은 동일한 구현체(hasAnyAuthorityName)를 호출 한다. 결론 : 역할과 권한은 개발적으로 동일하다.!! 또한 JWT 처리 방식을 보니 scope와 scp을 Authorities로 받아서 권한 처리를 진행한다. ### 클라이언트 DB Sepc.CREATE TABLE IF NOT EXISTS `oauth_client_details`( `client_id` ..

생각의 흐름대로 주저리 주저리!! 수 많은 블로그에서 저마다의 이해를 바탕으로 저마다의 생각이...온전하지 못한 나를 흔들고 있다. 여긴 오데?? 나는 누구?? 무엇을 하고 있지??...아아어어... 여긴 오데?? 나는 누구??.. 아아아아.. 내가 내린 결론이 틀릴 수 있다...그냥 껴맞추기로 이해를 해보자. 나는 독고다이 솔로다. 해서 혼자 모든 것을 오롯이 해야 한다. 하지만 시간이 없다. 그러하여 인증에 관련된 것들은 위임을 할 것이다. 즉, 나 대신에 더욱 신뢰 있는 친구에게 인증을 부탁한다.(구글, 페이스북, 네이버, 카카오) 사실 인증과 관련된 부분을 개발하기엔 녹록한 부분이 아니기에 위임을 하면 편할것이다. 근데 위임을 할 친구들이 여럿이다... 각자의 방식으로 !! 그 또한 혼돈이다..해..

기본적으로 알고 있는 내용인데 또 고생을 하고 있어서 다시 한번 정리 해본다. 늘 시스템 구성(개발환경)은 누군가 미리 해놓고 그 위에 기능적인 개발만 진행하다 보니 당연하게 생각했던 것들이 너무 소중하고 감사했다잉. 그래서들 블러그를 통해서 기록을 하게 되는 것이고 내가 경험했던 시행착오를 통해 누군가의 삽질을 마무의리 할 수 있도록..... But 삽질의 양만큼 실력이 늘어난다고 본다. 호랑이 담배 피던 시절에는 하나의 어플리케이션에 프론트와 백엔드가 하나의 서버에 공존 했다..JSP....구구절절.... 지금은 모든것이 분업화 되어 프론트(리액트,뷰,...)와 백엔드가 분리되어서 기동이 된다.(어지간하면?) 보통 프론트는 nginx(localhost:3000)와 백엔드는 tomcat(localhos..

클라이언트의 로그를 별도로 기록하자는 정책이 나왔다. 시스템을 유지보수하는 차원이 아닌 사용자 트래킹을 위한 로깅이다. 결국 트래킹을 위한 클라이언트 이벤트에 한땀한땀 API 호출.... 하악하악 클라이언트에서 보내주는 데이터(Json)를 단순 로깅하는 서버로 프레임워크에 따른 성능 테스트를 진행해 보았다. 프레임 설명 비고 spring-Boot(동기) spring-boot-starter-web 로컬 spring-Boot(비동기) spring-boot-starter-webflux 로컬 srping-Boot with Armeria(비동기) armeria-spring-boot2-webflux-starter 로컬 Elasticsearch azure 네트워크(번외) 테스트 결과는 비동기 서버와 동기 서버의 성능..

익숙해지고 나면 개발적인 면에서 보일러플레이트 코드들이 상당 부분은 제거 된다. 집중 할 수 있는 비지니스 로직에 전념 할 수 있다. 즉, 쿼리 관련 같은 패턴들의 "복사 & 붙여넣기" 하는 부분이 제거 된다. 나름의 러닝 커브가 존재하지만 조금(?) 익숙해 지고 나면 Wow 감탄사를 나도 모르게 연발 하고 있을 듯 싶다. 그 만큼 작은 노력으로 빠르게 개발을 할 수 있게 지원해주는 친구라고 보면 될것 같다. 내부적으로 어떻게 동작하는지 까지는 이해 할 필요가 없지만 어떻게 사용 해야 잘 사용하는 건지는 계속적인 고민을 해야 할것이다. 공부의 시작은 삽질에서 부터 Start -> 똥코드를 통해서 많은 것들을 이해 할 수 있었다. 선배개발자들의 노고를 통해서 우린 그저 가져다 쓰기만 하면 된다. 늘 고맙습..