@withjoy/message-queue

message-queue

Node.js module that provides classes to publish messages/subscribe to the queue. Also declares types that dictate the expected format of the message queue payloads.

FIXME: To Be Documented

• how it uses rxjs
• where are the useful Types?

Users

• email_service uses its subscriber code in order to listen to new push notification and email send requests.
• registry_service uses its publishing code in order to trigger new push notifications and emails.
• event_service uses its publishing code for most of its Post Office features, as well as Couple notifications.
• TODO: add other users here

Related Documentation

• Publishing a New Email to Email Service
• Knowledge / Engineering / Emails
• Developing Node Module

Setup

You will need

• Node 12, or whatever matches .nvmrc

Then, from within message-queue,

# set up Node
nvm use
yarn install

# run the Test Suite
yarn test

This is sufficient if you're developing your changes in isolation.

However, it's likely that you'll also want to try out the results "live" using email_service. You'll need to install it locally and link the two repos. Please consult the email_service README section that talks about 'editing message-queue'.

Core Principles

One of the main jobs of this module is to provide consistent payload "shapes" of a message for both the Producer and Consumer (email_service).

The Email payload shapes live in 'src/queue.types/email.ts';

• EmailType specifies a unique name for each message / payload type
• EmailType + EMAIL_TYPE_SET calls out all of the EmailType names
• each shape implements an interface that extends EmailInfo (to provide the emailType)
• EmailInterfaces calls out all of the interfaces

The Push Notification payload shapes live in 'src/queue.types/push.notifications.ts' and follow a similiar paradigm.

Publishing the Module

To publish a new version of this module,

• do not up-version on your development branch
• merge your fixes into master
• from the master branch,

yarn version --patch  # or whatever is suitable

As a follow-up,

• package.json is up-versioned
• a semver-ish tag is pushed to Git
• CircleCI will perform the yarn publish operation when it detects the tag
• it's ready once the 'versions' in yarn info @withjoy/message-bus have been updated

Standard Queue Names

message-queue uses an Azure Storage Queue for pub-sub. There is one Queue per deployment environment. It is configured as AZ_QUEUE_ACCOUNT_NAME within the Service that imports this module, along with a corresponding secure AZ_QUEUE_ACCOUNT_KEY.

Environment	Queue
Development	withjoyvendorsdev
Staging	withjoyvendorsstage
Production	withjoyvendorsprod

These Queues should not be used for local development. If you subscribe to them locally, you will be work-stealing from the deployed Service.

There is an additional Queue -- joymessagequeuelocal -- which has been created for local development purposes. However, like the others, that Queue is a singleton shared by all Developers. If two Developers are running event_service locally, they can work-steal from each other.

In such a case, you might not see your changes, because the email could be generated by someone else's Service. Fortunately, this rarely happens.

CircleCI

Its Project uses the following Environment Variables:

• ARTIFACTORY_TOKEN
• CIRCLE_CI_KEY
• DOCKER_HUB_PASSWORD
• NPM_TOKEN