We've now got Napster and server up and running inside of our Cuban 80s cluster.
In this video I want to give you a quick overview on how Napster and server differs from that custom
event bus we had put together back in our first application.
We're going to focus on some high level items and then immediately after that we're going to start to
work on a very small little stand alone project to get a better idea of how we interact with that streaming
server and some of its different properties.
So let's get to it.
We're going to take a look at a couple of different diagrams in every one of these diagrams.
I'm going to show you something that our custom event bus we had previously built did.
And then we'll compare that to how that streaming server behaves.
The first thing I want to think about is how we communicated events between different things with that
custom event bus we had previously built.
So with the custom event bus we might have had some service that would build up and events and then
we use axes to make a post request directly over to that customer event bus the customer event bus was
running a copy of Express so it listens for incoming post requests it would receive that event and then
internally take the event and make its own post request using axioms.
Out to some other service inside of application and those other services were running their own copies
of express that would listen for incoming events so this was a very simplistic approach where we basically
relied upon the libraries of axles and express that was pretty much it now that we are using that streaming
server.
However we're not going to be using express or axles to share events around our application.
Instead we are going to use a client's library that is specifically designed to work with that streaming
server the client library that we're going to use is called node that's streaming.
Let's take a look at the documentation for it on NPM.
Right now I'm going to open up a new browser tab and navigate to NPM J.S. dot com once here.
I will look up node that's streaming
here's the documentation for it.
Now there's a lot of stuff in here that is just chock full of information.
There's a lot of stuff going on inside of here and unfortunately whereas a lot of libraries out there
you can kind of just skim over it and say oh yeah I know what's going on and then reference it in the
future anytime some specific problem comes up.
Unfortunately with this library and that streaming server it is kind of important to understand the
internals or how this stuff is really working from the get go.
So that's why we're going to do a little stand alone project to work just with Nat string server by
itself and not worry about any services or communities or anything like that.
We're going to have this little standalone project just we can understand these very important internal
mechanics they're going to be critical for us to use to properly communicate data throughout our application.
The one thing I do want to point out around is documentation right away.
If you take a look at the basic usage section you'll notice that to work with this library we've got
a very event based kind of architecture so in other words if you're familiar with event emitter in no
J.S. or any other kind of eventing library where we emit events and listen to them in plain javascript
code that is really how this library works.
So we're going to create some objects we're going to setup event listeners and we're going to emit events
as well and all works with a very heavily callback based kind of infrastructure.
So unfortunately we are going to be relying quite a bit on callbacks with this library as opposed to
using async await or anything like that.
All right.
Back over to our diagram.
So we're going to do it like I said be using no net streaming to create events send them over to that
streaming server and then that streaming server is going to send those out to our different services
which will be listening for events.
Also using the known that streaming library we're not going have access or express dedicated solely
to handling events or anything like that.
We will of course still use axes or express for normal HDTV requests and so on.
I just mean to say that for all the event related stuff we're going to be using Node Nats streaming
OK.
Second thing here.
So with our custom event plus anytime we emitted an event that event was sent over to every single service.
So for example if we had our ticket service emit an event of ticket update event we received it on our
customer event bus and we sent a copy of it off to our order service and whatever other service.
Now of course we didn't actually have these services in our first application.
I just mean to say if we had used this custom event bus in our current app this is how it would work.
So we would receive an event and throw it off to every different service technically even the service
that had sent it to the event plus the technically an event or the same event went directly back to
the ticket service which was not super useful as your guests no doubt streaming is me very different
in nature that streaming is going to requires to subscribe to specific channels so a channel overall
is gonna use the term topic somewhat interchangeably.
These are essentially types of events or channels of events that we're going to be listening to specifically
inside of our different services.
So for example on that streaming server we will create a collection of different topics or channels
we're gonna use that term pretty interchangeably then whenever we want to emit some kind of event we'll
create it inside of one service we'll reach out to the node in that streaming library and we will tell
it publish this event to the ticket call an updated channel so that event will be emitted out of our
ticket service it will go over to this channel on no net streaming and then the event will be sent along
to only the services that are listening on that very specific channel.
So for example if our order service is listening for events on ticket colon updated then it will receive
a copy of this event.
What if some other service such as say payment service was not listening to that channel it would not
receive it.
So no longer does one event get sent everywhere.
Instead we have to specifically say you are the different topics or channels that we care about these
are the different topics or channels that are going to exist.
And we have to specifically subscribe to them inside of our different services to actually receive those
events.
All right onto the next diagram.
So next thing back with our customer event plus we have put together a memory store of sorts to store
all the different events that were ever emitted.
So for example if we had our ticket service emit an event again of ticket updated we would store that
inside of a in memory array.
It would of course also be emitted to all of our different services.
But we held onto a copy of it as well.
This feature right here was absolutely critical so we could handle temporary downtime of any given service.
If some service went offline for some a very brief period of time it could then come back online and
ask for a list of all the different events that had ever been emitted.
And so we can make sure that some service was down for some period could come back online and fetch
or retrieve all the data or events at administering that period.
This is also fantastic for any time we needed to add in a new service.
So for example if we decided to create a new service and add it into our application maybe in this case
we call it payment service the payment service could then reach out to the event boss and say hey give
me a listing of all the different events that have ever been emitted so we could then take our big list
of events send them all down and then the payment service or whatever new service this is would then
be magically and suddenly up to date with all the relevant data inside of our app so this idea of storing
memory or storing events somehow was really critical for handling outages or handling any new service
we pulled up as well.
Now streaming server has a very similar idea but it's way more complex and robust so with that streaming
server it's going to store all the different events to get emitted in memory by default.
However we can also customize it to store these events inside of flat files stored on a hard drive or
even inside of a database like my sequel or post grass.
So again for example ticket service could be met and events over to it that streaming server it'll be
stored inside of memory and simultaneously a copy of that event will be sent out to all the relevant
services.
If we then at some point time bring a payment service or some newbie service online it can reach out
to that streaming server ask for a copy of all the different events and that streaming server will respond
with all the relevant events that it has missed out on so the same thing is true.
If we decide to store all these events on a flat file my single database or post press as well.
So I'm not going to go through drawing out the entire diagram.
I think you get the idea here if we met you met an event over time that streaming server we can configure
it so choose.
These events get stored inside of some file or database.
So now if our Napster in separate server ever goes off line or has to be restarted of course it loses
everything stored in memory.
What if we stored those events inside of a file or a database.
Then after the streaming server comes back line it could connect to that database or that file.
Take a look at it and say oh OK here's all the different events that have ever been emitted.
So that is it.
Those are some very high level notes on some critical differences between our event bus and that streaming
server.
The big ticket items here are that we're going to use this custom little client library called no net
streaming to communicate.
Next up with Nat streaming we have to create these things that are called topics or where else can use
the term channels for them and then our services have to split it specifically subscribe to events from
these specific channels and then finally very similar to our custom event plus we can have that streaming
server store all these events in memory or alternately stored them inside of a file or database as well.
That's what we understand Sony's very core differences.
We're gonna take a pause right here and then start writing some code in the next video.