All right, my friends.
Time for the Big Reveal, let's talk about how we're going to actually implement all these different
parts of our project, so.
We are going to develop each of these major parts of our project as standalone NPM packages, so that
means that for our Seelie that we're going to eventually put together, we're going to create an NPM
package called simply Chibouk.
This will be an NPN package that can be very easily installed on a user's machine.
We're going to create another package called at the local API.
That package is going to contain all the code, all the implementation needed for our local Express
API.
Remember, we are not actually going to build this public version of our Express API, but I'm going
to leave it on these diagrams just as an example.
So if we're building this, we would create another package called JDBC Public API.
And then finally our entire REACT application.
We're going to package up and deploy inside of an NPR module called JDBC Local Client.
So for the rest of this video, we're going to talk about some big benefits of taking this kind of approach.
What we really gain by wrapping up each of these little pieces of functionality inside of an NPM package.
But here's the first very big benefit we established in the last video that there are these kind of
very tenuous connections between each of these pieces of functionality.
So if we develop each of these as a standalone and package, then we can very easily add in each of
these to another sub project as a dependency.
So, for example, our ally needs to launch the local Express API.
So the Seelie has a dependency upon that package so we can create the Seelie and say that it has a dependency
of local express API and then specify what version of that package we want to use.
The local Express API, in turn, depends upon our REACT application so we can install the React app
into our local Express API and specify exactly what version of our REACT application we want to use
as well.
If we were developing the Public Express API, we could also very easily consume the reactor application
from there as well.
So now we can start to see that we've got the standalone reactor application right here.
It can be very easily consumed by as many other parts of our application as we want.
And in turn, each of these parts can be consumed by another part.
And for each of these different dependencies, we can always precisely specify what version we want.
So, for example, if we start to develop our REACT application and add in some new features to it that
are only applicable to, say, the local Express API or the local version of our application, we could
tell the local Express API to use that newer version.
And we can just say, hey, you know what, Public Express API, you don't really need to be making
use of this newer version just yet.
So just stick with the version you have.
So this will allow us to version out each of these different major dependencies of our projects.
The next big benefit to this is that we can very easily start to do three factors and extract logic
that is similar between our different packages.
So, for example, our local Express API and the public one, those both need to have some understanding
of what a cell is, because remember, part of the idea here is that both those APIs would eventually
store a list of cells that belong inside of some notebook.
So we might eventually decide to take all of that kind of cell handling logic and extract it into a
new separate package, we could then very easily share that package between both versions of our API,
both a local one and the public one.
Another big benefit is that if we have, say, our react application or really any other part of our
app and we realize that there's some really interesting part of this application we put together, we
could very easily extract that into a separate package as well and then deploy that as a separate package
and maybe even open source.
It is a really good example of this is inside of our REACT application.
Remember, we put together all that logic around our bundler.
That's all inside the bundler directory right now.
This folder is completely standalone.
It does not import anything else from our entire project.
And the code inside of you is actually really interesting stuff.
Everything we put inside, if you're around doing some bundling inside the browser.
This is very I can't stress it enough.
This is very original work and there's not really many prior examples online of doing bundling inside
the browser very effectively.
So we might decide that we want to take this bundle everything right here and share it with the rest
of the world so we could take just this bundler directory, extract it into a separate little sub project,
rate that as a module deployed off to NPM, publish it on GitHub and open source it and say, hey,
if anyone else wants to make use of this bundling thing or make improvements to it, there you go.
And then we can very easily import that separate bundler package back into our REACT application.
Yet another big benefit here, and this one is a little bit more obvious, if we are looking at a larger
company, we can much more easily have different teams, manage each sub project.
So we might have one team or just one engineer in charge of the local Express API, another one in charge
of the public Express API.
We have a front end team in charge of the reactor application by itself and maybe just one engineer
in charge of the CLI or maybe the Seelie just never really gets touched because maybe it just just doesn't
change that often.
One last big benefit here, just in case you're kind of worried about this, if we ever have a package
that has some really sensitive business logic inside of it, it's absolutely trivial to make sure that
that particular package does not get shared with the outside world.
So, for example, our public Express API and remember, the word public here just means that it's accessible
by anyone.
Once it is deployed, there might eventually be some code inside there that is very sensitive.
So some code around authentication or something like that, we might want to make sure that no one else
can very easily see that code.
So we can very easily mark this package as private so that it is not publicly available on NPM for just
anyone out there to download and install.
That's going to make sure that nobody can just very easily take a look at the code inside of our public
API.
So this is pretty much it I've outlined a couple of big benefits to this approach, obviously this approach
is extremely complicated.
It is way more complicated than just adding in a little bit more code to our REACT app application.
But there are many just incredible benefits to this along the way.
So with that in mind, just a very quick disclaimer here.
First off, once again, I want to repeat it just one more time.
We are not going to be building that public express API part.
That is just an example of how we might expand this application in the future.
And if we were building that, using this multi package approach would be absolutely invaluable.
Second thing, just another very big disclaimer here, the approach I'm showing you here is very overengineered.
It is way more complex and needs to be, especially because we are not putting in this public express
API part.
So it is overengineer just keep in mind it's going to feel very often like we are doing a lot of extra
work without a lot of benefits.
And that is true.
We really are doing a lot of extra work here, way more than we need to do for this particular application
as it stands right now.
The reason we are taking this approach, the reason we are doing everything way more complicated is
because, well, this is a course and so in a course, I can very easily give you a lot of tips, a
lot of guidance, a lot of direction on the best way to do these things.
So personally, I think it makes a lot more sense for me to show you the more complicated approach here.
And, of course, because I can give you all this extra guidance right away as opposed to you trying
to implement this kind of thing on your own project and just being a little bit more having a harder
or tougher time doing it.
So the whole reason I show you this diagram right here is really to just highlight that a lot of stuff
is going to be very complicated.
And I just want you to understand, yes, it is complicated.
It is more complicated than it needs to be.
Just keep that in mind.
OK, so now that we've got the general idea here, obviously the question very quickly becomes, well,
how are we going to set up all these different packages and how are we going to do any kind of local
development on them?
How is this all going to come together in any practical way?
Well, of course, that is the next very big question.
So let's take a pause here.
Take a look in the next video at a couple of diagrams and understand exactly how we're going to manage
all of these different projects.