Domain events In Discourse

AI-generated summary

In a discussion about implementing domain events in Discourse, Del_Boy_Trotter asks if there’s a built-in mechanism to notify external apps of key events like @mentions or badge awards. codinghorror requests clarification on specific event types desired. Del_Boy_Trotter explains the need for out-of-process, real-time notifications for users still active in their external app. riking suggests polling /notifications.json server-side using a master API key (not client-side), which Del_Boy_Trotter finds inefficient due to per-user polling overhead. riking then asks sam if MessageBus subscribers can bypass channel security to receive all messages — e.g., all notifications or user channels. sam confirms no global “subscribe all” exists but is open to adding such a feature if there’s demand. Del_Boy_Trotter concludes they’ll likely implement a custom solution, hinting at integrating with MessageBus or similar. The thread reveals a gap in Discourse’s eventing system for external integrations, with potential for future enhancement via MessageBus or a new admin-only subscription mechanism.

is there any concept of domain events in discourse? We’d like our app to be notified of certain events within discourse.

If not we’ll be looking at creating this as some sort of extension but I do think there’d need to be code added to the main code in order to fire the events.

Ideally the aggregator would be generic so we (or anyone) can plug in their own mechanism for consuming or forwarding these events.

Anyone know anything about this?

1 Like

Can you be more specific about what events you want to see?

I guess it’s things that would be interesting to the user still in our app but outside of discourse. So off the top of my head:

  • @mentions
  • badge awarded
  • etc

Basically whenever there is a notification in the header for a user - we could then listen out for these events (probably by subscribing to RabbitMQ topics) and forward the notifications in our header.

You can request /notifications.json?silent=true&api_username=$username&api_key=$master_api_key (FROM THE SERVER TO DISCOURSE - do not ship the master api key to clients)

This will give you the notifications, without marking them as seen (clearing the blue indicator).

(The master API key lets you perform requests as any user.)

hmmm I’d rather do this out of process. Also we’d have to poll discourse for each user which is not something I’d like to get into.

Actually…

@sam is it possible for a MessageBus subscriber to receive all messages, regardless of the specified security settings? (The user_ids/group_ids)

Then your service could subscribe to all /notifications/:userid channels, or all /topic/:id channels, or…

There is no override subscribe all (admin only) thing, but I am fine to add that to message bus if people want to submit a PR.

Looks like I’ll be taking my 1st dive into ruby!