Est-il possible d’utiliser Discourse comme l’un des composants d’une plus grande application Rails ?
Mes objectifs :
Partager la base de données. J’aimerais que mon application Rails utilise la même base de données que Discourse.
Partager la connexion : il serait idéal de pouvoir utiliser le système de connexion de Discourse et de réutiliser le cookie de session pour authentifier les utilisateurs dans différentes parties de mon application.
Ajouter un grand nombre de nouvelles routes à mes composants.
Bonus : personnaliser les helpers de vue de Discourse qui redirigent les utilisateurs connectés vers ces composants supplémentaires (peut-être que je peux le faire uniquement via les paramètres, mais je me demande s’il existe des helpers Rails surchargeables permettant de personnaliser les informations à l’échelle du site).
J’ai vu le post sur l’utilisation de HAProxy pour placer Discourse derrière un proxy et le router vers un chemin sur un domaine. Ce n’est pas ce que je veux, car j’aimerais éviter de dupliquer le framework Rails dans une autre application (et je ne suis pas sûr de la facilité avec laquelle je pourrais réutiliser la session utilisateur dans une autre application). Est-il possible d’utiliser Discourse comme composant dans une plus grande application Rails ?
Je ne suis même pas certain que ce soit possible, mais si c’est le cas, ce n’est pas nécessairement recommandé.
Votre installation ne pourra jamais être prise en charge par notre communauté, car elle serait trop personnalisée.
Vous devrez vous charger de fusionner toutes les modifications apportées à Discourse. Au rythme où nous effectuons des commits dans le dépôt, cela pourrait signifier un énorme travail pour vous, selon ce que vous modifiez.
Vous pouvez en quelque sorte faire cela avec SSO dès maintenant. C’est une approche plus recommandée pour ce type de besoin.
C’est super. Je suis content de savoir dès le départ que ce n’est pas recommandé, cela m’évite d’essayer et d’échouer lamentablement !
Ok. Il semble que la meilleure solution soit d’utiliser deux applications Rails (Discourse et mon application personnalisée) derrière un proxy inverse.
Après réflexion, il semble que garder deux bases de données soit une meilleure option pour m’assurer que mon application ne modifie pas la base de données de Discourse d’une manière que les auteurs de Discourse n’ont jamais prévue.
Hmm, je serais moins pessimiste. On pourrait aussi dire que cela pourrait être un plugin très volumineux.
Le plugin Custom Wizard est si grand qu’il ressemble presque à une application distincte (surtout sur le front-end).
Il y a beaucoup de fonctionnalités génériques utiles intégrées à Discourse que vous pouvez réutiliser, par exemple le cadre et les fonctionnalités des comptes utilisateurs, le pipeline de déploiement, etc.
De plus, vous pouvez adapter de nombreux cas d’utilisation à Discourse sur le front-end. Les sujets sont vos pages, etc.
C’est vrai — vous pourriez créer un gros plugin pour intégrer votre « app ». Il y a beaucoup de possibilités, selon la profondeur à laquelle vous souhaitez aller !
Avantages d’avoir une application distincte : nous pouvons mieux vous soutenir ici, et toute mise à jour de Discourse n’affectera pas votre application.
Avantages d’avoir le site comme un « grand plugin Discourse » : vous bénéficiez de toutes les fonctionnalités et assistants disponibles dans Discourse (y compris toute la gestion des utilisateurs), ce qui n’est pas à sous-estimer.
Ce serait génial selon ce que vous construisez — je pense que @justin souhaite vous mettre en garde contre la charge de maintenance potentielle que cela implique. Nous ne pouvons pas vous soutenir pleinement si vous construisez directement sur Discourse, et tous nos assistants et schémas internes sont sujets à modification ™, donc cela pourrait s’avérer plus problématique qu’il n’y paraît. (Bien sûr, cela dépend de ce que vous construisez ! Cela pourrait aussi facilement valoir le coup )
C’est tout à fait vrai. Il faut de l’expérience pour écrire des plugins robustes face aux modifications du cœur. Vous devrez faire évoluer certains éléments de l’application pour suivre les changements de Discourse. Mais c’est possible.
J’ai jeté un coup d’œil rapide aux plugins. Je préfère utiliser un framework JS différent d’Ember (je suis un fan de Svelte), et je suis un peu inquiet que cela ajoute une couche ou une interface à l’application Rails de Discourse (que je ne connais pas bien), ce qui rendrait le dépannage plus compliqué pour moi. Je penche plutôt pour garder cela comme une application distincte. Je connais assez bien Rails (et la mise en proxy d’applications Rails), mais je ne connais pas encore Discourse, et j’ai l’impression que je rencontrerai moins d’obstacles en suivant cette voie.
)