Writing contrib modules as glue between your custom code
A few years ago, I worked on an event booking and management website for a charity in the UK.
One required piece of functionality was to allow event organisers to send a private message to all attendees of an event.
We decided to use the Private Message module but were concerned about hitting memory limits or timeouts, as some events had several hundred attendees.
We decided that we needed to use a queue and have it process and send the messages.
This split the feature into three parts:
- The UI for event organisers to enter and send their messages.
- The queue that stores and processes pending messages in the background.
- The Private Message module that would create and send each message, provide an inbox for each user, and provide notifications.
The UI for event organisers was specific to the project and had to be custom code and not open-sourced.
The Private Message module is already a contributed module, but what about the queue part?
This is why the Private Message Queue module was created.
Instead of keeping it within the project's custom code, we created it as an open-source module on Drupal.org.
It contains no customer or project-specific information and only adds generic functionality - it creates a queue to hold private messages to be processed in the background.
It provides the glue between our custom UI and the Private Message module.
As there was no reason why we needed to keep it private, we made it public and developed it as its own project from the beginning instead of planning and hoping to do so later.
- Oliver
