gradle에 대해서 한번 글로 정리할 필요가 있을 것 같아 정리해봤다.물론 두서는 없지만,,gradle groovy 기반의 은 빌드 + 의존성 관리 + 자동화까지 하는 도구이고, maven보다 빠르며 gradlew로 통일된 빌드 환경을 구축할 수 있다.gradle왜 gradle을 사용하는가?프로젝트를 빌드/테스트/패키징/배포까지 빠르게 자동화하기위해서 사용된다.의존성 관리필요한 라이브러리를 선언만 하면 전의 의존성까지 그래프로 풀어서 일관된 결과를 만들게 해준다.자동화컴파일 → 테스트 → 패키징 → 분석 → 리포트 같은 task들을 자동화 할 수 있다.빌드 성능입/출력이 변하지 않은 작업은 스킵하고이전 결과를 캐시로 재사용하고,가능한 작업은 병렬로 돌려서 빠르게 반복 빌드를 할 수 있게 한다.gradl..

지난 번에는 댓글을 n depth 댓글도 허용하는 구조로 변경해보았다. 댓글 최적화 도전기커넥티스트 프로젝트를 진행하면서게시판의 댓글과 대댓글에 대해서 고민했다. 처음에는 댓글 테이블, 대댓글 테이블 따로 구현했는데, 댓글과 대댓글이 과연 분리되어야 하는 엔티티인가에hyogu.tistory.com 이때 발생했던 애로사항이 도메인에서는 트리 구조의 댓글을 사용하는데 디비에서는 그렇지 않다는게 문제였고,만약 읽기 쿼리와 쓰기 쿼리를 통일화 한다면 댓글의 depth를 기준으로 페이징 처리를 하지 못한다는 단점이 있었다. 그리고 또 디비에서 값을 가져올 때는 읽기 전용 쿼리를 사용하여서 클라이언트에서 트리 구조를 적용하였다. ⇒ 읽기/쓰기 쿼리를 통일화 하지 못한다면, 결국 도메인은 트리 구조로 관리되어야 할..

커넥티스트 프로젝트를 진행하면서게시판의 댓글과 대댓글에 대해서 고민했다. 처음에는 댓글 테이블, 대댓글 테이블 따로 구현했는데, 댓글과 대댓글이 과연 분리되어야 하는 엔티티인가에 대해 질문을 받게 되었고,나도 생각해보니 이 둘은 필연적으로 게시글에 속해있어 같다고 생각해 굳이 분리할 필요가 없다고 생각했다. 그리고 현재는 depth 2를 갖는 대댓글만 지원하고 있는데, 이 둘을 한 테이블에 합치면 n depth 대댓글을 효율적으로 구현할 수 있었다.→ 하지만, 도메인의 재설계는 필연적으로 필요했다.그래서 이들이 일단 구현될 수 있는지 실험해보았다. 일단 10 depth 대댓글을 지원할 수 있도록 다음과 같이 디비 스키마를 짜주고mysql> desc comments;+------------+--------..

어제 나를 돌아보며 그간 개발 생활에 대해 회고하면서 특히 중요하다고 생각했던 부분들에 대한 발췌입니다. 결국 지식의 축적과 본인만의 기준을 토대로 한 논리적 설계와 개발이 중요하다고 생각했습니다. 또 하나 느낀 건, 나 스스로 ‘내가 개발을 하면서 정립한 효율적 설계의 기준’에 대해 아직 명확한 언어로 표현하지 못한다는 사실이다. 과거의 프로젝트를 돌아보며 그간 효율적이라고 생각했던 설계들의 공통점을 떠올려보려 했지만, 스스로도 확신을 갖지 못했다. 내가 좋다고 느꼈던 설계가 정말로 의미 있었던 것인지, 혹은 단지 내 기준에만 부합했던 건 아닌지 되묻게 된다. 어떤 것이 ‘좋은 설계’인지에 대한 질문은 여전히 어렵지만, 적어도 그 판단의 기준을 계속해서 날카롭게 세워가야겠다는 다짐은 들었다. 무엇보다..

