É possível usar o Discourse como um componente de um aplicativo Rails maior?
Meus objetivos:
Compartilhar o banco de dados. Eu adoraria que meu aplicativo Rails usasse o mesmo banco de dados que o Discourse usa.
Compartilhar o login: seria ótimo se eu pudesse usar o sistema de login do Discourse e reutilizar o cookie de sessão para manter os usuários autenticados em diferentes partes do meu aplicativo.
Adicionar várias novas rotas aos meus componentes.
Bônus: personalizar os helpers de visualização do Discourse que direcionam usuários logados para esses componentes extras (talvez isso seja algo que eu possa fazer apenas nas configurações, mas me pergunto se existem helpers do Rails que podem ser sobrescritos para personalizar informações de todo o site).
Vi a postagem sobre o uso do HAProxy para colocar o Discourse atrás de um proxy e rotear para um caminho em um domínio. Isso não é o que eu quero, porque adoraria evitar duplicar o framework Rails em outro aplicativo (e não tenho certeza de quão facilmente eu poderia reutilizar a sessão do usuário em outro aplicativo). É possível usar o Discourse como um componente em um aplicativo Rails maior?
Não tenho certeza se é possível fazer isso, mas, mesmo que fosse, não é necessariamente recomendável.
Sua instalação nunca será suportada pela nossa comunidade, pois seria muito personalizada.
Você precisaria ser responsável por mesclar quaisquer alterações no Discourse. Dada a velocidade com que fazemos commits no repositório, isso pode significar muito trabalho para você, dependendo do que você alterar.
Você já pode fazer algo parecido com SSO. Essa é uma abordagem mais recomendada para esse tipo de situação.
Isso é ótimo. Fico feliz em saber de antemão que isso não é recomendado, o que me poupa o trabalho de tentar e falhar miseravelmente!
Ok. Parece que a melhor maneira é usar dois aplicativos Rails (Discourse e meu aplicativo personalizado) atrás de um proxy reverso.
Após refletir, parece que manter dois bancos de dados aqui é uma opção melhor para garantir que meu aplicativo não atualize o banco de dados do Discourse de uma maneira ruim que os autores do Discourse nunca pretendiam.
Hmm, eu seria menos pessimista. Você também poderia dizer que isso poderia ser um plugin muito grande.
O plugin Custom Wizard é tão grande que quase se torna um aplicativo separado (especialmente no front-end).
Há muitas funcionalidades genéricas úteis já integradas ao Discourse que você pode reutilizar, como a estrutura e as funcionalidades de contas de usuário, o pipeline de implantação, etc.
Além disso, você pode adaptar muitos casos de uso ao Discourse no front-end. Os tópicos são suas páginas, por exemplo.
Acho que o detalhe é que o diabo está nos detalhes.
Vantagens de ter um aplicativo separado: podemos oferecer um suporte melhor aqui, e qualquer atualização do Discourse não quebrará o lado do seu aplicativo.
Vantagens de ter o site como um “grande plugin do Discourse”: você terá todos os recursos e assistentes disponíveis no Discourse (incluindo toda a parte de gerenciamento de usuários), o que não deve ser subestimado.
Seria legal, dependendo do que você está construindo. Acredito que o @justin queira alertá-lo sobre a possível sobrecarga de manutenção que você assumirá. Não há como oferecer suporte total se você estiver construindo diretamente sobre o Discourse, pois todos os nossos assistentes internos e esquemas estão sujeitos a alterações ™, então isso pode causar mais problemas do que vale a pena. (Dependendo do que você está construindo, é claro! Também pode ser facilmente vale a pena )
Sim, isso é muito verdade. É necessário ter experiência para escrever plugins que sejam resilientes a alterações no núcleo. Você precisará evoluir alguns elementos do aplicativo para acompanhar as mudanças no Discourse. Mas é possível fazer isso.
Dê uma olhada rápida nos plugins. Prefiro usar um framework JS diferente do Ember (sou fã de Svelte) e estou um pouco preocupado que isso adicione uma camada/interface ao aplicativo Rails do Discourse (com o qual não estou familiarizado), tornando a solução de problemas mais complicada para mim. Estou inclinado a manter isso como um aplicativo separado. Conheço bem o Rails (e fazer proxy de aplicativos Rails também), mas ainda não conheço o Discourse e sinto que terei menos obstáculos se seguir por esse caminho.
)