데이터베이스 공유: Rails 애플리케이션이 Discourse와 동일한 데이터베이스를 사용하길 원합니다.
로그인 공유: Discourse의 로그인 시스템을 사용하고, 세션 쿠키를 재사용하여 앱의 다른 부분에서도 사용자가 인증된 상태를 유지할 수 있으면 좋겠습니다.
내 구성 요소에 새로운 라우트 여러 개를 추가하는 것.
보너스: 로그인한 사용자를 해당 추가 구성 요소로 연결하도록 Discourse의 뷰 헬퍼를 커스터마이즈하는 것 (이것은 설정만으로 처리할 수 있는지도 모르겠지만, 사이트 전체의 정보를 커스터마이즈할 수 있는 오버라이드 가능한 Rails 헬퍼가 있는지 궁금합니다).
HAProxy를 사용하여 Discourse를 프록시 뒤에 두고 도메인의 경로로 라우팅하는 방법에 대한 게시글을 확인했습니다. 하지만 저는 Rails 프레임워크를 다른 앱에서 중복해서 사용하지 않으려고 하기 때문에 이것이 원하는 방식이 아닙니다 (또한 다른 앱에서 사용자 세션을 얼마나 쉽게 재사용할 수 있을지도 불확실합니다). Discourse를 더 큰 Rails 애플리케이션의 구성 요소로 사용할 수 있을까요?
별도의 앱을 가지는 장점 - 여기서 더 나은 지원을 받을 수 있으며, Discourse에서 이루어지는 업데이트가 앱 쪽에 영향을 주지 않습니다.
사이트를 "대형 Discourse 플러그인"으로 만드는 장점 - Discourse에서 사용할 수 있는 모든 기능과 헬퍼(사용자 관리 관련 기능 포함)를 활용할 수 있으며, 이는 결코 과소평가할 수 없는 이점입니다.
무엇을 구축하느냐에 따라 달라지겠지만, @justin은 직접 Discourse 위에 스캐폴딩을 할 경우 발생할 수 있는 유지보수 부담에 대해 경고를 하고 싶어 하는 것 같습니다. Discourse에 직접 스캐폴딩을 구축하는 경우 완전히 지원할 수 있는 방법은 없으며, 내부 헬퍼와 스키마는 모두 변경될 수 있으므로(Subject To Change) 오히려 더 큰 문제가 될 수 있습니다. 물론 무엇을 구축하느냐에 따라 달라지겠지만, 그만큼 가치가 있을 수도 있고요
플러그인을 잠시 살펴봤습니다. 저는 Ember 대신 다른 JS 프레임워크를 사용하는 것을 선호합니다(저는 Svelte 팬입니다). 이 방식이 Discourse Rails 앱(제가 잘 모르는 부분)에 한 겹의 인터페이스를 추가해서 문제를 해결하는 데 더 복잡함을 더할까 봐 조금 우려됩니다. 그래서 이걸 독립적인 앱으로 유지하는 쪽으로 기울고 있습니다. 저는 Rails를 꽤 잘 알고 있고(또는 Rails 앱을 프록시하는 것도 잘하고) Discourse는 아직 잘 모르지만, 이 방향으로 가면 장애 요소가 적을 것 같습니다.
