Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Team-03-BE] Issue Tracker 3주차 PR #54

Merged
merged 14 commits into from
Aug 13, 2023

Conversation

jinny-l
Copy link

@jinny-l jinny-l commented Aug 11, 2023

👋 To Reviewer

안녕하세요, 새리~
3주차 PR입니다.

요번주 구현한 기능 및 구현하면서 고민했던 부분을 PR에 작성했습니다.
배포한 서버 주소도 전달드립니다!

아 그리구 전주 PR에 답변을 못 드린 것이 있어 댓글 남겨놓았습니다!

🔑 Key changes

  • 이슈 수정 기능
  • 이슈 상세 페이지 조회 기능
  • 이슈 상태(Open/Close) 변경 기능
  • 코멘트에 반응을 추가하는 기능
  • 필터에서 마일스톤 목록을 조회하는 기능
  • 필터에서 담당자 목록을 조회하는 기능
  • Github OAuth Login 기능
  • 일반 Login 기능
  • 전반적인 리팩토링
    • 팀 코딩 컨밴션 적용
    • issue 도메인을 2개로 분리: issue & issueInfo(Label, Assignee)

남은 기능

  • 이슈 필터링 기능
  • 파일 첨부 기능
  • 오가니제이션 CRUD

🤔 고민

DB에서 updatedelete을 할 때 리턴타입이 고민됩니다.

  • ID는 파라미터로 받기 때문에 ID를 다시 리턴하는 것은 의미가 없기 때문에 우선 대부분 void 타입으로 되어있습니다.
  • 또, JdbcTemplateupdate 메서드를 참고했을 때 반환 값은 변경된 컬럼의 수이므로, 의도했던 컬럼에 데이터가 정확히 반영되었는지는 알 수 없어 컬럼 수로 검증하는 것에 의미가 있는지 의문입니다.
  • 다만 이럴 경우 통합 테스트에서 해당 컬럼이 제대로 변경되었는지 확인하는 방법이 없어보입니다.
  • 지금 생각나는 방법은 findBy로 객체를 찾아와서 전후 값을 비교하는 것입니다.

여러개의 테이블의 정보가 필요한 경우 VO를 만들었습니다.

  • Join이 필요한 경우 결과를 entity에 매핑할 수 없어 응답 API 형태에 맞게 VO를 만들었습니다.
  • Join 결과를 VO로 매핑하는게 맞는건지, 테이블 별로 Enity를 만들어 어플리케이션 단에서 조합을 해 DTO를 만들어야 할지 고민이 됩니다.
  • VO를 선택한 이유는 원하는 데이터를 조회하는 것이 DB의 역할 중 하나라고 생각했습니다.
  • 따라서 어플리케이션에서 각 테이블의 정보를 조합하는 것보다 Join 기능을 활용하여 응답에 필요한 데이터를 한번에 데이터를 가져오는게 더 적절한 방법이라 생각했습니다.
  • 하지만 이렇게 할 경우 ResultSet으로 매핑을 할수있는 객체가 없었고 따라서 VO라는 객체가 필요했습니다.
  • 그런데 막상 VO를 만들고 보니 개발자 편의를 위한 것이 아닌가 싶기도 하고
  • 결국엔 VOAPI 응답에 맞게 만들어졌기 때문에 DTO로 변환되지 않고 Repository에서 그대로 Controller까지 올라가게 됩니다.
  • 이렇게 될 경우, VO는 개발할 때는 편하지만 요구사항이 수정될 경우 모든 계층이 VO에 의존적이기 때문에 모든 계층의 코드를 고쳐야 하는 것이 단점이라 고민이 되었습니다.

