어제 api명세서, 테이블명세서, erd를 제출하고 오늘 리뷰를 받았다.우리팀같은 경우 매일 아침 9시에 리뷰를 하기로 해서 국비가 시작하는 10시보다 1시간 일찍 만나기로 했다.오늘이야 어제 작성한 문서를 토대로 같이 이야기를 해본 시간을 가졌다.문서를 작성하면서 의문을 가진것들은 바로 튜터님께 여쭤보기로 하였다.10시가 되자마자 튜텨님에게 달려가서 질문을 하였다.튜텨님께서는 잘했다고 하셨고, 명세서를 하나로 합쳐달라고 부탁하셨다.왜냐하면 내가 문서들을 링크들로 올려둔 상태였기 때문이었다.암튼 이런 피드백을 받고, 수정할거 수정하고... 다행히 11시에 블로그 제출을 완료하였다.그리고 그 문서는 2시30분에 튜터님께서 리뷰를 해주셨다.튜텨님은 잘했다고 칭찬해주셨고다만 아쉬운건 메뉴옵션부분이 주문시에는 ..
국비지원 첫 팀 프로젝트팀원: 박용훈, 김대연, 김수현, 백승규API 명세서https://www.notion.so/teamsparta/1982dc3ef514804ab7d9e1dfb3b9b7d0?v=1982dc3ef51481428b75000cf38890d1 API 명세서 | NotionMade with Notion, the all-in-one connected workspace with publishing capabilities.teamsparta.notion.site 기능설명컨트롤러권한Http 메서드PathheaderRequestResponse담당자텍스트1. 사용자(User) API1.1 회원가입auth-controllerALLPOST/api/users/register {"username": "john..
이런 생각이 들었다. 과연 N+1문제는 문제인건가?그냥 쿼리 하나가 증가했을뿐인데 성능에 그리 큰 영향을 주나?근데 이건 이렇게 단순하게 생각할 문제는 아니다.쿼리가 하나 증가하는게 문제인게 아니고 그 쿼리가 불필하다는게 문제다.그러니까 나오면 안되는게 나왔다고 보는거다.무리에 불청객한명만 있어도 불편한것처럼 불필요한 쿼리가 증가한건 굉장히 불편한 일일것이다.게다가 한개만 증가한걸로도 성능에도 영향을 줄 수 있다.일단 생각해야 하는것이 쿼리의 양은 모른다. 쿼리가 긴지 짧은지 전혀 모른다.쿼리가 무지무지 길다면 쿼리 하나 증가하는건 굉장히 치명적일거라 생각한다.내가 하고 싶은말은 N+1을 반드시 해결해야 하는건 성능때문이 아니라 생각한다. 그저 불필요한 쿼리가 하나가 더 추가된게 더 큰 문제라 생각한다..
현재 msa를 수강중에 있는데 다른 용어들은 들어봤었지만 서킷 브레이커는 처음 들어봤다.인터넷에 찾아보니 서킷 브레이커는 회로 차단기라고 한다. 서킷 브레이커는 서비스간의 호출을 감지하고 시스템의 안정성을 유지한다는 거라고 한다.MSA가 각 서비스를 모듈로 각각 만드는건데..그렇다는건 그냥 500에러를 뱉어서 처리를 할 수 도 있겠지만 그렇게 되면 안정성과 거리가 멀어진다.애초에 이렇게 만들꺼면 msa를 왜 하는지 모르겠다.암튼, 서킷 브레이커는 서비스 간의 호출 실패를 감지하고 시스템의 전체적인 안정성을 유지를 하는거라고 한다.아까 사전적 정의가 회로 차단기라고 했는데여기서는 회로가 무엇을 말하는 걸까?그리고 무엇을 차단한다는 걸까?그러니까 서비스끼리 전파가 회로구그거에 대한 차단을 말하는 거였다!!결..
msa는 하나의 독립적인 서비스를 분리하여 개발하는 것을 말합니다.이는 하나의 스타일이며 권고 사항은 아닙니다.MAS는 다음과 같은 특징을 가지고 있습니다. 1. 독립적 배포 : 각 서비스 마다 개발이 가능하기 때문에 독립적으로 배포가 가능합니다. 만약 모놀로식으로 개발하게 된다면 하나의 서비스를 개발하고 배포를 해야 한다면, 개발이 되지 않는 서비스들도 함께 배포를 해야 합니다.2. 유연성 증가 : 유연성이 증가한다는 건 각자의 서비스마다 다른 스타일로 개발이 가능하다는 점에서 유연성이 증가하게 되어집니다.3. 확장성 : 이 특징같은 경우 특정 서비스를 고도화를 한다고 생각했을때, 좀더 체계적으로 개발할 수 잇다는 특징을 가지고 있습니다.하지만 단점도 존재합니다.1. 복잡성 증가 : 복잡도가 증가하다..
블로그글을 안쓴지 1년이 넘어간다. 사실 이렇게 까지 운영을 안하려고 했던건 아니였는데 어쩌다보니 이렇게 되었다. 지금까지 나는 개발자라는 직업으로 발전을 시킬 수 있을지 고민을 했다. 어떻게 하면 더 잘 할 수 있을지.. 하지만 올해는 아니였다. 개발자에 대한 능력을 키우는 것보다 내 자신에 대해 조금더 심도 깊게 생각할 시간이 필요했다. 결론부터 말하자면 의미가 없었다. 더 정확히 말하면 완전히 의미는 없지는 않는건 아니지만 글로 적기에 애매한 거 같다, 올해는 정말 미치는 듯이 놀았다. 적금도 최소한으로 하고.. 놀 수 있으면 놀고 그랬다. 공부는 하지 않고 놀았다. 올해 처음으로 해외여행도 갔다. 비록 혼자가긴 했지만 아무튼 좋았다. 뭐가 좋은지에 대해서는 적지는 않겠지만 아무튼 좋았다. 솔직히 ..
Spring data JPA에서는 많은 확장 기능을 제공하고 있다. 사용자 정의 리포지토리 구현 (잡 글) 일반적으로 Spring data JPA에서는 public interface MemberRepository extends JpaRepository {} 인터페이스를 통해서 JPA를 사용하고 있다. 근데 마이바티스 나 네이티브 쿼리를 사용하는 경우 위 인터페이스는 의미가 없어진다. 왜냐하면, JPA에서 이들을 관리할 수 없기 때문이다. 결국 이들을 사용할때 엔티티와 테이블간의 간극이 발생할 수 있다는 건데 이를 해결하는 방안으로는 강제로 영속성 컨텍스트를 초기화를 시켜줘야 가능하다. 그러면 위 인터페이스를 이용하면 어떨까? 결론부터 말하면 굉장히 비효율적이다. 아까도 말했듯이 마이바티스나 네이티브 쿼리..
rollup vs cube vs grouping set 공부를 하면서 이 3가지가 굉장히 헷갈렸다. 특히 group by가 2~3개 이상 섞여있을 때 굉장히 문제를 해결하기 어려웠다. 이들을 쉽게? 해결하는 방법은 갯수를 세어 보는 방법이다. 예시 쿼리를 보여주고 싶기는 한데 그거까지 하기에는 조금 귀찮은 감이 조금 있어서 그거는 생략하도록 한다. c1 c2 count A 1 1 A 2 1 A 2 B 1 1 B 2 2 B 3 테이블이 이렇게 되있다고 생각해보자. 그럼 제일 먼저 해야 할 일은 count가 어떻게 들어 오는지 파악해야 한다. 확인 결과 (c1,c2) => A,1 이 1개라는 것을 알 수 있다. 이렇다는 것으로 미뤄봤을때 group by는 c1과 c2둘다 해당 된다는 것을 알 수 있다. 근데..
오랜만에 작성하는 것 같다. 요즘 공부하는 패턴들이 생각보다 쉽지 않아 계속 미루고 있었는데 이 패턴은 그 나마 설명할 수 있을 것 같다. 근데 중재자라고 하는데 뭐를 중재하는 걸까? 이건 현실 세계에 비교 하면서 생각하면 좋은데 비행기와 관제탑 배와 등대 라고 볼 수 있다. 이들에 대해서는 자세히는 설명하기는 어렵지만 관재탑과 등대 모두 비행기와 배를 위해 어떤 특정한 작업을 하는 느낌이다. 사실 중재자라는 이름 보다는 중간 체계?이런 이름이 더 어울리는 것 같은데 이것을 그림으로 그려보자. 이런 그림이 그려지는데 이것을 해석해보면 A 에서 B를 갈려면 X를 거쳐야 한다는 뭐 그런 것 같다. 요게 uml인데 첫번째꺼 말고 두 번째를 보면 c1이 c2에게 연락을 취하기 위해서는 mediator에 먼저 연..
이제 문서를 빌드해보자. 그전에 pom.xml에 다음을 작성하자. org.asciidoctor asciidoctor-maven-plugin 1.5.8 generate-docs prepare-package process-asciidoc html book org.springframework.restdocs spring-restdocs-asciidoctor ${spring-restdocs.version} maven-resources-plugin 2.7 copy-resources prepare-package copy-resources ${project.build.outputDirectory}/static/docs ${project.build.directory}/generated-docs 만약에 버전이 맞지 않는..