저희 엔터프라이즈 커뮤니티가 (사용자 측면과 비즈니스 측면 모두에서) 큰 성공을 거두면서, 문서 팀이 연락을 와 documentation.sailpoint.com 전체에 대한 댓글 시스템을 구축할 수 있는지 물어보았습니다. 현재로선 우리가 최소한으로 이루고자 하는 것의 거의 모든 것을 수행할 수 있을 것 같습니다:
댓글 임베딩 (임베딩 기능)
또한 임베딩에 따라 다른 사용자로 게시하고, 다른 태그 집합을 적용하는 것도 사용하고 싶습니다. 이 기능은 곧 출시될 예정입니다:
이것을 제외하고, 문서 팀(그리고 제 팀)이 원했던 모든 것은 Discourse 내에 존재하여, 나머지 “일상적인” 포럼 사용과 이 경험을 효과적으로 분리하면서도 사람들이 댓글을 달고, 답장에 대한 알림을 받을 수 있는 기능을 제공할 수 있습니다.
목표가 https://documentation.sailpoint.com/ 에서 사용자가 댓글을 생성할 수 있도록 하는 것인지, 아니면 문서 사이트에 댓글을 임베드하고 사용자가 글을 댓글 달기 위해 Discourse 사이트를 방문하도록 하는 방식이라면 괜찮은 건지 궁금합니다.
전자는 제가 반갑게 맞이할 기능이며 가져보고 싶은 기능입니다(읽어보기: CDCK, 제발 만들어주세요). 후자는 적어도 우리의 최소 요건을 충족합니다.
사실 가까운 미래에 Discourse가 우리의 마크다운 문서를 제공하도록 하는 아이디어를 탐구할 예정입니다(아니, 토픽 안에서가 아니라 전통적인 마크다운 스타일의 문서로요). 이 경우 코멘트와 코멘트를 작성하기 위한 가입이 모두 포함될 것입니다. 하지만 그 탐구는 아직 시작되지 않았습니다.
현재 제가 진행 중인 접근 방식으로는 Discourse 댓글을 MkDocs 페이지에서 직접 생성하는 것이 기술적으로 가능하지만, 이를 위해서는 MkDocs 페이지를 서빙하기 위해 서버 사이드 프레임워크(Remix, Rails 등)를 사용해야 합니다. 이렇게 하면 문서 사이트에서 사용자를 인증(DiscourseConnect를 통해)할 수 있고, 이전에 반환된 댓글을 캐싱하기 위해 인메모리 데이터베이스를 사용할 수도 있습니다.
(수정: 명확히 하기 위해 말씀드리자면, 저는 웹사이트를 Discourse의 인증 제공자(Identity Provider)로 사용하는 것이 아니라, Discourse를 웹사이트의 인증 제공자로 사용하는 것에 대해 이야기하고 있습니다. 후자의 방식은 작동하지만, 대부분의 사용 사례에는 너무 유연성이 부족합니다.)
그러나 팀이这么大的 변경을 감당해야 한다는 점에서 상당한 부담이 될 것입니다.
당신의 관점에서는 이것이 Discourse 내부에서 완전히 이루어지는 것이 더 직관적일 것이라고 생각하시겠지만, Discourse를 콘텐츠 관리 시스템(CMS)으로 사용하는 것도 가능합니다. 이 경우 마크다운 문서는 일반적인 Discourse 토픽으로 생성됩니다. 그리고 Discourse 웹훅(webhooks)을 사용하여 외부 사이트에서 문서 페이지 생성을 트리거합니다. 실제로 제가 설정 중인 Discourse 댓글 데모 사이트의 기반이 바로 이 방식입니다.
이 주제가 오늘의 링크와 연결되었기 때문에, 이 아이디어에 대해 작업을 진행한 후 얻은 결론으로 업데이트해야겠다고 생각했습니다.
OP에서 설명한 이유에 따라, 여전히 Discourse가 좋은 댓글 플랫폼이 될 수 있다고 생각합니다.
구현 방법에 대해서는, 이 작업은 Discourse 측에서 수행되어야 한다고 생각합니다. 이상적으로는 Discourse 댓글 임베드 스크립트를 개선하는 방식으로 이루어져야 합니다. 이는 점진적으로 진행될 수 있습니다.
기술적으로는 Discourse 클라이언트(예: WP Discourse 플러그인)에서 모든 작업을 수행하여 Discourse를 댓글 플랫폼의 서버로 사용하는 것이 가능합니다. 그러나 클라이언트와 Discourse 사이의 상태를 관리하고 속도 제한 문제를 우회해야 하므로, 이는 복잡한 문제로 이어집니다. 이는 제가 유지보수를 책임지고 싶을 만큼 복잡한 것이 아닙니다.
이 주제에 있는 몇몇 게시물에서는 사람들이 블로그 사이트에서 사용자가 Discourse 댓글을 만들 수 있도록만 하는 것에 관심이 있다고 나타났습니다. 제 관점에서 이는 훌륭한 해결책은 아니지만, 현재 Discourse API를 통해 달성할 수 있습니다. 복잡한 부분은 사용자가 일반적인 주류 뉴스 사이트에서 댓글과 상호작용하길 기대하는 것과 유사한 방식으로 웹사이트에서 Discourse 댓글과 상호작용할 수 있는 완전한 댓글 시스템을 구축하려는 시도입니다.
이 기능을 순수하게 클라이언트 측에서만 개발하는 데 망설인 이유는 시스템이 어떤 규모의 트래픽에서도 정상적으로 작동할 수 있는지에 대한 문제 때문이었습니다. 기본적으로 API 요청을 큐에 넣고 큐화된 요청의 응답을 처리해야 했습니다. 이는 예를 들어 1,000명의 동시 접속 사용자를 처리하기에 충분히 견고하지 않다고 느꼈습니다. JavaScript 임베드 방식도 유사한 우려가 있지만, 그 이유는 다릅니다. 다만, 모든 것을 클라이언트에서 동기화하려 하는 것보다는 훨씬 쉽게 처리할 수 있을 것으로 예상됩니다.
어제 이 주제가 다시 올라오면서(bump) 좀 더 깊이 생각해 보았습니다(그래서 여기에 게시글을 올린 것입니다). 저는 클라이언트 전용 솔루션(즉, JavaScript 임베드)이 여기에서 실제로 의미가 있는 유일한 방법이라고 생각합니다. 그렇지 않으면 결국 각자 고유한 문제를 가진 여러 플랫폼별 구현체들을 이야기하는 것이 됩니다.
동시성(concurrency)과 부하(load)가 문제가 된다는 지적이 맞습니다. ActivityPub의 경우 상당한 부하와 동시성 문제가 있습니다. 단일 ActivityPub 게시물이 Fediverse와의 수많은 수신 및 발신 요청을 유발할 수 있기 때문입니다. 이러한 맥락에서, 원격 클라이언트가 제어되는 상태이므로 오히려 약간 더 쉬울 수 있습니다. 또한 이 경우 동시성과 부하는 실제로 서버 측(즉, Discourse 측)에서만 문제가 되며, 이들은 문제가 되긴 하지만 백그라운드 작업, 캐싱, 뮤텍스(mutex)를 통해 해결할 수 있다고 생각합니다. 하지만 그렇다고 해도 고려해야 할 중요한 문제들입니다.