DB에서 1개의 Row를 찾을때 query()를 사용하는 것이 EmptyResultDataAccessException 오류 방지차원에서 적절한 방법인가?

  • 집계 함수는 항상 결과 값을 가지므로 queryForObject()를 사용해도 해당 오류가 발생하지 않습니다.
  • findById와 같이 특정 id로 데이터를 찾을 때, 데이터가 없으면 EmptyResultDataAccessException 예외가 발생하여, queryForObject() 대신 query()를 사용했습니다.
  • 현재는 query()로 결과를 찾은 후 .stream().findFirst()로 반환하는 방식을 사용하고 있습니다.
  • 구현하고 보니 NULL 처리냐 예외 처리냐의 문제인데, 결과값이 없을 때 어떤 처리 로직이 있다면 반환값이 <Optional> 이기 때문에 Service에서 NULL 처리는 놓치지 않을 수 있지만, 예외는 명시적으로 발생하지 않기 때문에 놓칠 수 있지 않을까 생각했습니다.
  • 더불어 Service가 예외에 덜 의존적인 측면도 있다고 생각했습니다.
  • 결론적으로 queryForObject() 메서드가 만들어진 이유가 있을텐데 예외가 발생하니 하나의 결과값이 필요한 경우에도 query()를 쓰는게 맞는지 고민이 되는 것 같습니다.

응답 코드의 사용을 구체적으로 나누는지 궁금합니다.

  • CRUD 를 할때 POST에 대한 응답으로 201을, DELETE에 대한 응답으로 204를 사용하는 등 현업에서도 디테일하게 분리하는지 궁금합니다.
  • 아니면 팀 컨밴션에 따르는지요?

🧞‍♂️ Jinny

생각보다 기능 구현이 오래 걸리고 있습니다.
기능 구현이 우선이라고 생각되어 예외 처리 및 테스트 코드는 후순위로 밀고 기능 구현에 집중하고 있는 상황인데
하나의 기능을 구현하더라도 제대로 구현을 해야하는 것인지... 지금의 학습 방향이 올바른 학습 방향인지 고민이 됩니다.
관련해서 새리의 조언을 듣고 싶습니다!
태풍 피해 조심하시구 안전한 주말 보내세요 🙂

🍫 Charlie

아직 Member 쪽에서 Oauth 로그인, 일반 로그인, 일반 회원가입 하는 코드에 대해서 기능 구현만 한 상태입니다.
빠른 시일내에 예외처리 및 코드 리팩토링을 진행하겠습니다.
이번주도 감사합니다! 새리

jinny-l and others added 14 commits August 7, 2023 16:13
* refactor: 불필요한 static 메서드를 인스턴스 메서드로 수정

* feat: 이슈 담당자 수정 기능 구현

* feat: 이슈 레이블 수정 기능 구현

* feat: 이슈 마일스톤 수정 기능 구현

* feat: 이슈 제목 수정 기능 구현
* feat: issue 상세페이지 조회시 comment정보를 가져오는 기능 구현

* refactor: Jinny 리뷰에 따른 코드 수정
* refactor: 마일스톤 필터별 전체목록 조회시 필터에 해당하는 마일스톤만 응답에 포함하도록 수정

* refactor: 마일스톤 필터 목록 조회시 열려있는 마일스톤만 응답으로 보내도록 수정

* refactor: 리뷰에 의한 수정
* feat: 이슈 상태 개별 변경 기능 구현

* feat: 이슈 상태 일괄 변경 기능 구현
* refactor: 개별 마일스톤 및 전체 마일스톤 조회시 보내주는 응답 수정

* refactor: 마일스톤 갯수 조회시 열린 마일스톤의 갯수만 응답에 포함하도록 수정
* fix: 기본 생성자와 setter가 없어 Emoticon API에 Null 값이 들어오는 이슈 수정

* 추후에 setter 안쓰게끔 리팩토링 필요

* fix: 상수에 테이블 필드명을 잘못 입력해서 RowMapper에서 값을 못 불러오는 이슈 수정

* feat: 이슈 상세 페이지 조회를 위한 이슈 담당자 조회 기능 구현

* feat: 이슈 상세 페이지 조회를 위한 이슈 라벨 조회 기능 구현

* feat: 이슈 상세 페이지 조회 기능 구현
* refactor: 코드 컨밴션에 맞게 Comment/CommentRepository 리팩토링

