디스코URS 인스턴스에 약 20,000개의 그룹을 만들고 싶습니다. 이것이 가능한가요? 그리고 웹사이트 성능에 어떤 영향을 미칠까요?
사용자 수는 얼마나 될까요?
20,000개 그룹은 어떤 문제를 해결합니까?
다음과 같은 상황을 설명드리겠습니다. 저는 discourse를 사용하여 학술 논문 토론 플랫폼을 구축하고 있습니다. 각 논문은 논문 ID를 가진 태그로 표현되며, 해당 태그 아래 생성된 모든 토픽은 해당 논문의 태그 페이지에 표시됩니다.
문제는 다음과 같은 기능이 부족하다는 것입니다:
시스템에 업로드된 논문에 대해 저자 수동 승인 프로세스를 운영하고 있습니다. 저자들로 하여금 자신의 논문으로 태그된 게시물을 편집할 수 있도록 권한을 부여하고 싶습니다. 하지만 태그를 기반으로 권한을 부여하는 것은 불가능하다는 것을 알게 되었습니다.
그런 다음, 논문별로 그룹을 만들고 해당 논문의 저자들이 같은 그룹에 속하게 하는 아이디어를 떠올렸습니다. 하지만 특정 게시물을 편집할 수 있는 권한을 어떻게 부여할 수 있는지 확신이 서지 않아서, 이 방법이 제 문제를 해결할 수 있을지조차 알 수 없습니다.
이 기능을 구현할 수 있는 우아한 방법이 있는지 의견을 듣고 싶습니다. 감사합니다.
저자의 논문に対する 답변인 경우, 다른 사람의 게시글을 편집할 수 있도록 하자는 건가요?
게시글을 말하는 건가요, 아니면 주제를 말하는 건가요?
네, 게시물이 답변인지 해당 논문과 관련이 있는지는 현재 태그로 결정됩니다.
도움이 된다면 논문별로 그룹을 만들 수도 있습니다.
그리고 이상적으로는 게시물과 주제 모두 수정 가능해야 합니다.
그룹은 매우 가볍기 때문에 수만 개를 사용해도 문제가 없습니다.
반면, 카테고리를 2만 개까지 늘리면 성능 문제가 발생할 수 있습니다.
게시물에는 태그가 없으며, 주제(topic)에만 있습니다.
왜 다른 사람의 게시물을 수정할 수 있게 하려는지 이해할 수 없습니다. 위키로 만들 수는 있지만, 그렇게 하면 누구나 수정할 수 있게 됩니다.
아니면 사용자의 주제를 위키로 만들어 누구나 수정할 수 있게 하려는 건가요?
다른 사람의 글을 변경하는 것이 합리적인 모델이 무엇인지 이해할 수 없습니다.
여러 시나리오를 고려해 본 후, 편집 기능이 가져오는 이점 자체에 대해서도 의문을 품게 되었습니다. 다만, 답글을 남긴 사람이 해당 토픽과 관련된 논문의 저자인지 확인할 수 있는 메커니즘이 있다면 좋겠습니다. 현재 그룹 기능으로는 여전히 이것이 불가능하다고 생각합니다.
좀 더 구체적으로 설명하자면, 사용자가 id가 5인 논문을 태그하여 게시글을 작성했다고 가정해 보겠습니다. 만약 5번 논문의 저자가 해당 토픽에 답글을 남긴다면, 이상적인 기능은 답글을 남긴 사용자가 논의 중인 논문의 저자임을 어떤 방식으로든 표시하는 것입니다(플레어, 제목, 게시글 상단의 작은 기본 텍스트 등).
각 논문이 하나의 주제이고, 주제 작성자(OP)를 저자로 지정한다면, OP가 자신의 게시글에 추가로 답글을 남길 때 시각적 차이를 추가하는 CSS 규칙을 만드는 것은 자명합니다.
각 논문마다 토픽을 하나씩만 만들면 어떨까요? 그러면 혼란이 없을 겁니다. 태그나 그룹도 필요 없게 되죠.
또한, Discourse의 ‘토픽’(게시글들의 모음)과 ‘게시글’(토픽 안에 있는 한 사람의 단일 메시지)의 개념을 혼동하고 있는 것 같습니다.
하지만 이미 @falco 님이 먼저 말씀해 주셨네요…
@pfaffman @falco 기술적으로 각 논문은 태그입니다. 그 이유는 한 주제(topic)만으로는 해당 논문에 대한 모든 토론이나 질문을 담을 수 없기 때문입니다. 논의해야 할 다양한 측면이 많으며, 이 포럼의 주요 목적은 특정 논문을 둘러싼 모든 토론을 한 곳에서 모으는 것입니다. 따라서 각 논문은 태그로 처리되며, 특정 논문의 태그 아래 생성된 모든 주제는 /tag/:paper_id 페이지에서 확인할 수 있습니다.
이 시나리오에서 CSS 트릭을 적용할 수 있을까요? 필요에 따라 태그와 해당 “저자 사용자” 간의 관계를 정의하는 외부 데이터베이스를 생성할 수 있습니다.
네, 해당 데이터베이스를 파싱하여 자동으로 생성되는 CSS 파일을 가질 수 있습니다.
또한 커스텀 플러그인을 사용하여 Discourse에서 이 모든 것을 처리할 수도 있습니다. 이렇게 하면 게시물 작성자가 일치하는 게시물에 대해 토피크 직렬화기(topic serializer)에 추가 필드를 가져오며, 이는 프론트엔드 앱에서 활용할 수 있습니다.
알겠습니다. 플러그인에는 아직 초보이지만, 어떤 것들을 할 수 있는지 알아볼게요. 조언해 주셔서 정말 감사합니다!
막히면 언제든 #dev에서 주제를 열어보세요.
즉, 태그는 게시물(post)이 아니라 주제(topic)에 붙는다는 점을 이해하고 계신 것 같습니다. "topic"을 의미하면서 "post"라는 단어를 사용하고 계신 것 같습니다.
이 질문에 답하지 않으신 것 같습니다. 다른 사람들의 게시물을 편집하는 것을 원하지 않으신다면, 문제가 없을 것이라고 생각합니다. 왜 다른 사람들의 게시물을 편집할 수 있도록 하고 싶은지 상상하기 어렵지만, 그렇게 원하신다면 위키(wiki)로 만드는 것이 해결책이 될 수 있습니다.
특정 논문에 관한 주제에 해당 논문의 태그(예: DOI, 다만 이 단계에서는 아직 DOI가 없을 수도 있겠죠)를 붙이는 것은 훌륭한 아이디어이며, 이를 API를 통해 지금 바로 실행할 수 있습니다. 또한, 주제를 편집할 수 있는 사용자(신뢰 수준 3, 주제 소유자)는 태그를 추가할 수 있고, 다른 사용자는 플래그를 걸어서 태그를 달아달라고 요청할 수 있습니다(하지만 주제를 시작한 사람이 그것이 해당 논문에 관한 것인 것을 모를 리가 있겠습니까?).
이 시점에서 플러그인이 필요한 것이 정확히 무엇인지 명확하지 않습니다.
성능 문제가 어디에서 발생하는지에 대해 말씀해 주실 수 있나요? 즉, 특정 페이지에서 발생하는 문제인지, 아니면 일반적인 문제인지요? 각 카테고리가 하나 또는 두 개의 그룹에 연결되어 있고, 평균 사용자는 총 10~20개의 카테고리에만 접근할 수 있다면, 2만 개의 카테고리가 있는 것이 여전히 문제가 될까요?
제 (가상의) 사용 사례는 공개된 주제에 대한 논의를 그룹 DM(개인 메시지)을 통해 가능하게 하는 것입니다. 이 접근 방식은 양극화된 주제에 대해 생산적인 공개 논의를 유도하기 위해 몇 가지 다른 방식으로 활용될 수 있습니다. 본질적으로, 특정 주제와 관련된 팀(그룹)에 참여하도록 요청하고, 팀으로서 공개 주제에 대응하기 위해 일련의 규칙을 따르도록 함으로써 논의를 게이미피케이션(게임화)할 수 있습니다.
수천 개의 그룹이 사이트 운영진에게 초래할 수 있는 UI(사용자 인터페이스) 문제들을 처리할 준비가 되어 있습니다. 이는 Discourse 그룹에 대해 예상치 못한 사용 사례임을 알기 때문에, 제가 놓치고 있는 명백한 성능 문제가 있는지 확인하기 위해 여기에 게시합니다.
음, 내 예상보다는 훨씬 더 말이 되는 것 같네요. 
사용자 생성 그룹 기능이 개발 중인 것으로 보이는데, 아직 좀 더 걸릴 것 같습니다.
좋긴 하지만, 지금은 API를 통해 할 수 있습니다.
오, 조금 주제에서 벗어나고 있네요. 하지만 각 새 토픽마다 웹훅을 수신하는 그 API 중 하나를 사용해서 자동으로 그룹을 생성할 수 있어요. 플러그인은 필요 없어요. 왜 그 서비스 양쪽에 Discourse를 두는 방법을 생각하지 못했는지 모르겠어요.
그리고 GitHub - triggerdotdev/trigger.dev: Trigger.dev – build and deploy durable AI agents and workflows · GitHub 이 오늘 제 눈에 들어왔어요. 그 서비스 중 하나에 돈을 내는 대신 이걸로 일을 처리할 수 있을 것 같아요. Discourse를 기본적으로 지원할지는 모르겠지만, 동작하게 만드는 것은 충분히 쉬울 거예요.