kumakuma34 / b-side Goto Github PK

Challenge 조회 API 구현

모집중인 챌린지

[기능]

• 모집중인 챌린지 리스트 표시
  • 기본 표시 개수 : 10개
• 리스트 정렬 기준
  • 챌린지 시작일 기준 내림차순
  • 시작일이 같을 경우는 참여한 인원수 적은 순
    [정책]
• 현재 참여한 인원수 = 최대 참여 가능 인원수 일 경우에는 리스트에 출력하지 않음 (모집 마감)

참여 중인 챌린지

내가 개설한 챌린지

Google OAuth 회원 가입 구현

1. OAuth

• Access Token 관리
• Access Token으로 정보 가져오기

2. OAuth 회원가입 구현

• DB에서 회원 가입 여부 확인 >saveOrUpdateBy 구현
• DB에 회원가입 처리

1. 가입이 되어있는지 확인하는 함수
2. 가입을 시키는 함수(Request body > 정보를 받아서 처리)

• Challenge Entity 설계
• Controller 작성( 챌린지 등록)
• 모집중인 챌린지 조회 Controller 작성
• ~3/7

notification이 저장되어야 하는 경우,

notificationService의 public void save(NotificationSaveDto saveDto) 호출 필요

NotificationSaveDto 필수 값은 해당 class 내의 bulider 참조
(필수 값 누락시, 컴파일 에러를 발생)

1. Front-Back OAuth API 연동

• API 로직 구현

2. 로그인 관리

• Access Token, Refresh Token을 어떻게 관리할 것인지 (논의)
• JWT로 관리할 것인지 (논의)
• 차주 회의때 논의

프론트 수정 요청 건

우선순위 높은 것들만 처리 할 예정 (세부 validation등 기타 스펙 다 out)

챌린지

• 챌린지 일배치로 상태 변경
• 특정 챌린지 조회 시 조회한 멤버가 챌린지에 속했는지 안속했는지 여부
• 특정 챌린지 조회 시 해당 멤버가 그 챌린지에 글 제출 가능 상태인지 여부
• 챌린지 개설자는 자동 참여

글

• 글 공개 / 비공개 toggle API구현 필요
• 글 제출 시 뱃지 획득될 수 있도록 연계작업
• 글 제출 랭킹 조회 시 유저 프로필 썸네일 url 추가 제공
• 글 조회 시 조회하는 멤버가 그 글을 좋아요 했는지 여부 추가 데이터 제공
• 챌린지 조회 시 해당 챌린지 참여 중인 모든 멤버들의 글 조회 기능(주차별로 조회조건 있음)

• EC2 서버 구축
• 서버에 Spring Boot 프로젝트 배포
• 배포 자동화 구축

• 현재 600000초로 되어있는데 , 굉장히 짧은 시간 후에 바로 token이 expire됨 > 이 이슈 해결 필요

lombok builder를 활용해서
현재 challengeService.java에 있는 challenge Titile, detail validation check 밖으로 빼오기
`public Challenge addNewChallenge(ChallengeDto.AllInfo challengeDto) {
int title_len = ChallengeCode.CHALLENGE_TITLE_LENGTH.getVal();
int detail_len = ChallengeCode.CHALLENGE_DETAIL_LENGTH.getVal();

    if(challengeDto.getChallengeTitle() == null || challengeDto.getChallengeTitle().equals("")){
        throw new IllegalArgumentException("challenge title must not be null");
    }
    if(challengeDto.getChallengeTitle().length() > title_len){
        throw new IllegalArgumentException("challenge title length must be under 39");
    }

    if(challengeDto.getChallengeDetail() == null || challengeDto.getChallengeDetail().equals("")){
        throw new IllegalArgumentException("challenge detail must not be null");
    }
    if(challengeDto.getChallengeDetail().length() > detail_len){
        throw new IllegalArgumentException("challenge detail length must be under 100");
    }

    Challenge challenge = challengeDto.toEntity();
    return challengeRepository.save(challenge);
}`

//    public List<Long> getArticleIdList() {
//        return ArticleIdList;
//    }
//
//    public void setArticleIdList(List<Long> articleIdList) {
//        ArticleIdList = articleIdList;
//    }``

여기서 List 아티클 리스트 꼭 필요..?
Service에서 차라리 조회 탈 때 Article 디비에서 쭉 긁어와서 메모리에서 가지고있는게 나을것같은데
이렇게 되면 Article 등록할때마다 Member Table도 변경 같이해줘야될것같습니다..

응답 실패시, error code 및 desc 추가 필요

• error code enum 추가 필요
• error 분류 합의 필요

Member DB 설계/ 연동

badge 획득 logic

• challenge, like, article 벳지 code별로 event 발생 시 badge 획득 조건 충족 여부를 check하는 logic 구현 필요
• 관련 data 저장 필요 (like 횟수, 완주한 challenge 갯수....etc)

ex) like를 받은 경우,
BadgeService의 public BadgeDto checkAndGetBadge(BadgeSaveDto saveDto) method 호출해서 사용할 것

• badgeSaveDto 안에는 memberId, badgeValue, badgeCode값이 입력되어있어야함.

text/plain -> application/json 으로 response content-type 변경

유저 알람 사항 구현

• 알람 생성 함수 합의 필요
• 알람 생성 시기 합의 필요
• 알람 저장방식 합의 필요

• Auditing 적용
• Lombok getter setter 적용
• Member Controller