* refactor: 코드 컨밴션에 맞게 LabelRepository 리팩토링

* refactor: rowMapper 이름을 컨밴션에 맞게 수정

* refactor(code with me): 코드 컨밴션에 맞게 LabelRepository 리팩토링

* refactor: 코드 컨밴션에 맞게 MemberRepository 리팩토링

* refactor(code with me): 코드 컨밴션에 맞게 MemberRepository 리팩토링

* refactor: 대문자로 시작하는 메서드명 수정

* refactor: SqlParameterSource를 BeanPropertySqlParameterSource로 수정

* refactor(code with me): SqlParameterSource를 BeanPropertySqlParameterSource로 수정

* refactor: 코드 컨밴션에 맞게 MilestoneRepository 리팩토링

* refactor(code with me): 코드 컨밴션에 맞게 MilestoneRepository 리팩토링

* refactor: 코드 컨밴션에 맞게 OrganizationRepository 리팩토링

* refactor(code with me): 코드 컨밴션에 맞게 OrganizationRepository 리팩토링

* refactor: 코드 컨밴션에 맞게 CommentController 리팩토링

* refactor(code with me): 코드 컨밴션에 맞게 CommentController 리팩토링

* refactor: 코드 컨밴션에 맞게 CommonController 리팩토링

* refactor: 코드 컨밴션에 맞게 FilterController 리팩토링

* refactor: 코드 컨밴션에 맞게 IssueController 리팩토링

* refactor(code with me): 코드 컨밴션에 맞게 IssueController 리팩토링

* refactor: 코드 컨밴션에 맞게 LabelController 리팩토링

* refactor(code with me): 코드 컨밴션에 맞게 LabelController 리팩토링

* refactor: 코드 컨밴션에 맞게 MilestoneController 리팩토링

* refactor(code with me): 코드 컨밴션에 맞게 MilestoneController 리팩토링

* refactor: 코드 컨벤션에 맞게 CommentService 리팩토링 및 코드 reformat

* refactor: 코드 컨벤션에 맞게 filterService 리팩토링 및 dto 리팩토링

* refactor:  코드 컨벤션에 맞게 label service 및 dto 리팩토링

* refactor:  코드 컨벤션에 맞게 milestone service 및 dto 리팩토링

* refactor:  코드 컨벤션에 맞게 milestone repository 리팩토링

* refactor: 코드컨벤션에 맞게 filter 리팩토링

* refactor: 코드컨벤션에 맞게 LabelRepositoryImpl 리팩토링

* refactor: 코드 컨벤션에 맞게 MilestoneRepositoryImpl 리팩토링

---------

Co-authored-by: CDBchan <kdjin1215@naver.com>
#92 [BE] Webconfig에 ec2 주소 추가
* feat: oauth 초기 세팅

* feat: github를 통한 oauth 로그인 기능 구현

* refactor: access_tocken 을 통해 정보를 받아올때 필요없는 부분 삭제

* refactor: memberService 메서드 리팩토링

* feat: 같은 사용자에 대해서 refresh 토큰 발급시 기존 refresh토큰 삭제기능 구현

* feat: local 회원가입 기능 구현

* feat: local 로그인 기능 구현

* refactor: 패키지 재구조화

* feat: jwt 토큰 검증을 위한 filter 기능 추가

* feat: cors 필터 구현

* refactor: github 로그인시 email이 아닌 id를 받아오도록 수정

* refactor: oauth package 이동

* refactor: profile_img_url 삭제에 따른 리팩토링

* feat: jwt 토큰을 통해 memberId가 필요한 controller에 memberId 전달기능 구현

* refactor: IssueController에서 Label, Assignee 관련 Controller 분리

* refactor: IssueRepository를 DB 테이블에 따라 분리

* fix: 이슈 삭제 시 잘못된 코멘트를 삭제하고 있던 문제 수정

* refactor: IssueService를 이슈를 담당하는 서비스와 이슈의 부가적인 정보(라벨, 담당자, 코멘트)를 담당하는 서비스로 분리

