I think this little test with Nat streaming server and putting together this little test project has
had some pretty good results.
So we've now got this space listener base publisher we got the listing of all of our different subjects.
We've seen how to create a event that described some message We're gonna send out and how to create
the custom look publisher and listener as well.
So at this point we're gonna start to wrap things up and move forward.
But I do want to do a very quick summary and really touch on two items really quick.
So first off thinking about how to test these things we think about testing the publishers the publishers
themselves are actually rather similar to making a plain network request.
In other words it's rather similar to using something like axioms we're essentially using this class
to make a requesters with some information.
There's not really going to be a lot of business logic inside these.
And so we're not really going to focus a whole bunch on how to test them listeners.
On the other hand are a totally different story.
The listeners we put together are going to receive events and the assumption here is that we're going
to do a lot of business logic or processing on these incoming events in that regard.
These listeners are actually similar in nature to request handlers and we're definitely going to want
to do a lot of testing around the listeners we put together and make sure that we handle everything
inside them correctly.
So we will be spending a lot of time to figure out how to write some tests effectively for a listener
game.
One other quick item at this point I just want to highlight that we have centralized a ton of information
into our common module the common module is now going to be the primary source for where we define 11
different event names or remember what they are called in the world of Nats.
They are subjects inside of here we also have the exact definition of what all of our different events
are going to consist of.
So the subject for each of them and the data that these events are going to contain.
We are not going to define any events whatsoever inside of our different services.
Instead we are going to import them from this common module and this is going to absolutely positively
ensure that all of our services are using the same event names and the data inside of them will always
be consistent now.
Quick side note kind of like a higher level note here.
When I was first putting this course together I worked on this course for a extremely long time at this
point a very long time and the vast majority that time was actually evaluating different options on
how to put this common module together.
And when I was really thinking about building this course and going through all that work I thought
this section where we were talking about building out this customer then handling stuff in the common
module was going to be like a huge deal and it ended up being just about 14 videos or so I'm kind of
shocked at how things actually turned out.
Anyways back on topic here the reason that's really relevant is that I really can not understate how
important it is to put the definition of all these events and these event names into some common location.
It is simply not feasible to only define these events inside of your services because as I've said several
times you are going to make typos on event names and you are going to make typos on property names as
well.
It is guaranteed I 100 percent guarantee it if you try to define these things directly inside of your
services.
And that's why putting it all inside of some common module is so so helpful I almost wish that we hadn't
put the coming module together from the get go so we could have experienced the pain of having to guess
these property names and have to go look them up back and forth and all that pain I think would have
given us a lot more appreciation for defining the events inside of here.
Now I do want to say there is a downside to this approach.
We are writing typescript code putting these event definitions inside of a typescript module.
So naturally this whole approach right now is only going to work if all of our different services are
written with typescript.
If we have some other service using Java or something like that.
Well this shared definition of what an event is is not going to be quite so useful.
If you do expect to have services with other languages being used inside them and you don't expect to
be able to use some kind of common module all written typescript there are a couple of options.
So if you want to have a common definition of all the events the information inside them and shirt inside
of some kind of Polygon architecture you can take a look at some other alternatives such as gate Jason
schema Jason schema allows you to define Jason structures the different properties you'll have the different
values they'll have and some validation around those properties.
And this can be done in a cross language way.
In other words lot of languages have support for Jason schema so you can write your Jason schema inside
of some kind of a common repository.
So maybe I get hub repo or some like that so you can easily work with it between different languages
and then each year different services can pull in those Jason schema files and use them to validate
events that they're trying to publish another alternative is print above wrote above is a way of serialized
information not unlike Jason but it compacts information to much more compact formats heard above can
be used to define the structures also has cross language support.
Finally there's also something else called Apache arrow.
This is really themed around Java in particular but there is support for a variety of different languages
as well.
It's just not as strong as the Java focus side.
So again if you do expect to have some multi language services inside of your application rather than
doing a common module with TypeScript and putting the event definitions in there you might take a look
at these approaches just you know I did originally kind of try to design this application using Chase
on schema.
I also did a version of it with proto buff as well.
Neither of them were anywhere near as usable as the typescript implementation.
We ended up with.
So I showed you the type curve solution because I really did believe it was a very good way of handling
this and avoided a lot of headaches so we would have ran into if we tried to make use of Jason schema
or protocol.
So just throwing that out there.
All right.
So enough this pause right here.
Last thing we're going to do we're gonna take a lot of logic out of this little test project.
We're going to relocate it to our common module.
We're then going to rebuild it republish it and then update the common module inside our ticket service.
We're then going to go backwards to the tickets world.
We're going to make sure that we start to publish events whenever a ticket is updated or created.
So still a little bit of work to do.
Let's get started in the next video.