프로젝트를 진행하면서 JPA에 대한 강연을 할 일이 생겼다.오우 이런 날이 언젠가 올 줄은 알았지만, 그게 다음 주일 줄이야. 사실 Java 기반의 서버를 개발하고 운영하면서 JPA는 매주 중요한 요소라고 생각한다. 그리고 나의 교육/학습 철학 은 정확한 Bias 이기 때문에, 먼저 이를 최대한 정리해보고자 한다. 기술을 배울 때 가장 중요하게 생각하는 것은 왜? 이다. 왜 이 기술이 탄생했고 어떤 문제점이 있었는가?이다.왜 JPA를 사용하는가?객체지향 프로그래밍과 관계형 DB의 간극 해소Java는 객체 지향 언어이고, 데이터는 클래스와 객체로 표현되지만, 관계형 데이터베이스는 테이블, 로우, 칼럼 중심의 정형화된 데이터 모델을 사용한다.애초에 사고방식(의도)과 구조가 다른 모델이다. 예를 들어 상속 ..

guideme project를 진행하면서 생길 수 있는 분산 트랜잭션의 문제에 대해 정리해 봤다.msa를 구현하면서 매번 고민하는 건 역시 데이터 정합성 같다. 예시를 들자면,, 고요 속의 외침 같달까 문제 상황현재 프로젝트 구조auth service → user service 간 분산 트랜잭션을 kafka를 이용한 Choreography기반의 SAGA pattern으로 구현.현재 구조에서 생각해 본 문제:auth service 실패 시, Kafka이벤트를 발행한다. 그러나 Kafka 이벤트 발행에서 문제가 있을 수 있지 않나?auth service 실패 시 발행하는 이벤트는 도메인 이벤트인가? 만약 그렇다면 이벤트 스키마의 주인은 auth인가? 그리고 이를 통일시켜야 하는 것이 어렵다.만약 consu..

이 글에서는 교내 프로젝트에서 Docker Compose를 사용한 경험을 바탕으로 Docker Compose의 개념과 활용에 대해서 알아보고자 한다.Docker Compose란?가장 먼저 docker compose가 뭔지 알아보고 이를 왜 사용하는지 알아보고자 한다.Docker compose는 여러 컨테이너를 한 번에 정의하고 관리하기 위해서 사용한다. 단일 컨테이너를 Dockerfile로 정의하고 빌드-배포-사용하는 일련의 과정들은 꽤 간단하다. 하나의 Dockerfile로 전부 처리 가능하기 때문이다. 그런데, 만약 한 서비스에 여러 컨테이너가 필요하다면? 여러 Dockerfile을 한 번에 실행시키는 것은 여간 불편한 일이 아닐 수 없다.그래서 Docker Compose를 사용하는데, 이는 여러 개..

GDGoC GIST활동 중 Guide me 프로젝트에서 처음으로 OAuth2.0을 도입하여 인증 로직을 외부 IDP에 위임하는 시도를 해보았다. 이전까지는 직접 인증/인가 로직을 구현해 왔지만, 이번에는 GSA 통합 계정을 활용해 인증을 위임해 보았다.이 글에서는 코드 레벨의 구현보다는 좀 더 큰 레벨에서 로직을 어떻게 만들었는지 정리하고자 한다.왜 권한 위임을 하는가?권한 위임을 시도한 이유는 비즈니스 로직 간소화와 사용자 만족도 향상이다.사용자가 이미 신뢰하는 GSA IDP(Identity Provider)로 인증을 넘기면, 우리 서비스는 회원 정보 관리와 인가(Authorization)에만 집중할 수 있다. 그리고 사용자는 신생 서비스에 새 비밀번호를 맡기기보다, 기존 GSA 계정으로 Single ..