* feat: 이슈 생성 시 유저 ID 확인하는 로직 추가

* refactor: jwt에 존재하는 claim 타입 캐스팅

* feat: accessToken reissue api 구현

* refactor: 리팩토링 

filter에서 필요한 memberId 리팩토링
controller url 수정

---------

Co-authored-by: jinny-l <jinny.l.dev@gmail.com>
Comment on lines +27 to -23
// TODO: 도메인 설계 개선 필요(상위 개념을 만들어서 중구난방으로 서비스와 레포지토리를 가져오지 않게)
// TODO: 코멘트 관련 내용도 어떤 것은 IssueInfo 어떤 것은 Issue에서 처리하고 있음
private final IssueInfoService issueInfoService;
private final CommentService commentService;
private final MilestoneService milestoneService;

private final OrganizationRepository organizationRepository;
private final IssueRepository issueRepository;
private final CommentRepository commentRepository;
Copy link
Author

@jinny-l jinny-l Aug 11, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

전주에 새리 조언을 듣고 기존의 IssueService를 최상단 Service인 IssueService와 이슈의 라벨, 담당자 등을 담당하는 하위 Service인 IssueInfoService 2개로 나누어보았습니다. 🙂

다만 이슈에 종속적인 마일스톤, 라벨, 담당자 관련 내용은 issue 도메인 내에 존재하는데 각 도메인으로 위치하게 해야하는지 책임의 소재가 누구한테 있는지?는 고민이 되었습니다.

더불어 Service 계층이 2개가 되면서 a() 메서드가 b()를 호출하는데 둘다 @transactional 어노테이션이 붙어있는 경우가 있습니다. 트랜잭션이 합류되는 것은 알지만 이외에 사이드이펙트나 트랜잭션 테스트 방법에 대한 지식이 없어 이부분은 공부를 더 해봐야 할 것 같습니다.

그리고 이것저것 찾아보니 파사드 패턴이라는 것이 있던데 해당 패턴을 공부해보려고 합니다!

Comment on lines +48 to +50
if (httpServletRequest.getMethod().equals(OPTIONS)) {
return;
}
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OPTIONS 메서드를 통과하는 코드가 없으면 preflight에서 401에러가 발생하고, 본요청에서는 CORS 에러가 발생합니다..
어찌저찌 코드로 해결하긴 했는데
preflight에서 401이 발생한다는 것은 CORS를 통과했다고 생각했고 실제 디버깅에서도 확인했는데
본요청에서 CORS 에러가 발생하는 이유를 파악을 못했습니다 🥲

Copy link

@sallyjellyy sallyjellyy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

