All right if you're still here watching this video I'm going to assume that you want to go through the
up process and run all of our code in a development environment using Google Cloud which is going to
unequivocally solve all of our performance issues let's first get started with a quick overview of how
we are running communities on our local computer right now and how we're going to run it through Google
cloud.
This is a diagram of what's going on on our machine at present.
We got your computer.
We are running a single Cuban 80s node now on there.
We could possibly have many different pots.
At present we probably only have one pod that authentication pod but eventually we're gonna have many
different pods.
We can open up our browser and access that node using the ingress engine X server we just configured
in the last couple of videos.
So that's what's going on right now.
Here's what's going to happen once we start to move all this stuff out to Google cloud your computer
is still going to be running say a browser or something like that trying to access our different pods
and test out some code manually.
But our entire communities cluster is going to be running on a Google Cloud virtual machine.
So no longer are we going to be running Cuban ads on your computer whatsoever.
Instead we're going to leverage some remote computer.
So we're gonna have a node somewhere out on the cloud that's running all of our different pots.
Now the reason this starts to get really relevant is that you have to really understand what scaffold
is doing for us.
You see scaffold is going to be the real tool that's going to allow us to set everything up on google
cloud very very easily.
You might be curious why we're using Google cloud at all by the way as opposed to NWS or something like
that.
Well scaffold was actually developed by teams at Google.
So scaffold has a very very tight integration with Google Cloud in general.
That's why we using Google Cloud in particular.
All right.
So here's what's going on behind the scenes with scaffold.
We're going to add in some additional configuration to scaffold and tell it that we wanted to use some
node hosted on Google cloud as opposed to a local node on our machine scaffold you might recall is not
only going to create all of our different services and deployments and all that stuff it is also in
charge very critically of handling changes that we are making to our project as well you might recall
that there are two types of changes that we can make to a file or a project when we're making use of
scaffold.
We either make changes to a file that is syncs or unsafe.
So if you go back over to our scaffold config file right now we listed out the sync section right here.
And this meant that any time that we made a change to a file matching that pattern just take that file
and sync it with a corresponding pod inside of our cluster.
So in that scenario we were not rebuilding any image or anything like that.
We were just taking the change file and sticking it directly into a pod so this diagram is laying out
that scenario the case in which you make a change to a sync file so on your computer you're going to
be writing inside of your code editor and at some point time you're going to change a sync file.
So in our case again that's going to be a typescript file.
Then whenever we save that file scaffold will detect that change scaffold will then be configured to
reach out to Google Cloud to reach out to the node that is running this specific pod and take that change
file and stick it directly into that pot.
And that's how updates are going to be processed now scenario two where we change a knot sync file is
a little bit more complicated and that's the real thing I want to show you with these two diagrams.
I want you to understand what happens when we make a change to a file that will not be automatically
injected into a pod so let's imagine that we make a change to say our package not JS on file when we
change that file.
It does not get automatically injected into a pod because we did not listed inside the string section
right here.
Whenever we make a change to the package not just on file that is a sign that we want to completely
rebuild our off image and then update some corresponding deployment inside of our cluster.
That would be at scenario number two where we change an unsinkable file so on our computer we're going
to open up our Ed and we'll make a change to a file that is not listed in the string section again something
like the package that JS on file scaffold will detect that and it's going to add in an extra step scaffold
is going to reach out to a service that runs inside of Google cloud called Google cloud build this service
is all about building Docker images to scaffold is going to take all of our source code for your project
that's going to upload it to Google Cloud bit built along with the docker file for that specific project.
Then on Google Cloud built some builder process is going to build our image for us the whole reason
that the image is being built on Google cloud it just so we decrease the number of resources that are
being consumed on your local machine.
In addition building the image is going to be a lot faster because Google Cloud servers have extremely
extremely fast internet connections.
And as you're going to see a little bit later on we're eventually gonna have a couple of projects or
subs projects inside of our project that have very large numbers of dependencies maybe not very large
numbers but we can have dependencies that require downloading something like 200 or 300 megabytes.
So if you are on a slow computer it might take or have a slow internet connection.
It might take you a long time to re download all those dependencies.
Anytime that we have to rebuild an image by making use of Google Cloud built you are going to be able
to install all those dependencies in a matter of seconds as opposed to possibly a matter of minutes.
So Google cloud build is going to be in charge of rebuilding all of our images once the image is rebuilt
scaffold will then reach out to the corresponding deployment on our node and tell that deployment that
there is a new image available the deployment will then restart restart all of our pods using the latest
updated image okay.
So that's it.
That's what's going to be going on behind the scenes.
So in the coming videos we're gonna do a pretty good amount of setup.
We're going to of course have to sign up for a Google cloud account.
We're going to create a project we're going to set up a Cuban entities cluster on Google Cloud.
We're going to configure Google cloud build we're going to configure it scaffold then to use google
cloud build and this remote cluster as well.
So it really is a pretty good amount of setup.
And again all this stuff is being done so that we can have a development environment running through
Google Cloud which in theory should be way faster than local especially if you're on an older machine.
So we really do have a good amount of work before us.
So let's take a pause right here and get started in the next video.