우연히 백준사이트의 깃헙 레포지터리에 접근하게 되었는데 디스커션 메뉴가 있더라구요. https://github.com/tony9402/baekjoon/discussions/198

새로운 기능의 발견

github.com 을 너무나도 오랜만에 사용하느라 새로운 기능이 생긴 것도 몰랐습니다. 주로 gitlab을 사용하고 있었거든요.

코딩된 로직에 대해서 이슈가 발생할 때는 이슈기능에, 질문하거나 답변, 또는 개선아이디어라는 카테고리가 이슈에서 논의되는 것에는 역시 거부감이 있었는데, Discussion이라는 메뉴가 생겨 있었습니다.

• 얼마나 전부터 제공한 것인지, 저한테만 새로운 것인 지도 모르겠습니다.
• stackoverflow.com 의 기능도 흡수할 수 있을 것 같습니다. 좋은 아이디어입니다.

좋은 아이디어라고 생각하는 이유

질문해야 할 내용에 대해서 정리하는 툴로 이것이 좋겠다고 생각했습니다.

• 슬랙으로 질문 답변을 유도하는 것보다 훨씬 더 좋은 방법이라고 생각합니다.
• 슬랙과 같은 메신저, 메일과 같은 다른 커뮤니케이션 수단의 사용을 유도하지 않습니다.
• 레포지토리에 가깝게 저장할 수 있습니다.

활용

이것도 gitlab에서 도입되면 좋겠다고 생각듭니다.

• 아직은 gitlab에는 비슷한 것이 없습니다. (대신에 Wiki를 무료플랜에서 사용할 수 있죠.)
• 또 대부분의 커뮤니티에도 도입이 필요한 기능이 아닌가? 하는 생각이 들었습니다.
  • 회원가입처럼 필수.
  • 개인 포트폴리오 사이트에서도 필수.

Entity 모델링

드래프트 형식으로 추측해본 RDBMS 모델링을 적어보았습니다.

• Persistant의 모델링이고, 페이지를 구성하는 정보가 많아서 캐쉬를 두어야 할 것 같습니다.
• 스케일에 맞추어 아이디의 타입은 long이나 uuid로.

Discussion_Category

ID int
Icon string ( or character)
Format int (open ended discustion, question and answer, announcement)
Title string
Description 

Discussion

ID int
Icon string
Title string
CreatedBy int
CreatedBy datetime
Label int
(no contents but events and items)

Discustion_Event

ID int
DiscussionID int
CreatedBy int
CreatedBy datetime
EventMassage string

Discustion_Item

ID int
DiscussionID int
ParentDiscussionID int (Tree AST)
CreatedBy int
CreatedBy datetime
Content text

Discustion_Item_Reaction

ID int
DiscussionItemID int
CreatedBy int
CreatedBy datetime
Emoticon char

Discussion Service 모델링

디스커션쪽 시스템이 죽더라도 기존의 레포지토리 시스템에 영향이 없도록 분리된 서비스의 형태면 좋겠다는 생각이 들었습니다.
나눈다면 입력과 출력 두 부분.

• 입력
  • 직접 컨트롤러가 저장할 지, API를 부를 지
  • 이벤트로 렌더링을 비동기로 할지, 직접할 지를 선택할 수 있을 것 같습니다.
• 출력
  • 뷰의 데이터를 어딘가의 store에서 가져올 지, API에서 가져올 지.
  • 한 번에 전체의 View를 렌더링 할 지, React니까 각각의 component를 비동기로 불러와서 react에게 렌더링을 맞길 지.
  • 음. 처음에는 이미 렌더링된 Store에서 받아오는 좋겠다고 생각했습니다. 예전에 블로그 시스템은 이런 식이 많았는데…
  • 하지만 열어놓은 페이지가 어떤 이벤트를 감지해서 자동으로 갱신되곤 하잖아요? 이벤트가 발생된 데이터만 React가 받아서 실시간으로 렌더링하는 것이 트렌드에 맞는 것 같습니다.

웹 어플리케이션쪽 Adherent Service 모델링 부분

• 렌더링데이터는 websocket이나 firebase?를 통해서? 아니면 graphql이나 rest api 호출?
• 아니면 전통적으로 레포지터리패턴으로 직접 로직을 실장?

Discussion API Service 모델링

Repository의 역할, Rest Service? 또는 k8s를 흉내내서 WebSocket? 함수이름까지 써보면(파라메터는 생략합니다)

• CreateDiscussion

• UpdateDiscussion

• DeleteDiscussion

• GetDiscussion

• AddDiscussionItem

• UpdateDiscussionItem

• DeleteDiscussionItem

• AddDiscussionItemReaction

• DeleteDiscussionItemReaction

UI를 서포트하는 비동기 Service 모델링

• RenderDiscussion
  • persistant로 부터 필요한 데이터를 모아서 모델링하는 기능이 필요하지 않을까요
  • 어떤 렌더링용 모델이 리턴 타입으로 필요하겠네요.
• PublishDiscussion
  • 디스커션 이벤트가 발생하면 이 기능이 캐쉬를 업데이트 해야 할 것 같습니다.
    • 캐쉬는 데이터사이즈가 작지 않으므로 레디스보다는 몽고DB?

구상에 따라 여러 variation이 나오네요. 상상은 여기까지 해야할 것 같습니다.