kshshkim / yetanotherwikiengine Goto Github PK

파일: 어쩌고.png 형식의 제목을 파싱하여 Namespace.FILE, 어쩌고.png 형태로 분리하는 파서.

• 네임스페이스 구분자(ex. 파일)는 프로퍼티로 따로 지정해줄 수 있어야함.
• 네임스페이스 구분자는 국제화를 지원해야함. (ex. File: 어쩌고.png로 변환해도 동일한 결과를 내야함.)

소유자 그룹 - 그룹 역할 기반 체계에서, 단순 역할 기반 체계로 개편.

• 배경

  • 기존 구조
    • AuthorityProfile(행위자 권한 프로필)이 (권한 그룹, 권한 그룹 역할) 쌍으로 이루어진 GrantedGroupAuthority를 여럿 가짐.
    • ResourcePermission은 자원 id와 소유자 그룹, 개별 권한 규칙을 가짐.
      • 개별 권한 규칙 -> 소유자 그룹 기본 권한 규칙 -> 기본 권한 규칙 순서로 Permission 정보를 확인해야함.
    • 행위자의 GrantedGroupAuthority를 모두 확인하여, 하나라도 만족되는 권한이 있으면 pass
  • 문제점
    • 문서 소유자 그룹(권한 그룹)의 필요성이 떨어짐.
      • Notion을 사용하면서 그룹별 권한 체계가 있으면 좋겠다고 막연히 생각하여 구상한 구조인데, 일반적인 위키 엔진이라는 본래 목표와 주객이 전도될 정도로 고려할 점이 많아짐.
    • 캐싱이 어려워짐.
    • 네임스페이스별 기본 권한 설정 등, 새로운 기능을 추가할때 고려해야할 점이 많아짐.
      • 네임스페이스별 기본 권한 체계가 소유자 그룹 체계를 일부분 대체 가능할 것 같음.

• 변경방식

  • 소유자그룹을 없애고, 단순 사용자 역할 기반 체계로 개편
  • GrantedGroupAuthority 대신 GrantedAuthority
  • 개별 권한 규칙 -> 기본 권한 규칙 순서로 단순화됨.
    • 기본 권한 규칙을 네임스페이스 권한 규칙으로 쉽게 치환할 수 있음.

• 기대 효과

  • 단순 Role 기반으로, SpringSecurity와 보다 잘 통합될 수 있음.
  • 사용자의 권한 정보를 캐싱하기 간편함. (가장 높은 권한 정보만, 유효성을 고려하여 캐싱하면 됨.)
  • 네임스페이스별 기본 권한을 구현할 때, 그룹에 대한 요소를 고려하지 않아도 됨.

문서, 틀, 분류, 파일 등 네임스페이스.

현재 구현 방식

• 내부적으로, WikiPage에 대한 쿼리와 WikiReference에 대한 쿼리를 한 번 씩, 총 두 번의 쿼리를 통해 취합하여 반환함.
  • wiki_reference테이블을 주 테이블으로, wiki_reference.title과 wiki_page.title을 join
  • 유효하다고 판단된 wiki_page.title 목록을 반환함. (wiki_page가 null이거나 is_active가 false면 유효하지 않음.)
• 문제점
  • 최신 버전 문서 기준으로만 레퍼런스 유효성을 조회할 수 있음. (RDB의 구조적, 성능적 문제로, 모든 리비전에 대한 참조 정보를 저장하기는 어려워보임)
  • 연관관계 설정 측면에서 바람직하지 않아보임.
    • WikiPage 쿼리가 WikiReference의 구현 내용에 강하게 의존함. (현재 참조 정보를 WikiReference에서 불러와야함.)
• 대안과 tradeoff
  • FE에서 레퍼런스 유효성 조회를 비동기 요청으로 처리하도록 해야함.
  • WikiReference 정보를 사용하지 않고, FE 단에서 내부 링크의 제목을 파싱하여 list 형태로 쿼리해야함.
    • 내부적으로는 select wiki_page.title from wiki_page where wiki_page.title in (?, ?, ?, ...) and wiki_page.is_active=true 같은 쿼리를 생각해볼수 있음.
    • in 절의 조건에 수천개가 들어가는 경우 성능상의 문제가 있을 것 같음.
      • 참조가 많은 특수한 문서는 요청을 나누어(ex. 한 번에 최대 n개까지 요청) 보내게 하거나, 요청 결과를 따로 캐싱하는 방법을 생각해볼 수 있을 것 같음.(이 경우 캐시 정합성을 맞추는데 추가 작업이 필요함.)

• 서버 성능에 영향을 줄 수 있는 대량의 업데이트가 일어나야하는 경우, 비동기로 처리해야함. (ex. 한 번에 수천개의 참조정보가 변동되는 commit)
• 비동기 메시지 큐를 사용하여 처리 가능할 것으로 보임. 이를 추상화할것.

문서 '생성'의 의미를 보다 명확히 구분할 필요가 있음.

• 현재 WikiPageCreatedEvent 이벤트는 insert 쿼리가 수행되는 상황, 즉, WikiPage 엔티티가 DB에 영속화 되는 상황에 발행됨. 그러나, 위키 문서의 특성상 Created된 문서일지라도 active한 문서가 아닐 수 있음.(생성 이후, EditCommit이 이루어진 상황에서야 active한 문서가 됨.)
• WikiPageCreatedEvent를 권한 엔티티 생성 트리거로 활용되었기 때문에 문제가 없었으나, 문서 제목 존재 판정 기능에 함께 사용하기 시작하면서 의미 혼동이 발생함.
• WikiPageActivatedEvent를 새로 정의하고, 관련 기능에서 WikiPageCreatedEvent 대신 구독하도록 수정해야함.