현재 내가 참여 중인 프로젝트는 사용자간의 상호작용이
글 작성과 해당 글에 신청을 함으로써 이루어진다.
해당 글에는 각각 마감 기간이 존재하며, 해당 마감기간이 지나면
더 이상 신청을 하지 못하도록 막도록 설계했다.
하지만 이 부분이 문제였다.
과연 어떻게 마감 처리를 할 것이며, 어느 시점에 해야하는가?
또한 마감된 글은 어떻게 처리를 하는 것이 좋을까?
마감 처리 시점
가장 먼저 생각난 것은, 단순 반복문으로 체크를 하는 것이었다.
DB의 모든 글을 순회해 마감된 글을 Update 해주는 로직을 생각했다.
대충 의사코드를 짜보면 아래와 같을 것이다.
groupBuyingRepository.findAll()
.stream()
.filter(g -> g.deadline.isBefore(현재 시간))
.map(g -> g.updateMethod);그럼 해당 코드를 어느 시점에 실행을 시켜야 할까?
내 생각은 어차피 글 전체목록을 불러오는 일이니,
글 전체 목록 조회 요청이 들어올 때마다 검사를 하는 건 어떨까?
그렇다면 여러 명의 유저가 사용하는 상황을 가정하더라도,
한 명만 목록을 조회하면 마감처리가 되니 괜찮은 것 같다.
하지만 문제는 성능의 문제.
과연 글이 엄청 많이 늘어나게 되었을 때는 어떨까?
많은 글을 글 전체 조회 때 마다 순회를 하며 검사한다.
과연 성능에 영향을 끼치지 않을까?
마감 처리
글이 마감이 된 뒤에는 어떻게 처리해야 할까?
- 글은 보이나, 글을 비활성화 처리한다.
- Disabled 상태를 의미하며, Front에서 처리해야 할 것이다.
- 마감이 됐음은 DB에 Boolean 값을 Update해서 알릴 수 있을 것이다.
- 글이 매우 많아지면, 성능 문제가 발생할 수 있다.
- 글을 목록에서만 안 보이게 하고, 마이페이지에는 보이게 한다.
- 이 또한 화면에 렌더링 해주는 Front에서 처리해야 할 것 같다.
- 1번과 같이 Boolean 값을 통해 알릴 수 있다.
- 내가 쓴 글이나 참여한 글에서만 보이도록 한다.
- 마찬가지로 글이 매우 많아지면, 성능 문제가 발생할 수 있다.
- 글을 아예 삭제해버린다.
- DB에서의 삭제를 의미하며, Back에서 처리한다.
- 이 경우엔, 위에서 말한 Boolean 값을 Update할 필요가 없다.
- 글이 쌓이지 않으니, 성능 면에서는 이점을 취할 수 있다.
- 기록이 사라지는 방식이라, 유지 보수나 편의성 측면에 문제 가능성이 있다.
- 배치 처리를 통해 글을 삭제한다면?
- 배치 처리를 통해 주기적으로 마감된 글을 삭제한다.
- 어느 정도는 기록이 남아있으니, 조금은 편의성을 생각한 방안이다.
- 배치 처리에 대해서 공부를 해야 한다.
위 선택 사항 중 어떤 방식을 사용할 지는 팀원들과 상의 후 정하도록 한다.
Frontend에서의 구현 가능 여부도 알아야 하기 때문에 상의는 필수.
협업에서 가장 중요한 것은 의사소통!!
실제 구현
우선은 내 생각에 가장 성능이 괜찮을 것 같은 2번 방식으로 구현했다.
DB의 contents Table에는 다음과 같은 Boolean Column이 존재한다.
게시글을 쓴 뒤 아래와 같이 마감 기간이 지나면?
위와 같이 isFinish 항목이 true로 변경됨을 확인할 수 있다.
해당 값을 DTO에 담아 Front로 넘겨주어 처리할 수 있도록 할 계획이다.