저는 블로그와 포트폴리오라는 두 개의 별도 웹사이트를 위한 공유 포럼을 만드는 가능성을 검토하고 있습니다. 하나의 포럼 데이터베이스가 두 사이트를 모두 서비스하여, 사용자가 두 커뮤니티 간에 공유되고 주제도 함께 활용되도록 하는 개념입니다. 다만, 사용자가 방문하는 사이트에 따라 포럼의 스타일이 달라지도록 하여, 더 큰 공유 공간의 일부이면서도 각 커뮤니티가 고유한 느낌을 갖도록 하기를 원합니다.
저는 웹 개발 배경이 있지만, 최근에는 이 규모의 큰 프로젝트를 다루지 않았습니다. 이 프로젝트를 성공적으로 완수하기 위해 필요한 것을 다시 배울 의향이 있지만, 디스코urs가 이를 실현할 수 있는지 여부에 대한 조언을 구하고 싶습니다.
구체적으로 궁금한 사항은 다음과 같습니다:
디스코urs가 참조 도메인이나 URL에 따라 다른 테마나 스타일을 지원할 수 있나요?
사용자 데이터베이스와 주제 풀은 공유하되, 디스코urs를 커스텀 브랜딩(로고, 색상 등)을 표시하도록 구성할 수 있나요?
이 구현을 더 쉽게 만들어 줄 플러그인이나 확장 기능이 있나요?
이러한 유형의 설정을 추구할 때 고려해야 할 도전 과제나 제한 사항에 대한 조언이 있을까요?
이 프로젝트는 아직 개념 단계이며, 연말까지 구축을 시작할 계획입니다. 확약하기 전에 디스코urs가 이 비전에 적합한 플랫폼인지 확인하고 싶습니다.
여기서 빠르게 검색해 보았지만, 쉽게 가능할지 혹은 실제로 가능할지 확신이 서지 않습니다.
더 쉬운 방법으로는 기본 그룹에 연결된 토글을 사용하고, 그룹 A에서 그룹 B로 전환할 때 테마를 변경하도록 하는 방식이 있을 수 있습니다. 또한 그룹별 Customization > Theme component 커스텀 홈 페이지를 사용하는 것도 방법입니다. 아니면 air 테마에서 사용된 Modern Category+group 박스를 두 번 설치하고, 테마/기본 그룹에 따라 커스터마이징을 적용하는 방식도 고려해 볼 수 있습니다.
저는 직접 알지 못하지만, discourse를 두 개 설치하면 데이터베이스가 손상될 위험이 있는 것 같기도 합니다. 물론 스테이징 사이트를 운영하는 경우가 있지만, 스테이징 사이트는 메인 사이트에서 정기적으로 백업되는 것 같기도 합니다.
내 추측으로는 같은 데이터베이스 위에 여러 엔진(Discourse 설치)을 실행할 수 있을 것 같습니다(따라서 별도의 데이터베이스가 필요합니다). 다만, sidekiq는 1개만 실행하는 것이 좋습니다. 그렇지 않으면 두 개가 작업을 놓고 경쟁하게 될 테니까요. 그 외에는 Discourse가 무상태(stateless) 애플리케이션이라고 생각하므로, 몇 개를 실행하든 문제가 되지 않을 것입니다.
이제 근본적인 질문을 하나 드리겠습니다. 왜 그런 걸까요? 그리고 이것이 SEO 규칙에 위배되지 않나요? Google은 여러 사이트에서 동일한 콘텐츠를 발견하는 것을 좋아하지 않는다고 생각합니다.
사실 몇 가지 기능이 예상대로 작동하지 않을 수 있습니다. 예를 들어 실시간 UI 업데이트(누군가 기사를 업데이트하면 읽는 동안 마법처럼 다시 렌더링되는 경우)가 그렇습니다. 두 사이트가 서로를 알리지 않으므로 사용자에게 브라우저를 새로고침하도록 요청해야 할 것 같습니다. 더 많은 문제가 있을 수 있습니다. 예를 들어 한 사이트에서 사이트 설정을 변경하면 다른 사이트에서는 이를 감지하지 못할 것이며, 다른 사이트를 재시작해야 할 수도 있습니다.
Scaling up and sidekiq 를 참고하면 실제로 해결 가능한 문제인 것 같습니다. Sidekiq이 이를 처리하는 것으로 보이며, 나머지는 Redis를 올바르게 구성하는 문제일 것입니다.
이 부분을 좀 더 명확히 설명해 주실 수 있을까요? 그것이 어떻게 작동하는지 조금 더 알고 싶습니다. 두 문장이 서로 모순되는 것 같습니다. 모든 것을 반영하는 것이 실제로 OP가 요청한 것인 것 같습니다. 하지만 첫 번째 인스턴스에 의해 이루어진 변경 사항에 대해 다른 인스턴스가 통지를 받지 않는다면 어떻게 가능할까요? 데이터베이스에 저장되기는 하지만, 통지는 없으니까요.
그러면 단순히 db = 상태가 없(stateless)다는 뜻입니다. 요청을 할 때마다 데이터베이스에 다시 물어보는 것이죠 - 메모리 내 상태는 없습니다. 아니면 그런가요?
그렇지 않다면, 플러그인이라는 아이디어를 정말 좋아합니다. 이것이 나아갈 방향이라고 동의하며, 또한 SEO는 선택해서 하는 것이 아니라 청중을 확보하기 위해 어쩔 수 없이 해야 하는 것이라고 여전히 생각합니다. 중복(Duplication)은 실제로 이를 줄이는 방법일 수 있습니다. 사용자의 관점에서도 제가 한 사이트에서 작성한 것을 다른 사이트에서 링크로 보는 것은 의아할 수 있으며, 저는 정말로 불편할 것입니다. 콘텐츠 중복은 일반적으로 저품질 사이트가 사용하는 방법입니다. 그래서 SEO에서 불이익을 받습니다. 하지만 이것은 Community Building(커뮤니티 구축) 카테고리에 더 적합한 주제일 것입니다.
여기서 정의에 대한 혼란이 있는 것 같습니다. Discourse의 서버 측 코드는 (어느 정도*) 무상태(stateless)이지만, Discourse 인스턴스 전체(웹 클라이언트, 서버 측 코드, Redis, 캐시된 파일, 데이터베이스)는 무상태가 아닙니다.
그 메달의 다른 면은 다음과 같습니다. 서버 측 코드가 무상태라는 점을 고려할 때, 이 설정은 OP가 원하는 것을 달성할 수 없습니다. 왜냐하면 어떤 URL과 테마를 서빙해야 하는지에 대한 정보를 저장할 곳이 없기 때문입니다. 여러분이 설명하는 설정은 실제로 여러 웹 컨테이너와 단일 데이터베이스/Redis 인스턴스가 있는 로드 밸런싱 설정에서 발생하는 것과 동일합니다. 이는 단일 사이트입니다.
