All right.
Let's go ahead and build out our two events.
So again we care about order created and order canceled to get started inside my events directory in
the common module.
I'm gonna find that subjects t s file inside subjects.
We got that you know that it's listing out all the different possible subject names or essentially event
names.
So we're gonna add in an event name or a subject of order created an order canceled.
Well put inside of your order read it is order a colon created
and order canceled is order colon canceled.
Good start after that.
I'm going to create two files inside this event's directory one of the order created events.
Yes I accidentally put a s on the very end there I can make sure I just fix that we will also create
order canceled event.
Yes just so you know the word canceled very easy to misspell.
So you've now written out the word canceled three times right here right here and inside of that file
that we just created as well.
I beg you please triple check the spelling of the word canceled in all three locations if you misspelled
canceled anywhere it's going to cause problems down the line.
Without a doubt.
All right.
So now we'll go back over to order created events.
We're gonna start to put together this event definition at the very top.
We will import these subject seen them from subjects will then export a new interface called order created
event then inside of here we're going to list out the subject which is subject start order created and
then some data that is going to describe the order that was just made and we could certainly throw all
the data from the order inside of here but let's go back and take a look at that PDA.
That describes the purpose of this event so that we can really understand what information we should
include inside.
All right so remember order created is going to go off two tickets payments and expiration.
Each of these different services need to know some very particular information about the order that
was just made to the ticket service for example needs to know the idea of a ticket that was just reserved
that the ticket service can lock down that ticket and prevent any further editing the payment service
on the other hand needs to know the user I.D. of whoever does create this order so that it can understand
who it should expect to receive a payment from.
It also needs to know the cost or the price of the ticket.
And then finally the expiration service needs to know the expires at time of the order.
So in total we really care about the ticket I.D. we care about the user I.D. and the ticket price and
then we care about the expires at time.
And technically this thing also cares about the order idea as well so that when that 15 minutes expires
or passes the expiration can service can emit an event and say hey the order with I.D. so and so should
now be marked as expired.
The only thing that all these services don't really care about when it comes to order is the status
of the order none those different services care about the status whatsoever and in fact even the name
of this event implies that its status should be order Cary or that the created status.
Now having said that even though none of our services really care about the status I'm still going to
include it anyways with the event because who knows maybe at some point in time in the future some other
service is going to come online and it's going to care about the default status of this order or something
like that.
OK.
So anyways for data right here we're gonna say that we're going to include the I.D. as a string the
status which is going to be wanted the order status in some options.
So we'll have to import our order status enum at the top as a quick reminder.
We've got that types directory inside there's the order status in them and that describes all the different
value statuses that an order can have then the user I.D..
So this is the person who created the order we care about.
Expires at and remember saved on the order or the order model it is a date.
That is how we are storing expires at inside of our database it is a date object but we are describing
something right here that's going to be converted into Jason.
So rather than saying that this order created event is going to have it expires at property that is
going to be a date object instead I'm going to say that it is a string because we're definitely going
to want to convert that data object into Jason or into a string manually.
So we can control how the time zone gets set.
Long story short for right now we're going to say that expires that is going to be a string.
And when we actually go and make use this you'll see why then finally we're going to also include information
about the ticket on here as well.
Going to embed it inside of an object so I'll say that this thing is going to have an idea that is a
string and a price that is a number and that should be it for now.
All right let's now go over and take care of order canceled so here's Order cancelled events at the
very top.
I will get my status first is not status but subjects from subjects file will then export an interface
of order canceled event will say that this thing is gonna have a subject of subject stored order canceled
and then in this case what data do we care about.
Well let's go take a look once again at that diagram and see what actually cares about order canceled
so order canceled.
We want that to go over to the ticket service and that means that the ticket service is going to need
to be told exactly what ticket idea.
We just need or we need to actually on reserve.
In addition this thing is going to go to the payment service and tell it that it should stop to or should
not expect to receive any payment or anything like that the payment service for this particular event
doesn't really need to know about the price or the cost of the ticket.
It really just needs to be told hey do not expect any payments for order I.D. so and so so in total
I think that the only data that we need to include here is the I.D. of the order itself and the idea
of the ticket that we are trying to unreserved with the ticket service so we could say ticket tickets
must be an I.D. is going to be a string.
Now once again we could definitely throw in a ton more information describing the order without a doubt.
We can include the user I.D. we can include the ticket price when this thing expires and so on but we
don't really have any need to share that information with any other service inside of rap right now.
This is kind of the point at which you need to make a decision on your own for your own personal app.
When you create an event do you want to just by default assume you're going to share the maximum amount
of information possible or do you just want to share the minimum.
In this case we're sharing the minimum amount of information to describe the order.
That was just cancelled because we know exactly what services are going to try to use this event that
about site about this approach or the downside is that we are not really future proofing ourselves.
There might be some point in time in the future where maybe the payment service does need to know the
price of the ticket that was embedded with this order if that happened.
If it turns out that the payment service does need to know that price well we would have to come back
to this order created event interface.
Just add on that tiny little price property and then republish this entire library so it's really up
to you.
Do you want to future proof your stuff and include as much info as possible or do you want to trim every
event down to just the bare minimum.
So again we're going to go with bare minimum in this case yet.
Let's say this now the last thing we're going to do go back to our index not TSA file inside our SRT
directory.
We're gonna make sure that we export both the events we just created that year.
Yes at the bottom will add on export star from events and then order canceled event then another one
for events.
Order read it event then save this and then finally we're going to update this module or republish the
module and an update the module inside of our order service.
So back at our terminal I will change into my command module I'll do an NPM run pub to republish this
it looks like I'm on version 16 right now.
You are probably on a way less version at this point.
As I said I sometimes rerecord videos I can't really use version numbers and that's why I'm a little
bit higher than you are most likely.
So now that I've published this thing as version 16 I'm going to go back over to my orders service and
inside of orders we'll do an NPM update.
And then whatever your common module name is.
So mine is SGI tickets coming and again yours is probably something very different
and after that runs I'm just gonna make sure that I see the 1 6 right there.
Yep looks good All right.
That's it.
Let's take a quick pause right here.
When come back the next video we're going to make sure that we eventually emit these events or publish
them from within our code.
Whenever someone cancels in order or creates an order.