대머리개발자

자세한 내용은 해당 블로그에 확인한다. 너무나도 잘 기록되어있다. ㄳhttps://zuminternet.github.io/FCM-PUSH/ FCM 푸시 파헤치기파일럿부터 적용까지 진행했던 FCM 푸시를 파헤치며 기초 가이드북처럼 정리해보았습니다.zuminternet.github.io 그럼에도 간단하게 설명하자면 PUB / SUB 개념과 동일하다고 생각한다.  공급자(Publisher)는 메세지를 만들어는 내는 우리가 되는 것이고메세지를 소비하는 사용자는 구독자(Subscriber), 즉 클라이언트가 되는 것이다. 따라서 공급자에 대한 설정과 구독자에  대한 설정을 해야 하는 것이다. 상대적으로 공급자(서버) 설정이 쉽다. 1. 프로젝트 대충 만든다.2. 프로젝트 설정 -> 서비스 계정으로 접근한다.3. ..

지나가는 스트림, 즉 흘러가고 있는 데이터의 물결에서 어떤 가공을 하려면 ? 1년동안 주구장창 쓰고 있는데도..아.. 잘 모르고 쓰고 있구나 싶어서 다시 한번 이해도를 높이기 위한 고민을 시작했다. 사실 이부분은 프레임워크의 순 기능이다.내부적인 동작은 잘 몰라도 그냥 가져다 쓰면 그저 잘 나온다. 암튼.. ㅋ 아래의 코드를 보자Mono.just(1).flatMap( it -> Mono.just( it + 2)).subscribe(System.out::println);Mono.just(1).map( it -> it + 2).subscribe(System.out::println); 동일한 결과를 나오지만.적절하게 언제 어떻게 사용할 수 있는지 매순간 고민하고 머리 빠지고 해야 한다. 그런점에서 미리 고민하..

사용자를 관리하는 모듈(서버)이 별도로 존재하기 때문에사용자 정보가 현재 동떨어져 있다. (독립적이다. -> 나름 MSA ) 접근하기 위한 방법은 기본적으로 API를 이용하면 된다. 그러나 하나의 정보가 아닌 목록에 표현되는  정보라면 API호출은 성능 문제를 야기할 수 있다.(목록 Row 만큼 호출하는 것은 초딩이 봐도 아닌것을 금방 눈치 챌 수 있다.) 두가지 방법이 있는듯 한다. 1. DB View 제공해 Join해서 처리2. 해당 CASE의 경우 노출되는 정보를 같이 저장한다.3. 목록(리스트)에서 필요한 정보를 한 번의  API로 처리  각각의 장 단점이 있다. -> 현재 게시판 모듈에서 2번으로 처리하고 있다.게시판의 목록에서 닉네임을 보여주고 있는데 해당 정보를 게시판에 등록할 때 같이 저장..

부하 :  nGrinder  R2DBC + 레디스R2DBC + mysql 쿼리 수행시간이 평균 4ms으로 나오는 EndPoint  ( 레디스 )쿼리 수행시간이 평균 5ms으로 나오는 EndPoint  ( mysql )  레디스가 약 63%로 빠르다. 레디스를 적재적소에 사용을 하면 최적화된 피드백을 전달할 수 있다.!!당영한 이야기지..괜히 캐쉬로 쓰는것이 아니다. webflux, 논-블로킹, 비동기,..을 사용하는 이유는... 최소한의 자원으로 최대한의 효과를 얻기 위함이다.  성능 향상 keyword- 논-블로킹으로 처리를 하더라도 step by step으로 하는 것이 아니라 필요에 따라서 동시(병렬)로 처리- 엔티티가 아닌 DTO로 처리 -> 바인딩하는데 좀 더 걸린다. : 별다른 로직이 없는데 쿼..