In this video we're going to focus on how to build out this shared library.
We're going to first take a look at how we can somehow share code between multiple different services.
We're going to outline three different ways to share code between the OSS service and a ticket service.
Now just be clear.
There are more than three ways to share code between projects.
But we're going to be mostly focused on these three different methods.
So meet the number one for sharing code between two projects is to just do a very direct copy paste
so we can go into our all service we could find all those Middleware is all the custom error handling
stuff and so on and do a direct copy paste of that code over to this new ticket service we're going
to put together.
There's definitely a very big downside to this approach.
If we start to copy paste stuff over we might then go back over to our auto service and start to make
changes to this common code.
And so maybe we are now on version two over here.
How would we know what files change.
How would we somehow get those files sync over to the ticket service.
We would have to do a direct copy paste again.
And when we did that direct copy paste it might be really challenging for us to keep in mind exactly
what changed.
So it's kind of hard to document these changes over time.
I think you can probably we don't really need to spend a lot of time on this.
I think you can probably kind of instinctually sense that doing a direct copy paste this code between
projects is probably not the best way to do any kind of code sharing.
So I just want to mention it but we're not really going to consider this as a serious option met the
number two is to use what is called a get sub module if you are familiar with get then you might have
heard of some modules a sub module is whenever we have one get repository and we want to somehow include
another get repository inside there.
So we might create a get repo for our auto service and our ticket service we then create a third repo
for all of our common code we would then add in this common repo into our off and tickets repos as a
sub module.
And so you can imagine that we kind of take a copy of this thing
and put it directly in right there and right there.
Now the upside to this approach is that we have all of these common code inside of version control and
so we know at all times exactly what version of the common code we are running between these two different
projects.
We also have some really solid documentation on what gets changed between different versions.
The downside to this approach is that using get some modules in general is just a little bit challenging.
There's some different complicated commands.
Whenever you create a new get rid repository setting up some modules is always a bit of a pain.
And so this definitely is a valid option but there's just a little bit of pain associated with it.
So third option we're gonna take a look at is publishing all this common code as an NPM package.
This is what we are going to do.
We're going to take all this common code we're going to move it into a new project.
We're then going to publish this as a package to the NPM registry.
So we might give it a name of something like get ticks stash common or something like that.
Then inside of each of our different services that need this common code we will simply install it as
a NPM dependency using that same kind of NPM install command.
You are already familiar with the nice thing about this approach is that we can still version the code
inside this common repository or this come library so our auto service might use version 0 0 1 of this
common library and a ticket service might use say version 0 0 2.
So if we ever start to make a change to this get ticks library no problem we can still have all of our
other services using the older version until we eventually get around to making updates and adjusting
them and saying okay let's now use version zeros or two over inside the out service so we're going to
use option number three right here.
Now this definitely solves a lot of issues but there are some really big downsides.
This means that any time that we want to change our common code we're going to have to make our change
push it up to the NPM registry then go over to our different services and update our version to the
latest.
And that's just kind of a tedious process.
We are going to eventually write out a little script that's going to kind of automate some of stuff
for us.
But I just want to point out that it is a little bit tedious and there will be times where we start
to write some code in an update to this common repository or it's come library and then we will publish
it.
We will update our ticket service with the newest version and then we'll say oh my gosh we just made
a little mistake.
So we'll have to go back over to this library make the update rebuild it push it again update ticket
service again.
In other words there will be times where it's a little bit of a pain but this kind of has the best of
all different options.
OK so that might.
Another quick pause right here in the next video we're going to go ahead and create this common library.
We're going to start to set it up as an NPR module and then start to move all of our common code over
to it.