This guide explains the basics of using postmaster to manage events from rubykube Event API.
Nowadays postmaster support two components, that produce events
Read more about peatio Event API here.
Read more about barong Event API here.
An Event is a message produced to message broker in RFC7515.
Usually, events have the following structure
{
"payload": "string",
"signatures": [
{
"header": {
"kid":"string"
},
"protected":"string",
"signature":"string"
}
]
}
An Expression gives you the ability to apply additional event matching.
By specification defined in RFC7515 we can build a JSON Web Token.
After parsing of prebuild JWT, you will receive this payload with this structure.
{
"iss": "string",
"jti": "string",
"iat": 1567777420,
"exp": 1567777480,
"event": {
"record": {
"user": {
"uid": "string",
"email": "string",
},
"language": "string",
},
"name": "string"
}
}
Note: All events should be properly signed using RS256 private key.
Postmaster validates the signature of each upcoming event.
Further, we will see that postmaster user can work with this payload directly.
{
"record": {
"user": {
"uid": "UID12345678",
"email": "[email protected]"
},
"language": "EN"
},
"changes": {},
"name": "string"
}
When core model updates, the provider sends an event with routing key <model>.updated
, but sometimes you need
to apply additional event matching, in this case, you may want to use expression
.
The expression is evaluated by the postmaster when it receives an event.
In expression there two fields you can access: record
and changes
.
Note: Your expression
should always return boolean!
Example:
events:
- name: Withdrawal Succeed
key: withdraw.updated
exchange: peatio
expression: changes.state in ["errored", "confirming"] && record.state == "succeed"
templates:
EN:
subject: Withdrawal Succeed
template_path: templates/en/withdraw_succeed.tpl
For details about experssion language read documentation.
All languages, that will be used in the application, should be defined using languages
field.
languages:
- code: EN
name: English
- code: RU
name: Russian
Each Event API provider uses own AMQP exchange and algorithm to sign payload.
exchanges:
barong:
name: barong.events.system
signer: peatio
peatio:
name: peatio.events.model
signer: peatio
Using keychain algorithms and defined public keys for each provider postmaster will validate the data.
keychain:
barong:
algorithm: RS256
value: "public_key"
peatio:
algorithm: RS256
value: "public_key"
In events
you may define any event type from Event API providers and prepare email template for it.
events:
- name: Email Confirmation
key: user.email.confirmation.token
exchange: barong
templates:
EN:
subject: Registration Confirmation
template: Hello, {{ .record.user.email }}!
RU:
subject: Подтверждение Регистрации
template_path: templates/ru/email_confirmation.tpl
For templates
you can use either mount templates directly to container and template_path or use template.
Build the binary
go build ./cmd/postmaster/postmaster.go
Start your postmaster
./postmaster
Output:
XX:XXAM INF waiting for events
XX:XXAM INF successfully connected to amqp://xxxxx:xxxxx@localhost:5672/
Use official docker image for postmaster quay.io/openware/postmaster, which is automatically built on each commit in the master branch.
docker run quay.io/openware/postmaster --name=postmaster