Tempo Tempo

문제 상황현재 A Entity가 @OneToOne으로 두 개의 Entity를(C, D)를 갖고 있다. 연관관계의 주인이 아니기 때문에, mappedBy로 가지고 있는 상태이다. 이후 필터링 기반 동적조회 쿼리를 queryDSL로 작성했다. A Entity에서 @OneToOne 연관관계를 가진 Entity에 FetchType.LAZY를 적용해놓아도, C/D Entity가 계속해서 즉시로딩되며 문제를 발생시켰다.100개의 A Entity row 조회였지만, respnose 시간이 2.18초로 매우 낮은 성능을 보여주었다...(평균적으로 2.5초 정도 걸렸다.)원인먼저 결과부터 말하면, JPA @OneToOne 연관관계에서 mappedBy로 Entity를 가지고 있는 Child Entity는, 항상 Paren..

Http Standard로는, Get 요청에는 Body가 존재하지 않는다. 모든 데이터를 QueryString으로 처리할 뿐이다. 하지만, 복잡한 검색 조건이 담긴 필터링은 JSON 필터 정보들을 담을 공간이 필요하다. 이때 검색을 위해서는 HTTP METHOD GET을 써야할까, POST를 써야할까?StackOverflow에서도 POST 요청을 사용하는 것이 좋다고 하지만, 확신을 가질 수 없었다.https://stackoverflow.com/questions/20550514/post-or-get-in-a-search-form그래서 HTTP Protocol에 대한 RFC 문서를 찾아보며 각 METHOD를 사용할 때를 가정한 후 결정을 내렸다.GETGET을 사용한다. 하지만, 일반적으로 Get 요청에는 ..

"페어링 중고거래 플랫폼"이라는 프로젝트를 진행하면서, 발생한 기술적 이슈들을 어떻게 해결했는지에 대해서 기술 블로그를 만들게 되었습니다. 페어링 중고거래 플랫폼 2024.02 - 진행 중 6인 프로젝트 프론트엔드 2명, 백엔드/인프라 4명 에어팟과 같이 각 부분별로 중고 거래글을 올리는 선택지와 다른 사람들과 합쳐 한 개의 상품으로 판매할 수 있는 선택지를 줄 수 있는 통합 중고거래 플랫폼입니다. Jenkins, Docker를 이용한 CD 환경 구축을 통한 기존 수동 빌드 시간 제거 Kafka를 통한 애플리케이션 레이어 / 메세지 브로커 분리, 영속성 보장 Kafka-ui를 도입해 기존 토픽/컨슈머 확인 시간을 5분 → 10초 이내로 단축 Cloudflare를 활용한 SSL/TSL 인증서 적용 및 DD..

기존에 알고있듯이 @OneToMany와 같은 어노테이션이 붙어있는 필드 엔티티는 FetchType.LAZY가 기본값이고, @ManyToOne과 같은 어노테이션은 FetchType.EAGER가 기본값이다. FetchType.EAGER가 붙어있는 필드 엔티티는, 해당 필드를 포함한 엔티티를 조회하는 순간 해당 필드 엔티티도 조회하게 된다. @xxToOne 연관관계인 필드 엔티티에는 FetchType.LAZY를 붙이는게 대부분 좋다는 것을 김영한님 강의에서도 들어서 알고는 있었는데, 붙이지 않고 구현한 경우가 생겨 트러블 슈팅을 하게 되었다. 지금 개발중인 비즈니스 로직에는 ChatRoom(채팅방 정보), UserChatRoom(채팅방에 참여하고있는 사용자 정보), Chat(채팅 메세지 정보) 총 세개의 엔티..

예전에 공부한 Spring Controller에서 쓴 내용이 잘못 됐다는것을 발견했다. https://tmpfactory.tistory.com/39?category=932695 Spring 완전정복 - 1 / Controller Spring에서 페이지를 띄우는 여러 방법 1. 정적 페이지, MVC와 템플릿 엔진 위 그림과 같이 동작하는데, 각각의 경우에 따라 다르게 동작한다. 정적 페이지를 호출 할 경우 -> http://localhost:8080/hello.htm tmpfactory.tistory.com 문제가 된 것은 이 부분이다. Spring Bean은 싱글톤 형식으로 Spring Container에 담겨져 있다는걸 공부하고 있을 때, 이러한 싱글톤 객체에는 필드를 가지고 있어서는 안 된다는것을 알..

스프링은 필요한 메소드들을 스프링 컨테이너에 빈 형태로 관리하게 되는데, 그 동안 DIP(Dependency Inversion Principle)를 지키기위해 AppConfig이라는 Config 파일을 만들어두어, 스프링 빈으로 등록해서 사용해왔다. 코드만 보면, memberRepository() 메소드가 총 3번 실행된다. 1. memberService()에서 2. memberRepository()를 Bean에 등록 할 때 3. orderService() 하지만, 실제로 테스트를 돌려보면 각각의 메소드는 한 번만 실행된다. package hello.core; import hello.core.discount.DiscountPolicy; import hello.core.discount.RateDiscoun..

중요하게 생각한 부분들 설계 단계에서 인터페이스와 구현체들을 잘 생각해야 한다. 이 강의에서는 회원 정보, 주문 처리, 할인 처리 와 같이 각 역할들을 나누어 다른 패키지로 관리 + 각각 인터페이스 생성 과 같은 형식으로 후에 수정하거나, 다른 사람이 해당 프로젝트에 참가하게 되어도 쉽게 알 수 있게 프로젝트를 관리한다. 이 부분이 가장 중요하다는 생각이 듦. 테스트 코드는 필수다. 실제 DB에 넣고 호출하는 부분까지는 나중에 한다고 하더라도, 적어도 멤버 객체를 저장하고 호출해 유효한지 검사하는 테스트 코드 정도는 꼭 있어야 나중에 웹 서버를 올릴 때에도 유용하다. 그리고, 프로젝트에 테스트 패키지가 따로 있기 때문에 후에 서버에 올릴 때에도 테스트 코드는 올라가지 않는다. 이 부분도 중요한듯

앞쪽 부분은 기본적인 프로젝트 세팅이나 인터페이스 / 간단한 구현체 생성 정도였기 때문에 기록을 생략한다. 하면서 중요하다고 생각이 든 부분들 SOLID 객체지향 5대 원칙 그냥 매번 달달 외우는식으로 공부를 했었는데, 초반에 자세하게 설명해주셔서 개발시 실제로 적용되는 부분들에 대해 생각을 할 수 있었다. Single Responsibility Principle 단일 책임 원칙 하나의 클래스는 하나의 책임만을 가져야한다. Open - Closed Principle 개방 - 폐쇄 원칙 확장에 열려있어야하고, 변경에 닫혀있어야한다. 이 원칙과 아래에 나올 DIP 원칙이 가장 중요하다고 생각이 든다. 인터페이스 구현 -> 구현체 적용 과 같은 방식으로 개발을하게 되는데, 인터페이스를 잘 구현해 두면 따로 인..