Ist es möglich, Discourse als eine Komponente einer größeren Rails-Anwendung zu verwenden?
Meine Ziele:
Datenbank teilen: Ich würde gerne, dass meine Rails-Anwendung dieselbe Datenbank verwendet wie Discourse.
Login teilen: Es wäre großartig, wenn ich das Login-System von Discourse nutzen und das Sitzungs-Cookie wiederverwenden könnte, um Benutzer an verschiedenen Stellen meiner App zu authentifizieren.
Eine Reihe neuer Routen für meine Komponenten hinzufügen.
Bonus: Discourse-View-Helfer anpassen, die angemeldete Benutzer zu diesen zusätzlichen Komponenten weiterleiten (vielleicht ist das etwas, das ich rein über Einstellungen erledigen kann, aber ich frage mich, ob es überschreibbare Rails-Helfer gibt, mit denen man sitzungsweite Informationen anpassen kann)?
Ich habe den Beitrag über die Verwendung von HAProxy gesehen, um Discourse hinter einem Proxy zu stellen und auf einen Pfad einer Domain umzuleiten. Das ist nicht das, was ich möchte, da ich gerne vermeiden würde, das Rails-Framework in einer anderen Anwendung zu duplizieren (und ich bin mir nicht sicher, wie einfach es wäre, die Benutzersitzung in einer anderen Anwendung wiederzuverwenden). Ist es möglich, Discourse als Komponente in einer größeren Rails-Anwendung zu verwenden?
Ich bin mir nicht einmal sicher, ob das überhaupt möglich ist, aber falls ja, ist es nicht unbedingt ratsam.
Deine Installation wird von unserer Community nicht unterstützt werden können, da sie zu stark angepasst wäre.
Du müsstest selbst dafür sorgen, alle Änderungen an Discourse zusammenzuführen. Angesichts der Geschwindigkeit, mit der wir Commits in das Repository einbringen, könnte dies je nach deinen Änderungen eine riesige Menge an Arbeit für dich bedeuten.
Das kannst du bereits mit SSO in gewisser Weise umsetzen. Das ist der empfohlene Ansatz für solche Anforderungen.
Das ist großartig. Ich bin froh, dass ich im Voraus weiß, dass dies nicht empfohlen wird – das spart mir die Mühe, es auszuprobieren und kläglich zu scheitern!
Okay. Es klingt so, als wäre der beste Weg, zwei Rails-Anwendungen (Discourse und meine benutzerdefinierte App) hinter einem Reverse-Proxy zu betreiben.
Nach reiflicher Überlegung scheint es besser zu sein, zwei separate Datenbanken zu verwenden, um sicherzustellen, dass meine App die Discourse-Datenbank nicht auf eine Weise verändert, die von den Discourse-Entwicklern nie beabsichtigt war.
Hmmm, ich wäre weniger pessimistisch. Man könnte auch sagen, dass dies ein sehr großes Plugin sein könnte.
Das Custom Wizard-Plugin ist so groß, dass es fast eine eigene App ist (besonders auf der Frontend-Seite).
Es gibt viele nützliche generische Funktionen in Discourse, die du wiederverwenden kannst, z. B. das Benutzerkonten-Framework und die dazugehörigen Funktionen, die Bereitstellungs-Pipeline usw.
Außerdem kannst du viele Anwendungsfälle auf der Frontend-Seite an Discourse anpassen. Themen sind deine Seiten usw.
Vorteile einer separaten App: Wir können Sie hier besser unterstützen, und Updates von Discourse werden Ihre App-Seite nicht beeinträchtigen.
Vorteile einer Website als „großes Discourse-Plugin“: Sie erhalten alle zusätzlichen Funktionen und Hilfsprogramme, die in Discourse verfügbar sind (einschließlich aller Benutzerverwaltungsfunktionen), was nicht zu unterschätzen ist.
Es könnte cool sein, je nachdem, was Sie entwickeln – ich denke, @Justin möchte Sie vor dem potenziellen Wartungsaufwand warnen, den Sie dabei übernehmen. Wir können Sie nicht vollständig unterstützen, wenn Sie direkt auf Discourse aufbauen, und alle unsere internen Hilfsprogramme und Schemata sind Änderungen vorbehalten (Subject To Change™), sodass es mehr Ärger verursachen könnte, als es wert ist. (Je nachdem, was Sie entwickeln, natürlich! Es könnte auch leicht den Aufwand wert sein ;))
Ja, das stimmt absolut. Es erfordert Erfahrung, robuste Plugins zu schreiben, die sich an Änderungen im Kern anpassen. Sie müssen einige Elemente der App weiterentwickeln, um mit den Änderungen in Discourse Schritt zu halten. Aber das ist machbar.
Ich habe mir Plugins kurz angesehen. Ich bevorzuge ein anderes JS-Framework als Ember (ich bin ein Svelte-Fanboy) und bin etwas besorgt, dass dies eine zusätzliche Schicht oder Schnittstelle zur Discourse-Rails-App hinzufügt (mit der ich nicht vertraut bin) und die Fehlersuche für mich erschwert. Ich tendiere dazu, dies als separate App zu belassen. Ich kenne Rails recht gut (und das Proxying von Rails-Apps ebenfalls), bin aber mit Discourse noch nicht vertraut und habe das Gefühl, dass ich auf diesem Weg weniger Hindernisse haben werde.