[김건우] week3 - 요구사항 개발 완료 / 1차 QA / 서버 사이드 렌더링 고민

[coli-geonwoo]

완료한 태스크

• 메인 페이지 기준 offset 페이지네이션으로 게시글 조회기능
• 댓글 작성기능
• 좋아요 기능
• 댓글 작성 시 보던 페이지로 이동하는 기능
• 1차 QA

고민한 부분

좋아요를 어디에 어떻게 저장해야 하는가?

1. Article이 likes 를 가진다 : 아직 인덱스 설계를 하기 전이라 PK 기준으로 Article이 update되므로 많은 update 동시요청 시 락경합이 발생해 요청이 지연될 수 있으므로 반려
2. ArticleLikes를 분리하되 H2에 저장한다 : update 로직 설계에 있어 H2 를 사용하고 있으므로 MySQL 차원의 MVCC를 지원하지 않아 Update Loss 가능성 존재
3. ArticleLikes를 분리하되 InMemory에 Map<ArticleId, LikeCount>를 저장하고 AtomicLong으로 동시성 관리 : 메모리 DB라 서버 재시작시 날아감(H2도 마찬가지), but, 비동기적으로 동시성 이슈를 자바 언어 단위에서 처리 가능하며 접근속도가 빠름 -> 채택

articleId PK Generation Strategy에 귀속되지 않는 고민

현재는 Article 생성시 반환되는 (articleId)를 기반으로 GET /article/id?artilceId=artilceId로 최신 기준 offset을 알아낸 후, GET /main?offset={offset} 을 호출하여 댓글 작성 과정에서 다른 게시글이 추가되어 offset이 변화하더라도 원래 보던 article로 정확하게 리다이렉션해줌.

그러나, offset 호출 > 리다이렉션 사이에 다른 사용자가 새로운 게시글이 추가되면 offset이 밀려 같은 article을 보지못하는 케이스 발생 가능성이 있음

해당 경우를 대비하기 위해 Article Auto Increment의 속성을 활용하여 Id 값 기반 리다이렉션을 고려해볼 수 있으나, 이러한 API 설계는 엔티티 설계 구조를 API가 종속시켜버리는 느낌이라 망설여짐. 또한 delete 기능이 들어오면 이전, 다음 글 호출 시 id-1, id+1에 해당하는 삭제된 article을 조회할 가능성이 있음

서버 사이드 렌더링 고민

미션 수행 과정에서 일정에 쫓겨 서버 사이드 렌더링이 아닌 클라이언트 사이드 렌더링을 선택함. 즉 서버에서는 json만 반환하고 프론트 코드에서 해당 응답값을 받아 동적 렌더링을 진행함. 그러나, 엄밀한 의미에서 WebServer 구현 미션을 생각해본다면 동적 렌더링 요소까지 서버가 책임지는 것이 바람직하며 미션 의도에 부합하다고 판단함. ThymeLeaf 기능을 얼마나 서버 쪽으로 이전시킬 것인지에 대한 고민이 필요