2

My employer has a social intranet site with 1000s of users, groups, communities and blogs. Users are free to 'follow' or 'like' nodes, blogs and other users, subscribe to communities, join groups etc.

What I'm trying to achieve is the following.

  1. User A posts some content, for the sake of argument a blog.
  2. User B comes along, reads the blog and 'follow's it.
  3. User A needs to be notified that the blog has been followed.
  4. User B needs to be notified in the future that the blog has changed, been added to, modified or even simply 'like'd by another user.

This is all good with small numbers of people involved. However, as mentioned earlier, there are 1000s of people on this site. When a lot of users follow a blog or 'like' something, they all need to be informed of the update and it is here that I'm having the problem. The regular nodeJS module for Drupal seems to blanket broadcast to every active session on the site at that moment, and let Drupal figure out who needs to be told but the load on the server is massive as most of the notifications are unnecessary.

I've had a look at the Actions NodeJS module as well which at first glance seemed to be absolutely ideal as I know I can tell it to just get a list of the users who are followers, loop through each one and tell them that something has happened. The problem with this lies in that the initial event, 'like'ing something for example, does not complete until everyone has been notified so the system hangs until exit.

For example,

  1. User A posts some content.
  2. Users B through X all 'like' that content.
  3. User Y comes along and 'like's it as well.

Users A through X all get told that User Y has liked it but the 'like' operation from User Y's point of view does not complete until the last person has been notified. Again, this is not so much of a problem with a handful of users, but with possibly 1000s this becomes an issue to be dealt with now. If it's just an implementation issue and you know how to solve this, shout up.

Some 'back of a crisp packet' calculations say that the slow part of the process is the looping through of all the relevant users. Accessing the database to get the list of relevant UIDs is pretty quick as is the sending of the actual message.

Am I looking at writing some custom code to handle this? Am I going to be better off handing the work to a separate thread to process the notifications? Is this even possible? Does a module exist already that can perform this task efficiently? This is greenfield by the way. Anything will be considered for this task as performance on the site with the current implementation is 100% toilet. It may be that the current implementation is flawed and the existing modules are perfectly capable of accomplishing this, this is a real possibility. However, from what I've read, I don't think that this is the case.

I don't want to blanket broadcast to the site and let Drupal sort out who needs to see the notification as that means many unnecessary hits on the server but if that's how things are supposed to work, please let me know. I'd much rather just target a list of users and hit them, that seems to me to be the better way forward. All hints, tips, ideas and suggestions are welcome. The NodeJS module allows a system-wide broadcast which is pretty much instant across all open sessions. What I'd love is to be able to harness that performance but with a targeted list of UIDs.

Other info you may need to know.

  • I have a dedicated Node JS server at my disposal
  • The main Drupal site has 3 web heads but only using 1 at the moment for testing. Usual behaviour is 'round robin'ned across the 3 servers.
  • The site is hosted on a private network
  • No anonymous users allowed; everyone has to log in to use the site so everyone has a UID.
  • PHP v5.3.3
  • Drupal v7
  • NodeJS v0.10.36

Upgrading the software isn't really an option but if it absolutely 100% can not be accomplished any other way, then it becomes an issue for discussion for those on a higher pay grade to me. I've already said that I think things should be upgraded, particularly NodeJS, but there is definite resistance to this, don't ask me why.

1 Answer 1

0

Option 1: Message stack

Have a look at the Community documentation about the Message Stack, which consists of these modules (quotes are from the module's project page):

  • Message:

    The Message module is the core of the message stack. It enables logging and displaying system events in a number of different use cases. Events that are recorded over time are sometimes call activity streams. Exportable messages subtypes can be created for different use cases with custom fields and display (view) modes.

  • Message Notify.

    This module provides a method for sending a message via a notifier plugin. Message Notify comes with plugins for email and SMS and may be extended to other transport mechanisms as required.

  • Message Subscribe.

    With this module, users who subscribe to content will be notified when events occur that involve that content. The module leverages the Flag module, which provides a subscribe functionality to users.

These are the basic components and dependencies of the message stack:

enter image description here

Quite a few popular Drupal distributions already adopted to this Message Stack, such as such as Commerce Kickstart, Drupal Commons, ERPAL and Open Atrium. And it will make you well positioned for Drupal 8 also (because of he modules' object orientated architecture). Even though there is no such a thing as 8.x-dev yet, the Message code repository already does contain something already (not yet for the 2 other modules though). I assume the wip part of the branch name stands for 'Work In Progress'.

If you want to have a closer look at the Message Stack in your own environment, then experiment a bit with the Answers module (disclosure: I'm a co-maintainer), together with the Answers Notification sub-module, which allows logged in users to subscribe to selected questions, so that they receive notifications (using the Message Stack) when Questions receive Answers.

Option 2: Menu badges

A completely different approach is to use the Menu Badges module, which you could use to configure them using the integration of it with the Views module.

Some more details about some views that seem appropriate for your case:

  • A view of users "following" a node, whereas "following" could be implemented using the Flag module. A variation of this could be "nodes liked by users".
  • A view of changed nodes followed by the current user.

For more details, refer to my answer to "How to create a basic message - notifications system displaying a real time message counter badge?".

5
  • Thanks for the response, Pierre. I'll take a look at what you've suggested and see if it helps any.
    – doop_dev
    May 4, 2016 at 8:51
  • Mods - Please can you close this question? I haven't accepted it as answered as the given response didn't help but it might help someone in the future.
    – doop_dev
    Jul 15, 2016 at 13:32
  • @doop_dev : merci for the feedback, sorry it didn't help "you". But why would you want your question to be closed? Maybe somebody else might post an answer that does help "you". If the question would be closed, nobody will ever be able to answer anymore. Jul 15, 2016 at 13:37
  • That's a good point. Mods, ignore me. Pierre is right.
    – doop_dev
    Jul 15, 2016 at 13:38
  • @doop_dev : aha, good to hear ... But "we" won't ignore you ... at least I won't ... I might even post an additional answer using a different solution. Jul 15, 2016 at 13:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.