In the last video we took a look at exactly why we are seeing this really mysterious error message.
And each time that we are trying to fetch our current user during these server side rendering process
it's now in this video we're going to take a look at how to solve this problem.
So fortunately solving the problem is not going to be the worst thing in the world.
It's more just identifying the problem though is the big issue.
So we're going to have to kind of step solution here.
We're going to configure axioms a little bit differently.
We're gonna configure how axial makes requests definitely depending on whether or not we are making
the requests from the browser or from our next J.S. application if we are ever making a request from
inside the browser then we're going to configure axioms to use a base url of basically empty string.
So in other words we're going to continue to allow the browser to figure out the domain to make the
request to if we are running inside the browser because as we saw just a little bit ago there's no problem
with that whatsoever.
All we have to do is allow axles to do its usual thing or more specifically the browser to do its usual
thing of appending whatever the current domain is that we're visiting onto the URL that ticketing dot
debt for example.
So we find no issue whatsoever that requests did successfully get routed off to ingress engine X and
then eventually to our all service.
So again if we making the request in the browser we're not really going to worry about it too much.
However where we ran into problems was when we were making the request from the server side rendering
phase.
So there's two different ways of solving this when we are making the request from inside of Next j s
there's option number one And option number two so for option number two we're going to go in reverse
order here for option number two we can somehow tell axioms or something inside of Next j s that if
we are running inside of next if we are running the code during server side rendering let's make sure
that we put on the domain of that auth service that we're trying to reach out to.
Remember this is a little bit of travel trivia back and we are putting together all that Uber neti stuff
if we go and take a look at our off depot file we had created that cluster IP service and we gave it
a name of off dash as Savi and that meant that any other pod or anything else inside of our cluster
specifically can access this service and therefore the pod that it governs access to by trying to go
to HD GDP off dash SRB.
That means that from inside of our next j ust application we could make a request to off dash SRB and
communities would make sure that that request was forwarded on to eventually our service.
Now remember right now I'm using that term service somewhat interchangeably between the context of micros
services and the Cuban 80s worlds.
Remember that in communities service refers to a cluster IP service or a node port service.
Again kind of using that term interchangeably right now.
But the point is we can essentially just tell our next application to make requests directly over to
the service now I'm going to say that this is not a very good option because this implies that our ReACT
client code is going to know the exact service name for every different thing it's ever going to want
to reach out to.
So if we start to introduce other services we're going to have to encode those exact service names into
our ReACT application.
And that's just a little bit of a nightmare.
The other problem is that we need to somehow know not only those service names but also which route
corresponds to which service.
So we might.
Right now it might be really easy just look at this entire year El and say oh we're making a request
to some users end point.
Well that's probably tied to the service.
But what if some point time we need to make a request to some mystery service like API slash fruit would
we just naturally know that we need to make a request to some other service name fruit.
What if it was actually managed by like some produce service or something like that.
So not only do we need to know the service names we also need to know which routes correspond to which
services fortunately all that information has already been encoded in another location.
We've already set up all that information inside of ingress and connects.
So rather than using option number two and having our client reach directly out to our service we're
going to go with option number one.
We're gonna say that in time we need to fetch data from a service inside of our communities cluster
we're going to have our next J.S. application reach out to an ingress engine X which is already running
inside the cluster ingress engine X can then figure out where to send this request off to based upon
just the path by itself.
So all we have to do is say hey ingress engine X I'm trying to make a request to API users current user
and ingress engine X already has the set of relevant rules and we put together right here.
It knows how to take a request to some arbitrary endpoint and map it up to some service and some actual
port.
Now there's just a little bit of a challenge with this approach for option number one and that is what
domain.
How are we making the request to how do we somehow reach out to ingress engine X while we are inside
of some pod we can very easily reach out to ingress engine X from our local machine by just making a
request to local host port 80 or as we have set it up ticketing dot Dev that's going to forward the
request on to ingress engine X but how do we do that same thing when we are already inside the cluster.
So that will be something for us to figure out we need to figure out how to make a request directly
to ingress engine X when we are inside the cluster that's a little bit of a challenge to figure out.
There's one other little challenge as well.
Remember our entire authentication mechanism right now works based upon cookies.
And so as we're talking about somehow fetching the current user we need to keep in mind in the very
back of our head that we have some requests coming into our next as application and it includes a cookie
and at some point in time we're going to make a follow up request from inside of next and that follow
up request is probably going to have to include that cookie information right now back inside of our
index dot J ust file when this gets executed on the server or inside of next we do not have access to
the browser to automatically manage that cookie or anything like that.
This line of code when it's executed in a no j ust environment doesn't care about cookies.
Cookies are the last thing that it could possibly care about in the world.
So we need to figure out some way to make sure that we make this request from next J us.
We take a look at the original incoming request we extract that cookie off there and include it in the
request off to ingress engine x so that when this request finally gets routed through ingress engine
X over to the all service and I like that right there the all service will see that incoming cookie.
All right.
So as you can tell.
Yeah.
This stuff is kind of crazy pretty darn complicated.
As I mentioned last video this is really all why I wanted to take the server side rendering approach.
I want you to see some these challenges around making requests to other services from inside of our
cluster.
OK so we got our work cut out for us.
So let's take a quick pause right here and continue in just a moment.