한 주간 고생 많으셨습니다.

  • 제 코멘트
    • 배포 주소 들어가봤는데 회원가입 눌러도 아무 일이 일어나지 않네요. 확인 필요할 것 같습니다.
    • 코멘트의 파일은 String으로 받던데 URL을 받는건가요? 파일 업로드하는 API도 필요해보이는데 어떻게 구현되는건지 궁금합니다.
    • 레파지토리에 전반적으로 무엇으로 조회/수정/삭제하는지에 대한게 메서드명에 명시되어있지 않더라구요. Long타입의 아이디로 findBy가 있는 상황에서 같은 타입의 다른 필드로 조회해야하는 경우가 생길 수 있으므로 메서드 명 자세히 지어주면 좋겠습니다. 명시적으로 네이밍하는 습관이 들어야 좋다고 생각해서(이 부분은 특히나 현업에서 많이 느낍니다.) 메서드명, 변수명에 대한 리뷰를 자주 드리게 되네요.
  • 질문에 대한 답변
    • DB에서 update 및 delete을 할 때 리턴타입이 고민됩니다.
      • 제대로 업데이트 되었는지를 확인하기 위해서는 말씀하신대로 다시 조회하시면 됩니다.
    • 여러개의 테이블의 정보가 필요한 경우 VO를 만들었습니다.
      • 먼저 VO와 DTO가 뭔지, 개념과 역할 그리고 둘의 차이점에 대해 알아보시면 좋겠습니다.
      • 말씀하신 요구사항에 변경이 생기면 모든 계층에 변경사항이 생긴다고 하셨는데 필요한 데이터가 바뀌어서 쿼리부터 변경해야하는 상황이라면 그걸 매핑하는 객체의 필드만 바뀔거라고 생각합니다. 굳이 모든 계층을 변경할 필요는 없지 않을까요?
      • https://martinfowler.com/eaaCatalog/dataTransferObject.html
      • https://martinfowler.com/bliki/ValueObject.html
    • DB에서 1개의 Row를 찾을때 query()를 사용하는 것이 EmptyResultDataAccessException 오류 방지차원에서 적절한 방법인가?
      • 하나의 결과값을 찾는데 query를 쓰면 원하는 하나의 결과값을 찾은 후에도 더 없는지 db를 계속 찾기 때문에 비효율적입니다. 에러를 뱉는다고 QueryForObject를 사용하지 않을 이유는 없어 보입니다. Try-catch 등을 이용해 에러를 핸들하고 없는 값을 어떻게 넘겨줄지 규칙을 정하면 될 것 같습니다.
    • 응답 코드의 사용을 구체적으로 나누는지 궁금합니다.
      • 이 부분은 회사마다, 팀마다 달라서 어떻다 정확히 말씀드리기는 어렵습니다만 제 경험에 미루어봤을때 모든 상황에 응답코드를 strict하게 지키는 경우는 많이 보지는 못했습니다.
  • 코멘트
    • 지니 - 생각보다 기능 구현이 오래 걸리고 있습니다. 기능 구현이 우선이라고 생각되어 예외 처리 및 테스트 코드는 후순위로 밀고 기능 구현에 집중하고 있는 상황인데 하나의 기능을 구현하더라도 제대로 구현을 해야하는 것인지... 지금의 학습 방향이 올바른 학습 방향인지 고민이 됩니다. 관련해서 새리의 조언을 듣고 싶습니다! 태풍 피해 조심하시구 안전한 주말 보내세요
      • 마음 급하게 먹지 마시고 천천히 하세요! 모든 기능을 구현할 필요도 없다고 생각합니다. 테스트를 후순위로 두는것도 방법이라 생각합니다. 나중에 테스트를 중점적으로 공부해보셔도 되니까요. 화이팅입니다!
    • 찰리 - 아직 Member 쪽에서 Oauth 로그인, 일반 로그인, 일반 회원가입 하는 코드에 대해서 기능 구현만 한 상태입니다. 빠른 시일내에 예외처리 및 코드 리팩토링을 진행하겠습니다. 이번주도 감사합니다! 새리
      • 로그인 구현하시느라 고생하셨어요! 조급하시겠지만 지치지 않을 정도로 페이스 잡아가면서 해주세요. 화이팅입니다!

마지막 한 주 남았네요. 끝까지 힘내세요!


void save(Long commentId, Long memberId, Emoticon emoticon);

List<CommentEmoticonVo> findAllBy(Long commentId);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Id로 찾는다는걸 명시적으로 메서드명에 표현해주면 좋을 것 같아요. 다른 파일에 있는 메서드들도 마찬가지 입니다.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

파라미터까지가 시그니처라고 생각해서 commentId까지 읽으면 나름 명시되어 있다고 생각했는데 최대한 구체적으로 적는게 좋을까요?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jinny-l 아 이게 지금은 코멘트에 Long 타입의 필드가 commentId 밖에 없는 거 같아 상관이 없지만 만약에 다른 Long 타입이 있고 그 필드로도 조회를 해야한다면 파라미터 타입이 같아서 결국 메서드명으로 구분을 해줘야 해서 메서드명에 명시적으로 표시해주는게 낫다고 생각했습니다. 만약 인자의 이름을 정할 수 있는(named argument를 지원하는, kotlin, swift 같은) 언어라면 상관없지만 자바는 해당 기능을 지원하지 않기 때문에 자세히 명시해주는게 좋다고 생각합니다. :)

