라니킴의 기록 남기기

브라우저는 보안상의 이유로 다른 출처의 리소스를 사용하는 것을 기본적으로 제한하고 있다. 다른 출처의 리소스를 불러오려면 접근할 수 있는 권한을 달라고 브라우저에게 요청을 해야한다. 이번 프로젝트 중 프론트엔드 서버에서 백엔드 서버에 접근하니 아래와 같은 요청이 떴다. CORS 정책에 의해서 다른 출처의 서버에 접속하는 것이 막혔다고 브라우저에서 에러를 발생시켜준 것이다. 권한 요청을 Http header에 담아보내 접근할 수 있는 권한을 부여하도록 브라우저에게 알려주어야 한다. 백엔드에서 몇 가지 설정이 필요했다. 이번 프로젝트에서 Spring Security + JWT 를 사용했기 때문에 Client는 API 호출 시 모든 요청에 대해 Header의 Authorization에 JWT 토큰을 전송한다...

조회하는 부분에서 속도가 너무 느려서 성능 최적화를 하기 위해 query를 자세히 살펴보았다. 역시 N+1문제가 발생하고 있었다. N+1문제란? JPA로 애플리케이션을 개발할 때 성능상 가장 주의해야 하는 문제다. 처음 조회한 데이터 수만큼 다시 SQL을 사용해서 조회하는 것이다. 예를 들면 회원이 5명이면 회원에 따른 주문도 5번 조회된다. N+1이 발생하면 SQL이 상당히 많이 호출되므로 조회 성능에 치명적이다. 지연로딩으로 모두 설정해놔서 N+1문제에서 자유로울 것이라고 생각했는데 N+1 문제는 즉시 로딩과 지연 로딩일 때 모두 발생할 수 있다고 한다. 개선한 부분 1. 주변 식당 리스트 조회 join fetch 적용 전 join fetch 적용 후 식당조회시 리뷰까지 한 번에 받아오는 것을 볼 수..

도메인 주도 설계에 따르면 dto는 애플리케이션 레이어이기 때문에 Dto는 Entity에 의존할 수 있지만 Entity는 dto를 몰라야 한다. 기존에 작성해 놓은 코드를 보면 엔티티에서 dto에 의존하고 있는 부분이 여러군데 있었다. Entity는 최대한 깔끔하게 두도록 하자. 1. Restaurant Entity 1.1 수정 전 RestaurantService Restaurant entity 1.2 수정 후 RestaurantService Restaurant restaurant = requestDto.toEntity(); 2. Meeting Entity 마찬가지로 Meeting Entity에서 Dto에 의존하고 있다. Entity는 Dto 존재를 몰라야 한다. Entity는 최대한 깔끔하게 두어야 ..

조회 API에서 N+1 문제 해결 한 부분을 jmeter를 이용해 테스트를 해서 어떤 개선이 있었는 지 결과를 비교해보았다. 엄청난 효과다... 미팅 상세보기 API는 불필요하게 DB호출하는 로직도 많고 중복으로 호출하고 있는 부분이 많아서 뺄 건 다 빼버렸다.

springbootTest를 시행하면 연결되어있는 DB로 데이터가 이동된다. rollback이 된다고 하더라도 데이터가 DB에 들어갔다 오는 것이기때문에 test환경에서만 사용할 수 있는 DB를 h2로 설정을 했다. * build.gradle 에 추가 testImplementation 'com.h2database:h2' * FoodMapApplicationTests.java @ActiveProfiles("test") @SpringBootTest(properties = "classpath:application-test.yml") @AutoConfigureMockMvc class FoodMapApplicationTests { @Test void contextLoads() { } } * src/test/res..