Preview

 

마지막 개인프로젝트이자

그동안 해온 것들을 총정리하는 복습 프로젝트가 나왔다.

프로젝트 안내사항에는 매일 수행하는 과제 일정표가 주어졌지만 

P답게 1주일을 강의 듣는다고 하지 않아서 

이제는 5일의 전사 느낌으로 해보려 한다.

 

예상 진도

복습 프로젝트 월, 화, 수

리팩토링 프로젝트  수, 목, 금

완성 후 제출

 

이전 팀프로젝트에서 사전에 API명세를 구체적으로 설계해두면

프로젝트 진행이 훨씬 수월하다는것을 배웠기에

요구사항을 분석한 것을 간단하게 작성하고 이를 참고하여 프로젝트를 진행할 생각이다.

 

 

1일차  회원가입

 

• 닉네임, 비밀번호, 비밀번호 확인을 request에서 전달받기
  
  
• 닉네임은 최소 3자 이상, 알파벳 대소문자(a~z, A~Z), 숫자(0~9)로 구성하기
  -> 정규식 + validation 적용
  
  
• 비밀번호는 최소 4자 이상이며, 닉네임과 같은 값이 포함된 경우 회원가입에 실패로 만들기
  -> 정규식 
  
  
• 비밀번호 확인은 비밀번호와 정확하게 일치하기
  -> if문 검증
  
  
• 데이터베이스에 존재하는 닉네임을 입력한 채 회원가입 버튼을 누른 경우 "중복된 닉네임입니다." 라는 에러메세지를 response에 포함하기
  -> 기존에 findById 로직 사용하던것과 동일함 
  
  
• 회원 가입 버튼을 누르기 전, 같은 닉네임이 존재하는지 "확인" 버튼을 눌러 먼저 유효성 검증부터 할 수 있도록 해보기
  -> 컨트롤러에서 메소드 하나 더 만들면 된다.
  
  
• (챌린지 과제) 데이터베이스에 비밀번호를 평문으로 저장하는 것이 아닌, 단방향 암호화 알고리즘을 이용하여 암호화 해서 저장하도록 하기
  -> BCryptPasswordEncoder 사용
  
  
• (챌린지 과제) 회원 가입 시, 이메일 혹은 SNS로 인증 번호를 전달 받고 5분 이내에 해당 인증 번호를 검증해야 회원 가입에 성공하도록 해보기 (redis TTL 특징을 좀 더 파악하기 위함.)
  -> 굳이 redis를 쓰지않아도 이메일 인증코드 유효기간을 5분으로 설정해주면 되는데 이 부분은 좀 더 알아봐야 것 같다.  
  redis TTL을 써야하는 이유
    1. 사용하지 않을 경우  만료 시간 5분 이후 인증코드를 제거하기 위한 스케줄링 로직을 구현해야함.
    2. 인증코드를 DB에서 삭제하기 위해 계속 DB를 호출해야하므로 부하가 증가함.
  -> 이러한 이유로 redis TTL을 사용하여 5분후에 자동으로 삭제되도록 하면 위의 두 문제점을 해결할 수 있음.

 

 

2일차  로그인

• 닉네임, 비밀번호를 request에서 전달받기
  
  
• 로그인 버튼을 누른 경우 닉네임과 비밀번호가 데이터베이스에 등록됐는지 확인한 뒤, 하나라도 맞지 않는 정보가 있다면 "닉네임 또는 패스워드를 확인해주세요."라는 에러 메세지를 response에 포함하기
  -> JPA 사용하기
  
  
• 로그인 성공 시, 로그인에 성공한 유저의 정보를 JWT를 활용하여 클라이언트에게 Cookie로 전달하기
  -> JWT 활용해서 AuthController에서 적용 
  
  

 

3일차  전체 게시글 조회 

• 제목, 작성자명(nickname), 작성 날짜를 조회하기
  
  
• 작성 날짜 기준으로 내림차순 정렬하기
  -> JPA  ,  auditing 설정하고 desc
  
  
• (챌린지 과제) 전체 조회가 아닌 페이징 조회를 할 수 있도록 해보기
  -> pageable 설정
  
  
• (챌린지 과제) 페이징 + 커스텀 정렬 기능 구현하기 -> 사용자가 입력한 key와 정렬 기준을 동적으로 입력 받아, 해당 기준에 맞게 데이터를 제공. (예. 작성자명 오름차순 정렬 and 작성 날짜 오름차순 정렬된 결과를 상위 5개만 출력)
  -> JPA,  Pageable 구현해서 key, 정렬기준, 몇개 출력할지 정하는 메소드 만들어서 사용

 

4일차  게시글 작성

• 토큰을 검사하여, 유효한 토큰일 경우에만 게시글 작성 가능
  
  
• 제목(500자 까지 입력 가능), 작성 내용을 입력하기(5000자 까지 입력 가능)
  -> 엔티티에서 @Column의 length,   리퀘스트 필드에서 @size  둘 다 적용하면 된다.
   - 리퀘스트 단계에서 검증은 요청 처리되기 전에 빠르게 유효성 검사 가능
   - 엔티티는 DB에 처리되기 전에 검사 가능
  
  