private Boolean isIssueAuthor;
private LocalDateTime createdTime;
private List<CommentEmoticonResponse> emoticons;
private String files; // TODO: 파일 첨부는 일단 1개만 가능하고, 이후 List로 변경 예정

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

일단 1개만 가능하다면 필드명도 단수형으로 바꾸는걸 추천드립니다.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

넵 FE와 상의한 결과 comment의 본문 내용에 마크업 스타일로 S3에 저장된 데이터의 URL 을 포함하면 된다고 생각해서 해당 files는 삭제하도록 하겠습니다!

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

한 컨트롤러 전반에 공통적인 url이 있으면 RequestMapping을 사용하는걸 추천드려요.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

RequestMapping 를 통해 Controller의 공통 url을 묶으면 postman 이나 기타등등 url을 테스트할때 RequestMapping에 있는 url을 빼먹는 경우가 있어 모든 api에 공통 url 부분이 있더라도 따로 RequestMapping을 사용하진 않았습니다.

public class MilestoneFilter {

private long id;
private Long id;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

Comment on lines +32 to +35
.milestoneId(milestonesId)
.memberId(memberId)
.title(title)
.isClosed(isClosed)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

멤버변수를 사용할 때에는 함수 매개변수랑 헷갈릴 수 있어서 this를 명시적으로 사용하는걸 추천드립니다.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

여기 업데이트 다 분리하신건 각각 기능이 따로 필요해서 분리하신거 맞을까요?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

update 관련 메서드 분리한거 말씀하시는 것일까요?
질문을 정확히 이해 못했는데...
IssueService는 이슈 테이블과 관련 있는 내용, IssueInfoService는 Issue와 다대다 또는 다대일 관계로 매핑되는 라벨, 담당자 등을 관리하도록 분리했습니다.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jinny-l 여기 코드가 지금 안 보여서 정확히 뭐였는지는 기억이 안 나네요ㅠㅠ 제 생각에 이슈에 대한 타이틀과 같은 내용을 바꾸는게 메서드 하나씩 있었던 것 같은데 기획서 확인해보니 기능같아서 신경쓰지 않으셔도 됩니다!

Comment on lines +21 to +24
.title(this.title)
.description(this.description)
.backgroundColor(this.backgroundColor)
.isDark(this.isDark)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

여기는 this 사용하셨네요. 좋습니다 👍

private final String password;
private final String nickname;
private final LocalDateTime createdTime;
private final String profileImgUrl;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

필드명 자세해서 좋네요 ㅎㅎ

Comment on lines +14 to +16
.email(this.email)
.nickname(this.nickname)
.password(this.password)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍


List<MemberFilter> findFiltersBy(Long organizationId);

Optional<Long> findBy(String email);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

메서드명만 보고는 리턴되는 Long이 어떤건지 알 수가 없으니 id라고 명시해주는게 좋겠습니다.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

넵 저도 저 메서드를 사용하면서 헷갈려서 수정하도록 하겠습니다.

@sallyjellyy sallyjellyy merged commit d38ee16 into codesquad-members-2023:team-03 Aug 13, 2023
kses1010 pushed a commit that referenced this pull request Aug 13, 2023
[BE] 마일스톤 추가,수정,삭제,상태변경,상태 별 조회 API
kses1010 pushed a commit that referenced this pull request Aug 13, 2023
kses1010 pushed a commit that referenced this pull request Aug 13, 2023
kses1010 pushed a commit that referenced this pull request Aug 13, 2023
kses1010 pushed a commit that referenced this pull request Aug 13, 2023
kses1010 pushed a commit that referenced this pull request Aug 13, 2023
@CDBchan
Copy link

CDBchan commented Aug 14, 2023

배포주소에 들어가면 아무것도 안뜨는 이유가 로그인기능때문에 Filter에서 걸리는거같은데, 저희 FE 담당해주시는분이 한분이라 실제로 잘작동하는 페이지를 보려면 FE랑 좀더 맞춰봐야 할 것 같습니다. 죄송합니다 ㅜㅜ

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants