Examples of Extensive API Use/Integration with Non-Blog Sites?

Does anyone have examples of tight discourse integration on a non-blog site or sites across multiple domains to share?

Looking over the Discourse API, a lot should be possible deeply integrating discourse with separate domains. I am personally interested in using Discourse as the backbone for community features across some gaming related content sites. Embedded discussions and single sign-on at a minimum, which I have pretty much done without even using the API. Fantastic system.

I have not spent the necessary time yet to get it right, so my current setup is jarring for users and most bounce after clicking “continue discussion” or “start discussion”. I would love to see some advanced examples before I really dig into fixing the obvious.

If this doesn’t belong in support feel free to move, figured it was this or uncategorized.

Thanks

One thing that I did on a community and people loved, was integrating the notifications.

The main site had notification and many apps that made people be there a lot of time. I merged the forum notifications and the main site notifications, all came trough the same websockets connection and where interleaved and had the same look.

Other obvious integrations, are the SSO, avatars, search results and last post widgets on home page.

6 Likes

Integrated notifications and search I actually hadn’t given much thought, those are great ideas. Was this a multi-domain setup? Would love to see your work if public, sounds great.

Unfortunately it was all on a intranet :frowning:.

Yes, they where on a different domain. But all calls to Discourse API are made in the backend, so you won’t have CORS problems and cache calls when needed. Since you have SSO, you know the user account on the main site and on the forum, so it’s easy to extract the data.

Search is easy. When a user executes a search, your backend call your main site search and discourse search at the same time. When both returns (or one of then timeouts) you merge the data and return to user. Make the both calls concurrent and it will be fast.

This is a little more involved, you need to:

  1. listen to new notifications (rails model callback),

  2. transform Discourse notification data into your site format (Discourse doesn’t store the notification link destination in a very straightforward manner)

  3. Publish the transformed notification using your current site system.

3 Likes

Wouldn’t a webhook on notification be a bit easier here?

3 Likes

Well, 2 years ago Discourse didn’t had webhooks :stuck_out_tongue:.

But today, creating a webhook on notifications may be feasible. Even if it would require a bigger sidekiq poll for some forums.

2 Likes

Too bad on the intranet :frowning: . Thanks the tips though @Falco! The search implementation you are describing is basically what I would do too. Websocket notifications would likely scope my project too much at this stage, but that’s super cool.

Have you done anything exceptional with the companion posts on discord for pages with embedded discussions? The results I am getting with the default configuration are poor, mostly because its not blog content and the target page html is complex.

My thought here would be to do a custom RSS feed specifically for companion posts, since that functionality seems well developed in Discord. For reference, I’m talking about creating an RSS feed for content like this character page, which is pretty hacky. Know a better way?

What I’ve tested so far is targeting specific page elements (didn’t work well) and using a hidden div with forum markup (super hacky).