The last big thing we need to do inside of our cluster is integrate that react application.
This is going to be one of the last big topics to cover around communities.
I know all this Cuban neti stuff has been a little bit of a slog but we are almost at the end and I
want to repeat just one more time that even though doing a lot of stuff by hand is kind of annoying
little bit tedious after we get through this last topic we're gonna start to look at a tool that's going
to automate a lot of this stuff for us and make our lives a little bit easier.
All right.
But that might.
Let's take a look at how we're going to get that react application inside of your so our ReACT application
is actually the create react app development server.
We're going to house this thing inside of a pod so we're going to create a new Docker image or our ReACT
application or the development server.
We're then going to create a container inside of a pod and place it inside of our cluster.
One thing I want to clarify about what this react app dev server does is that whenever a user opens
up their browser and navigates to our application we're going to really be attempting to connect to
that react app dev server.
The only goal of that dev server is to take code that you and I write inside a very act application
and then generate some H T mail JavaScript in CFS files out of it.
So during the initial navigation attempt to our application running inside this cluster the only thing
that's react app dev servers doing is returning some HMRC SS and JavaScript what this react app server
is not doing is making any requests at any point in time over two posts over two comments.
Query anything like that.
The actual requests for data are being issued from the user's browser so we send over that HCM LCROSS
and JavaScript stuff.
Then the react app boots up inside the user's browser and then inside of the browser the react app is
going to try to reach out to the query service and get some posts and comments.
After serving up the initial T MLC SS and JavaScript stuff the development server it is no longer relevant
whatsoever.
So no requests are being issued from that dev server directly over to our other pots.
All these requests are coming from the browser.
So this starts to open up a kind of interesting question how are you going to make sure that the react
app can somehow make requests to all of these different pots.
We need to reach out to at least the query service comments and posts react that doesn't technically
need to reach out to moderation but whatever.
Let's forget that for just a second so to make sure that the react app can reach out to all these different
pods and the containers running inside them.
We have two options available to us.
One option is going to be pretty bad and we're definitely not going to do it.
I just want to show you this option Make sure you understand that we're not going to do this in any
serious application.
So here's possibility number one.
Probably not good.
We don't want to do this.
So option number one to make sure that the react application can reach out to these different pods.
We could create a node port service or post comments query and moderation.
Remember that a node ports service is going to expose a pod to the outside world or to traffic outside
the cluster.
So inside of a react application we could write out some code that would make requests to these different
node port services and access the underlying pods to get all the information that is required.
The reason that this is not a good approach is that remember when we create a node port service we are
essentially opening up a random ports.
We can't technically specify an exact port but more or less.
Let's just say it's a random port inside of our cluster.
And so if we ever changed a node port there's the possibility that who knows maybe the port that we
get assigned would be different.
And so if we ever start to change these ports we would have to go back to a react application and change
the port inside of our code and updated to reflect the new node port.
So this is probably not a good option for that reason and for a couple of others as well.
Rather than trying to expose all of our pods using Node ports we're going to take a look at that last
kind of service that we had discussed in the previous set of videos around services in general.
So this is what we are going to do.
This is what we're gonna do in production environment in a development environment.
This is the right way to do this stuff.
We're going to create a load balancer service.
The goal this load balancer service is to have one single point of entry into our entire cluster.
We're then going to make sure that our ReACT application is going to make requests to access that load
balancer service and then we're gonna place some logic so actual code or configuration inside of this
load balancer service that's going to take these incoming requests and then route them off to the appropriate
pod and just be clear when I say it read it off to the appropriate pod.
Once again what we're really reaching out to is the cluster IP service.
We're going to create for each of these different pods so the react app is gonna reach out to a load
balancer request gets forwarded onto the appropriate pod response comes through the load balancer and
back to the react application.
So this is all going to be around really this load balancer service we do of course have to go through
writing out some more configuration building another image and so on from the react application that's
gonna be a pretty small part where we're really focused on.
Here is this load balancer service.
All right.
So now we've got an idea of what we need to do.
Quick pause right here and we'll get some notes on this load balancer service and the general strategy
in just a moment.