We've now established that we really want to have a bundler inside of our application, but we want
our bundlers to work just slightly differently.
In particular, we want our bundler to try to find or import modules from NPM rather than trying to
find them on our users hard drive.
Remember, we want our users to be able to import any arbitrary module of any module that exists.
We don't necessarily want them to have to install these modules ahead of time or anything like that.
So to implement this step right here, there are three different possible solutions that we're going
to take a look at.
Let's start off with a possible solution, number one.
OK, so with option number one here for making this very small change to a bundler, we're still going
to have a react application.
We're going to eventually have some code that we want to process and eventually execute.
We're going to send that code to some backend API server that is going to be running Webberley.
We're going to run Westpac eventually, Westpac is going to try to process this code that's been sent
and it might find an important statement for something like React Axios, Lodish or whatever else,
some kind of module that might not be installed locally on this back in DPI server.
At that point in time, normally Westpac would throw in er, usually Westpac, there was an error if
you tried to import a module that is not installed locally, however, we can override that behaviour
by using a little plug in.
A plug in is a small piece of code designed to change the way that Westpac works ever so slightly.
So when the solution, we're going to rely upon a plug in called the NPM, install Westpac plug in.
Let me show you the documentation for that very quickly.
I'm at the Web site documentation, I'm looking at the documentation specifically for the NPM install
Web plugin.
So as I mentioned, whenever Web Jack is bundling your code, if it finds an import statement for a
module that is not installed locally, usually Westpac would throw an error.
This plug in is going to slightly change that behavior.
Rather than throwing an error, it will automatically install this module directly from AMPM onto your
local machine or in our case, our API server, and then allow Watpac to continue on with a bundling
process, as usual.
So this would definitely solve our whole issue any time -- runs, whenever it finds an important
statement for some missing module or module that we don't have on this back in API server, that plugin
will kick in, go and download that module from the registry and then continue on with a bundled process
and eventually send over all the bundled code back to the react application where we can actually execute
it and the user would see some result on the screen.
So this would definitely work, there's no two ways about it, but something about this approach.
I'll be honest with you, just doesn't quite feel right.
The reason for that is that we are essentially saying that we're going have a back in DPI server here
that is going to just be installing module after module after module over time.
We're definitely going to install and save these modules locally.
So they're essentially going to be cached.
But every single time someone asks for a module that's never been downloaded before, are back in server,
is going to have to go and download that module.
So we eventually are back in the API is going to have a hard drive that is just dock full of tons and
tons of installed modules.
So even though this would work, something about it just doesn't quite feel right.
So with that in mind, we're going to take a look at two other possible solutions that are mostly designed
to kind of get around this issue of saving these dependencies locally, which is what this plug in is
going to do by default.
OK, so option number two, option number two is just about identical in nature, we're still going
to have some kind of back and API running Watpac or something similar.
Anytime Watpac means an import statement, you and I are then going to kind of intercept that import
statement by writing our own custom plugin.
So you and I could write our own custom plug in to say, hey, any time someone tries to import something
such as React, Lodish, Axios, whatever else, you and I can make a request ourselves off to the NPM
registry.
And maybe if a user is trying to import react, we would get the source code for react and then return
it and pass it back to WABAC so that it continue on with the bundling process.
So this is essentially identical to this previous option.
Number one, the only difference is that we're saying that we're not going to actively save this dependency
onto our local machine.
Instead, we might decide to just reach out every single time to the registry somewhat.
Some whenever someone tries to import reactant to their little snippet of code, we could definitely
try to cache this result and make sure that we're not just always downloading the same file over and
over again.
But essentially, at the end of the day, we're just saying we're not going to install react as an entire
big heavyweight dependancy into our backend API.
Other than that, everything is pretty much similar in nature.
So once we give that file off to WABAC, Bundall gets completed and sent back over to the REACT application.
So this would definitely work.
This is definitely a viable solution.
And I think that, well, we could definitely try to implement this.
But before running off with this solution, I want to take a look at one other possible solution as
well.
So option number three, with option number three, we can once again make use of Watpac, maybe write
some kind of custom plug into an individual file from NPM.
What in this solution we're going to implement all this kind of web processing stuff directly into our
react application.
That means that we're not going to have to make some kind of outside request to our API, which in theory
should speed up the process of running our users code, because now we don't need to make that entire
additional request.
In addition, another big upside to this approach is that now it would be a user's machine.
It'd be up to a user to reach out to NPM and download an individual file, as opposed to having tons
and tons and tons of requests coming from our server, our API server that you and I might have to put
together.
So option number two and number three are essentially equivalent in nature.
The only difference is where we are doing this bundling process.
Are we doing it on some API that you and I are putting together?
Where are we going to do it on the react application itself?
So at this point time.
Or problems.
Number two and number three, we've now got a couple of different solutions available to us, remember,
for the trans piling stuff, we had said that we could do the trans piling on the back end API as well,
or inside of our REACT application.
And now with this bundling stuff, we're saying, well, we could do this on a backend API or inside
of our REACT application as well.
So it seems like we're kind of at a crossroads here where we need to really make a decision and decide
do we want to implement all this stuff inside of some API that you and I would put together?
Or do we want to just build it all directly into our react app?
That's really the big question here.
And that's what we need to really figure out and decide in order to move forward with some implementation.
So let's start to weigh some the pros and cons between these two different styles in just a moment.