• (챌린지 과제) 이미지 업로드 가능
  -> S3에 저장해야할지 그냥 로컬에 저장해도 될지 모르겠음.
  일단 S3에 저장하는것이라 생각하고 구현할 생각.

 

5일차, 6일차  게시글 조회, 수정

• 제목, 작성자명(nickname), 작성 날짜, 작성 내용을 조회하기 (검색 기능이 아닙니다. 간단한 게시글 조회만 구현해주세요.)
  
  
• 토큰을 검사하여, 해당 사용자가 작성한 게시글만 수정 가능
  -> 기존에 작성하던 로직 그대로 적용

 

7일차  게시글 삭제

• 토큰을 검사하여, 해당 사용자가 작성한 게시글만 삭제 가능
  
  
• (챌린지 과제) 수정된지 90일이 지난 데이터는 자동으로 지우는 스케줄러 기능을 개발해보기. (데이터 삭제 및 백업도 굉장히 중요한 기능인데, 수강생들이 이런 내용을 잘 인지하지 못 함.)
  
  • 스케줄러에 대한 가이드라인은 별도로 제공하지 말 것. (Spring Scheduler를 쓰던, 크론잡을 쓰던 선택지를 다양하게 줄 것.)
    
    
  • 90일이라고 하는 스펙은 수강생들이 알아서 정하게 내두기. (다만, 그 이유를 적도록 하기)
    
    • UTC의 스케줄러가 동작하는 현재 일시 (2023-12-11T02:11:23) 기준으로 90일이 지난 데이터를 지운다.
      
      
    • UTC의 스케줄러가 동작하는 현재 날짜 (2023-12-10) 기준으로 90일이 지난 데이터를 지운다.
      
      
    • LocalTime(+09:00)의 스케줄러가 동작하는 현재 일시 (2023-12-11T11:11:23) 기준으로 90일이 지난 데이터를 지운다.
      
      
    • LocalTime(+09:00)의 스케줄러가 동작하는 현재 일시 (2023-12-11) 기준으로 90일이 지난 데이터를 지운다.
      
      

           -> 타임존 설정하기
               어디에 해야하지? 스케줄러 클래스에 직접하기

               

           Q1.  왜 90일로 해야할까?  

                  개인적으로 30일로 설정하고 싶다.

                  그 이유로는 

                  첫번째로 짧은 주기마다 데이터를 정리하여 데이터 저장공간을 효율적으로 사용하기 위해.

                  두번째로 일반적으로 30일 가까이 지나면 본인이 쓴 게시글을 크게 신경쓰지 않기때문에
                      (게시글을 신경써서 수정하는 것을 기준으로하면 스케줄링을 일주일만 줘도 충분하다고 생각) 

                  세번째  그냥 주어져있으니까 뭔가 바꾸고 싶음 (가장 큰 이유)

           Q2.  스프링 스케줄러를 쓰긴 할건데,  크론잡은 뭘까  

23/12/18 스프링 스케줄러와 크론잡

 

 

 

8일차  댓글 작성

• 게시글과 연관 관계를 가진 댓글 테이블 추가
  
  
• 토큰을 검사하여, 유효한 토큰일 경우에만 게시글 작성 가능
  
  
• 작성 내용을 입력하기
  
  
• 게시글에 대한 좋아요
  
  -> 쉽다

 

9일차  게시글과 댓글 목록 조회, 수정, 삭제

• 댓글 목록 조회
  
  • (챌린지 과제) 전체 조회가 아닌 페이징 조회를 할 수 있도록 해보기
    -> 3일차에서 페이징 처리를 잘해두었다면 쉽게 할 수 있다고 생각한다.
    
    
  • (챌린지 과제) 페이징 + 커스텀 정렬 기능 구현하기 -> 사용자가 입력한 key와 정렬 기준을 동적으로 입력 받아, 해당 기준에 맞게 데이터를 제공. (예. 작성자명 오름차순 정렬 and 작성 날짜 오름차순 정렬된 결과를 상위 5개만 출력)
    -> 이 또한 3일차에서 코드를 잘 짜두었다면 약간의 변경만으로 충분히 완성할 수 있다.
    
    
• 게시글 조회 API 호출시 해당 게시글의 댓글 목록도 응답
  -> 게시글 엔티티에서 코멘트 엔티티를 OneToMany로 연관관계를 설정해두고  JPA로 가져올수 있게하면됨.
   그런데 딱히 어떻게 해야할지 가장 생각이 안나는 부분.
  
  
• 토큰을 검사하여, 해당 사용자가 작성한 댓글만 수정/삭제 가능
  
  • (챌린지 과제) 게시글이 삭제될 때 연관된 댓글도 같이 지우도록 스케줄러 코드 기능 추가
    -> cascade가 있는데 왜 이걸 써야할까.  
      일단 삭제리스트를 만들어서 삭제할 게시글을 먼저 리스트에 보관해 두고 스케줄러를 통해   
      삭제하는 방식으로 구현할 생각.

 

 

이것들을 다 구현하면 바로 코드 리팩토링 과제를 진행해야겠다.