대머리개발자

지나가는 스트림, 즉 흘러가고 있는 데이터의 물결에서 어떤 가공을 하려면 ? 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로 처리 -> 바인딩하는데 좀 더 걸린다. : 별다른 로직이 없는데 쿼..

서버는... 개똥같이 만들어도 돌아간다...우리도.. 예쑬을 해야지  https://hcnmy.tistory.com/182 Armeria를 사용하는 이유모든 리소스를 아르메리아로 조지고 있는데 문득 왜 쓰고 있는지 의문이 들었다. https://engineering.linecorp.com/ko/blog/hello-armeria-bye-spring LINE 개발자들이 Spring 대신 Armeria를 사용하는 이유 LINE DEV Meetuphcnmy.tistory.com 올해 4월달에 올렸던 글인데.. 굳이???라는 내용으로 썻던 글인데..나의 무지에서 나온 명백한 헛소리다. 반성합니다.... 무조건 무조건이닷!!! 앞으로는 나는 webFlux + r2dbc 조합만을 이용해서 프로젝트를 진행 할건데아르메..

when ?동시에  병렬로 처리 하고 싶을때 -> 사실 API를 더 작은 기능으로 쪼개서 프론트-엔드에서 동시에를 쏘면 되겠다.하지만 관리 포인트도 늘어나는 등 트레이드 오프 관계이기 때문에 서버 사이드도 적절하게 처리 할 수 있어야 한다.  why ?사용자에게 좋은 쾌적한 경험을 주기 위해서지  두 작업이 병렬로 진행하지만 마무의리는 맞춰야 하는 경우와 그렇지 않는 경우가 있다. 예를들어 검색을 한다고 했을 때1. 검색어 저장2. 검색 결과 리턴 검색어 저장은 검색 결과 리턴하는데 영향도가 1도 없기 때문에결과 리턴과 상관없이 각자도생하면 된다. 이력(History)를 쌓는 경우도 동일하게 처리하면 된다.import kotlinx.coroutines.*val scope = CoroutineScope(D..

결론은..웰메이든 된 제품을 있는 그대로 잘 활용하자 ㅋ 현재까지는 "서브 기능"으로만 이용 했기 때문에 정확도를 크게 신경 쓰지 않았다."주요 기능"으로 많이 사용한다 해서.. 개선 해야지... 해야지. 했던 부분을 진행하려고 한다.  "고도화"를 검색했을 때 "고도 + 화" => (자동화, 선진화, 운동화, 화요일, 멀고도, 밝다고도,...)" ..깜놀! 일단 모든 단어들을 형태소 분석이 되지 않도록 사용자 사전에 추가해서 급한 불을 껏다. ###일차적인 목표는원본 Text가 그대로 나와야 된다고 생각한다.그 이후 형태소로 나눠진 추가적인 결과 리스트가 나오면 덤인것이다. 하지만 지금처럼 전혀 기대 하지 못한 결과가 나와 버렸으니... 튜닝을 해보자! ㅠ 형태소를 분석해주는 친구들이 제법 있다. ht..

aop 는 관심사를 횡단으로 보는 것이다.모든 로직은 위에서 아래로 흘러간다. 근데 이것을 옆에서 보자는 것 이쥬. 옆으로 본다는 것에 대한 느낌을 가져야 한다. 위에서 아래로 내려가는 로직에.. 옆에서 갑자기 깜빡이 키고 새치기 해서 자기 할 일 하는 것이다. 암튼 하고자하는 바는 공통의 로직을 필요한 로직에 때려 받기 위함이다. (물론 모든 로직이 될 수도 있고) 예들들어 모든(필요한) 도메인 로직을 태우기 전에 JWT 체크를 하다던지... 로깅을 하다던지... 하는 작업일 때 깜빡이 키고 진행s! 어떤(유**) 회사의 리소스를 본적이 있었는데 ㅎㄷㄷ모든 EndPoint에서 시작하는 3줄의 로직이 무조건 똑같았다. (로깅을 하는 로직) 누군가는 처리 했어야 했는데.. 그니께.. 주식 상장을 해도..아..

SELECT id, action, regDtFROM ProductWHERE action = 'EARN_TODO'AND style = 'POINT'AND regDt > DATE_SUB(CURDATE(), INTERVAL 7 DAY)AND regDt  VSSELECT id, action, regDtFROM ProductWHERE action = 'EARN_TODO'AND style = 'POINT'AND DATEDIFF(CURDATE(), regDt) = 7  EARN_TODO를 정확히 7일 후에 조건이 충족되면 EARN으로 UPDATE  해줘야 한다.따라서 UPDATE할 대상을 조회하고자 할 때 어떤 쿼리가 더 효과적인지는.. 일단 무조건 피해야할 조건은 컬럼의 함수나 연산을 좌측에 두면 안 된다. ⭐⭐인..