이제 프로젝트의 막바지다.뭔가 처음 구상대로 흘러가지 않는 느낌이다.잘하고 있는지도 모르겠구...잘되고 있는지도 모르겠다.개발은 기능개발은 다 된거 같은데..내가 맡은 곳이 주문/결제 쪽이라 테스트하기가 쉽지가 않다.아무래도 엔드포인트가 되기때문인가?테스트만 잘 진행하면 무리 없을거 같은디...이거이거 잘되고 있는지 잘모르겠네..
오늘 플로우 정리를 하고 멘토님께 질문을 하였다.대충 플로우는 위와 같다.저 플로우가 맞다고 하셨고 나는 저렇게 개발을 완료하고 admin즉 마스터쪽 개발하기 위해 확인하였다. 근데 admin쪽이랑 일반이랑 같은 API가 있어서이 부분은 어떻게 하면 좋을지 여쭤보았다.멘토님께 여쭤보니 어드민쪽도 필요는 하다고 하셨고 그렇게 진행하기로 했다.멘토님이 말씀하시길 분리하는것이 맞다고 하셨고 권한 부여를 할때 많이 까다롭다고 하셨다.나는 동의했고 내일 수정 예정이다.원래 오늘까지 진행예정이었는데 오늘은 멘토링 준비하러 간다. 총총총공부한거 없을때 요런거 싸지르기..
메모리 절약을 위해, 인스턴스가 필요할 때 똑같은 인스턴스를 새로 만들지 않고 기존의 인스턴스를 가져와 활용하는 기법리소스를 많이 차지하는 역할을 하는 무거운 클래스일때 적합장점클래스가 하나의 인스턴트만 갖는다는 것을 확신할 수 있습니다.여러 개의 인스턴스를 생성할 필요가 없으므로 메모리 낭비를 방지함이 인스턴스에 대한 전역 접근 지점을 얻습니다.새로운 객체를 계속 만들 필요 없이 하나의 인스턴스를 공유하므로 메모리 사용량을 줄일 수 있음싱글턴 객체는 처음 요청될 때만 초기화됩니다. 필요할 때만 객체가 생성되므로, 불필요한 메모리 사용을 방지단점단일 책임 원칙을 위반합니다. 이 패턴은 한 번에 두 가지의 문제를 동시에 해결합니다.객체 관리와 로직 처리를 동시에 하기 때문에이 패턴은 다중 스레드 환경에서 ..
gpt로 엔티티를 만들었더니@Id@GeneratedValue(generator = "UUID")@GenericGenerator(name = "UUID", strategy = "org.hibernate.id.UUIDGenerator")@Column(columnDefinition = "UUID", updatable = false, nullable = false)private UUID id;요렇게 만들어줬다. 그리고 나서 정상적으로 테이블이 생성된걸 확인하고커밋을 하려고 했다.. 그런데!!!경고문이 발생해서 혹시나 해서 확인해보니더 이상 UUID는 위 방식처럼 만들 수 없었다.그래서 인터넷을 찾아보니https://stackoverflow.com/questions/76723290/using-the-new-typ..
어제 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. 복잡성 증가 : 복잡도가 증가하다..