Let's get a quick reminder on some different aspects of these listeners.
The person we're gonna focus on is the cougar name.
Let's take a look at a quick diagram OK.
So in this diagram we've got some publisher up here on the top left hand side.
That's going to be eventually published an event up ticket created on the right hand side is our net
streaming server and we're listening inside of our two instances of the order service to some channel
called Ticket created when these two order services connected to this channel and created a subscription.
They joined a Q group called orders service by being a member of this Q group that ensures that any
time an event comes into this channel this event is only going to be sent to one of the members inside
this Q Group.
So the entire idea behind this supposed to make sure that we do not have our different services all
independently processing the same copy of this event at the same time.
So instead the Q Group makes sure that this event is only going to be sent to either order service a
or order service.
The only requirement of the Q Group identifier right here is that it is unique for all the different
services that are going to create subscriptions inside this channel number one and number two it must
stay consistent over time so we should not try to randomly generate a Q Group name or anything like
that.
Now the Q Group Name is one of those little variables or properties right here that's really easy to
make a typo on.
So at some point time we're gonna create another listener inside of our app let's imagine that it's
some other listener inside of some other file and when we did so we would have to define this Q Group
name another time or second time would be really easy for us to actually make a little typo here.
Maybe we call it order service or maybe we call it order service without a dash or maybe do a slash
instead or a colon or whatever else.
And so usually rather than defining the Q Group name as a string directly inside the listener we might
be a little bit better off if we define the string somewhere else instead of a project just one time
and then import that value into our project or something into this listener file so let's try that right
now.
Let's declare a Q Group name and a separate file and then imported into this file again just so we avoid
making any typos inside of my listeners directory that we just created.
I'm gonna make a new file of Q Group name dot t s then inside there I'm going to export a concept of
Q Group name and I'll hardcoded value to orders.
Service does save this file.
Pull it back over to our listener at the very top.
I'm going to import you.
Group Name
from Q Group name and now I'll reference that variable right there instead of this hardcoded string
though.
Q Group name.
So again just avoiding little typos.
OK so let's get a quick reminder now about this data property coming too on message.
So remember we had said that we're going to create an interface to describe all the different events
that are going to be flowing throughout our application.
In this case that interface we created was the ticket created event interface.
We could do a command click on ticket created even anywhere inside this file or a control click through
on Windows.
And it should take us to the definition of that interface so all of our event interfaces had the subject
property and the data property and data was describing the different pieces of data that was going to
be contained inside this event.
So to make sure that we applied some type checking on the data flowing into this on message function
we reference the event type interface and then we're saying off that interface.
Take a look at the data property and that's going to be the type of this data argument right here then
finally last little reminder is this message argument as a second argument.
So what is the message.
Well remember this is an object coming from the node not streaming library.
The message thing is something that tells us about the underlying data coming from the known out streaming
server.
But most importantly for you and I absolute bar none.
Most important thing about it we do a command click on message and go to the type definition you might
recall.
This thing has a method of EQ and that was what you and I really really cared about.
We call EQ when we have successfully processed a message or an event and that is a signal to note that
streaming server that we have process this event and it does not have to worry about trying to send
it off to another copy of our service again.
So after we successfully process any event inside of our different listeners we're always going to finish
up by calling back.
Now the keyword here is successfully process.
So I guess the keywords successfully process only when we successfully process an event do we call ach.
Otherwise if there's some kind of error or something like that we usually it will not be calling EC
because an error will usually indicate that we want to try to re process this event again and we would
do that by just not calling Ach that would cause our event to time out after a couple of seconds and
that string server is going to try to take that event and send it off to another copy of our service
for reprocessing.
All right.
So hopefully that gives you a really good reminder on what's going on inside of our listeners.
Again we're going to be writing on the same exact code again and again and again moving forward for
all these different listeners.
Just really important that you keep the definitions of all these different things in mind.
All right sounds good.
So let's now take a quick pause.
We're going to start to implement the body of our on message function in the next video.