Is it possible to use discourse as one component of a bigger rails app?
My goals:
Share the database. I would love to have my rails app use the same database as discourse uses.
Share login: meaning, it would be great if I could use the login system for discourse, and re-use the session cookie to have users authenticated in different places in my app.
Add a bunch of new routes to my components.
Bonus: customize discourse view helpers that point logged in users to those extra components (maybe this is something I can do purely in settings, but I wonder if there are overridable rails helpers you can use to customize sitewide information)?
I saw the post on using HAProxy to put discourse behind a proxy and route to a path on a domain. This is not what I want because I would love to avoid duplicating the rails framework in another app (and not sure how easily I could re-use the user session in another app). Is it possible to use discourse as a component in a larger rails app?
I’m not even sure if you could do this, but if you could, it’s not necessarily advisable.
Your install will never be supportable by our community as it would be too custom.
You’d need to be responsible for merging in any changes to Discourse. At the rate we commit to the repo, this might mean a ton of work for you depending on what you change.
You can kind of do this with SSO already. That is a more recommended approach for this kind of thing.
That’s great. I’m glad to know up front that this is not something recommended, saves me the trouble of trying it and failing miserably!
Ok. It sounds like the best way is to use two rails apps (discourse and my custom app) behind a reverse proxy.
After consideration, it seems like keeping two databases here is a better option to make sure my app does not update the discourse db in a bad way that discourse authors never intended.
Hmmm, I would be less pessimistic. You could also say that this could be a very large plugin.
The Custom Wizard plugin is so big It’s almost a separate app (especially on the front end).
There’s a lot of useful generic stuff written into Discourse you can reuse, eg User accounts framework and functionality, the deployment pipeline etc etc.
Also you can bend a lot of use cases around Discourse on the front end. Topics are your pages etc
Benefits of having a separate app - we can support you better here, and any updates Discourse does won’t break your app side of things.
Benefits of having the site be a “large discourse plugin” - you get all the bells and whistles and helpers available in Discourse (all the user management stuff as well) which is not to be underestimated.
It’d be cool depending on what you’re building - I think @justin wants to caution you about the potential maintenance overhead you take on. There’s no way we can fully support you if you’re scaffolding on to Discourse directly, and all of our internal helpers and schemas are Subject To Change™ so it could be more trouble than it’s worth. (Depending on what you’re building, of course! It could also easily be worth the trouble )
Yes that’s very true. It takes experience to write plugins which are robust to core changes. You will need to evolve some elements of the app to keep up with changes in Discourse. But it can be done.
I took a brief look at plugins. I prefer to use a different JS framework than Ember (I’m a svelte fanboy), and I’m a little concerned this will add a layer/interface to the discourse rails app (which I’m unfamiliar with) and make troubleshooting more complicated for me. I’m leaning towards keeping this as a separate app. I know rails pretty well (and proxying rails apps well), but don’t know discourse yet, and feel like I will have fewer blocks if I go down this route.
)