오늘 한것들

1.오전에는 CORS문제로 프론트와 백엔드간의 소통이 있었다. 처음에는 배포 서버에 요청을 보냈으나 계속해서 CORS문제가 발생을 해서 내가 서버를 띄운 뒤 NGROK를 통해 프론트 측의 문제를 해결했다

corsConfiguration.setAllowedOrigins(List.of("*"));

SecurityConfig의 cors 옵션을 다음과 같이 설정해서 해결했다. 결국 프론트 서버의 AllowedOrigin은 열어뒀지만 요청을 보내는 곳의 AllowedOrigin을 안열어서 발생한 문제인거 같다.

 처음에 그래서 요청을 보내는 localhost포트를 열어주면 되는거 아닌가 했는데 동료분 말씀대로 localhost는 내 포트를 여는거지 상대방 포트의 요청을 열어버리는게 아니기때문에 별관련없는거같다 테스트는 안해봤다.

 

그리고 오늘 프론트 분이 주신 요구사항을 반영한 걷기 전체기록 조회 관련 로직을 작성했다.

이번에 새롭게 잘 써먹은 로직은 JPA Repository의 findBy... 메서드

메서드 명을 잘 지으면 해당 메서드 명대로 데이터를 조회해준다

가령

Page<WalkLog> findAllByWalkLogPublicSettingAndMember_MemberId(Pageable pageable,
                                                              WalkLog.WalkLogPublicSetting walkLogPublicSetting,
                                                              Long memberId);

위와 같은 메서드명은 WalkLogPublicSetting과 Member 객체에 있는 memberId값으로 들어온 값과 일치하는 값만을 데이터에서 조회해서 Page<WalkLog>로 반환한다.

메서드명으로 쓰는게 나는 생각보다 되게 편리했지만 단점이 있다면...

1. 메서드명이 길어질수록 가독성과 가시성이 떨어지는 점이 분명 존재한다.

2. 정확한 쿼리문을 작성해서 사용하는것보다는 정확성이 떨어질 수 있고 메서드명으로 하는 것은 쿼리문으로 작성하는것에 비해서는 한계가 존재하는 느낌이 강했다.

그럼에도 불구하고 간편하긴 했다

 

다만 날짜와 관련해서 조회조건을 어떻게 설정하는지 고민이었는데... 블로그를 참고해서 해결했다((JPA) find date between 날짜 사이 찾기 :: 해보고나면 별거아니다 (tistory.com))

Page<WalkLog> findAllByWalkLogPublicSettingAndCreatedAtBetween(Pageable pageable,
                                                               WalkLog.WalkLogPublicSetting walkLogPublicSetting,
                                                               LocalDateTime start,
                                                               LocalDateTime end);

다음은 WalkLogPublicSetting와 start와 end 사이의 시간인 객체들을 전부 Page<WalkLog>에 담아서 반환해준다.

같은 팀원이신 분은 @Query 애너테이션을 통해 다음과 같은 방식으로 해결하셨다

@Query("FROM WalkLog w WHERE MONTH(w.createdAt) = :month")

쿼리문을 작성해보는 연습을 한다는 점에서 팀원분의 방법이 좀더 적절하다는 생각이 든다. JPA안쓰고 JDBC쓰면 어쩔껀데...

 

작업물을 PullRequest 하는 과정에서 프론트 분이 원하는건 멤버 1명이 작성한 자기 게시물을 전부 조회하는건데 내가 자기 게시물이 아니라 전체 게시물을 조회하는 로직을 짰다는 사실을 알았다..

 

문제 해결을 위해서 기존 로직은 그대로 놔두고 추가로 memberId를 @Pathvariable로 받고 해당 멤버아이디 조건을 추가해 조회하는 방식으로 변경했다. 기존 로직을 거의 재활용해서 시간은 얼마 걸리지 않았다.

memberId를 사용하고 멤버의 게시물을 조회하는 만큼 MemberController에서 로직을 작성했는데 pullRequest하는 동안 해당 MemberController가 Conflict가 났다

 

MemberController를 담당하시는 분과 함께 충돌난 부분을 열심히 수정하고 오랫동안 커밋을 안한 상태여서 다시 git pull origin be-dev를 통해 가장 최신의 데이터를 받았는데 여기서 또 충돌이 발생했다. 어찌저찌 수정하고 pull을 한 뒤 결국 합쳐서 해결되었다.

 

오늘 반성하는 점은 의사소통을 자주해야하고 상대방이 구현하고자 하는 목표를 정확하게 캐치하는 습관을 들여야할것 같다. 그리고 어중간한 이해도로 구현하지 말기 구현해야할 목표는 적어도 정확히 할것 그냥 아~ 대충 그렇구나 하다가는 오늘같은 일이 다시한번 발생할것같다

 

앞으로 해야할 부분은 mapImage를 walkLog에 추가해야하고, 기존 코드를 객체지향적으로 리팩토링 해야한다. 그리고 웹소켓이 프론트와 잘 통신될수 있도록 설정해야하고, 프론트와 백엔드 도메인을 합쳐야한다.

웹소켓은 다같이 하면 어떻게든 되겠지인데 도메인을 합치는게 좀.... 어케해야하지 라는 생각이 좀든다.

우선 ec2의 경우 도메인 설정을 위해서는 정확하지 않지만 도메인을 구매하긴 해야하고 vercel도 확인해보니 유료플랜이 아니면 원하는 도메인명 설정이 불가능 한듯 하다.

개인적으로 원하는 방식은 프론트분들이 aws을 통해서 프론트 배포를 실행해서 aws로 전체 배포를 실행하는것... 이게 좋은 이유는 aws 하나로 모든걸 해결할 수있다!(애초에 하나의 클라우드 서비스인만큼 서로 연관관계를 잘 만들어 뒀다)

안되면 vercel 유료플랜이라도 쓰던가 방법을 찾아야하지 싶다. 아~~