1
00:00:00,470 --> 00:00:04,870
In the last video we took a look at exactly why we are seeing this really mysterious error message.

2
00:00:04,930 --> 00:00:09,290
And each time that we are trying to fetch our current user during these server side rendering process

3
00:00:09,480 --> 00:00:13,580
it's now in this video we're going to take a look at how to solve this problem.

4
00:00:14,100 --> 00:00:16,990
So fortunately solving the problem is not going to be the worst thing in the world.

5
00:00:17,000 --> 00:00:20,170
It's more just identifying the problem though is the big issue.

6
00:00:21,470 --> 00:00:25,080
So we're going to have to kind of step solution here.

7
00:00:25,100 --> 00:00:27,970
We're going to configure axioms a little bit differently.

8
00:00:27,980 --> 00:00:32,090
We're gonna configure how axial makes requests definitely depending on whether or not we are making

9
00:00:32,090 --> 00:00:38,060
the requests from the browser or from our next J.S. application if we are ever making a request from

10
00:00:38,060 --> 00:00:44,060
inside the browser then we're going to configure axioms to use a base url of basically empty string.

11
00:00:44,060 --> 00:00:48,440
So in other words we're going to continue to allow the browser to figure out the domain to make the

12
00:00:48,440 --> 00:00:54,290
request to if we are running inside the browser because as we saw just a little bit ago there's no problem

13
00:00:54,290 --> 00:00:55,970
with that whatsoever.

14
00:00:55,970 --> 00:01:01,880
All we have to do is allow axles to do its usual thing or more specifically the browser to do its usual

15
00:01:01,880 --> 00:01:08,880
thing of appending whatever the current domain is that we're visiting onto the URL that ticketing dot

16
00:01:08,910 --> 00:01:10,130
debt for example.

17
00:01:10,150 --> 00:01:15,800
So we find no issue whatsoever that requests did successfully get routed off to ingress engine X and

18
00:01:15,800 --> 00:01:18,020
then eventually to our all service.

19
00:01:18,020 --> 00:01:23,160
So again if we making the request in the browser we're not really going to worry about it too much.

20
00:01:23,180 --> 00:01:28,520
However where we ran into problems was when we were making the request from the server side rendering

21
00:01:28,520 --> 00:01:29,380
phase.

22
00:01:29,600 --> 00:01:34,510
So there's two different ways of solving this when we are making the request from inside of Next j s

23
00:01:35,330 --> 00:01:40,140
there's option number one And option number two so for option number two we're going to go in reverse

24
00:01:40,140 --> 00:01:45,810
order here for option number two we can somehow tell axioms or something inside of Next j s that if

25
00:01:45,810 --> 00:01:50,370
we are running inside of next if we are running the code during server side rendering let's make sure

26
00:01:50,430 --> 00:01:55,360
that we put on the domain of that auth service that we're trying to reach out to.

27
00:01:55,430 --> 00:02:01,520
Remember this is a little bit of travel trivia back and we are putting together all that Uber neti stuff

28
00:02:01,580 --> 00:02:07,560
if we go and take a look at our off depot file we had created that cluster IP service and we gave it

29
00:02:07,590 --> 00:02:14,220
a name of off dash as Savi and that meant that any other pod or anything else inside of our cluster

30
00:02:14,220 --> 00:02:20,910
specifically can access this service and therefore the pod that it governs access to by trying to go

31
00:02:20,910 --> 00:02:24,230
to HD GDP off dash SRB.

32
00:02:24,900 --> 00:02:31,640
That means that from inside of our next j ust application we could make a request to off dash SRB and

33
00:02:31,640 --> 00:02:36,260
communities would make sure that that request was forwarded on to eventually our service.

34
00:02:36,260 --> 00:02:41,320
Now remember right now I'm using that term service somewhat interchangeably between the context of micros

35
00:02:41,320 --> 00:02:43,070
services and the Cuban 80s worlds.

36
00:02:43,070 --> 00:02:48,110
Remember that in communities service refers to a cluster IP service or a node port service.

37
00:02:48,110 --> 00:02:50,080
Again kind of using that term interchangeably right now.

38
00:02:50,420 --> 00:02:54,920
But the point is we can essentially just tell our next application to make requests directly over to

39
00:02:54,920 --> 00:03:01,920
the service now I'm going to say that this is not a very good option because this implies that our ReACT

40
00:03:01,920 --> 00:03:07,170
client code is going to know the exact service name for every different thing it's ever going to want

41
00:03:07,170 --> 00:03:08,330
to reach out to.

42
00:03:08,340 --> 00:03:14,250
So if we start to introduce other services we're going to have to encode those exact service names into

43
00:03:14,250 --> 00:03:15,990
our ReACT application.

44
00:03:15,990 --> 00:03:18,300
And that's just a little bit of a nightmare.

45
00:03:18,300 --> 00:03:24,120
The other problem is that we need to somehow know not only those service names but also which route

46
00:03:24,450 --> 00:03:26,840
corresponds to which service.

47
00:03:27,120 --> 00:03:27,810
So we might.

48
00:03:27,810 --> 00:03:32,670
Right now it might be really easy just look at this entire year El and say oh we're making a request

49
00:03:32,670 --> 00:03:34,170
to some users end point.

50
00:03:34,170 --> 00:03:36,400
Well that's probably tied to the service.

51
00:03:36,510 --> 00:03:43,320
But what if some point time we need to make a request to some mystery service like API slash fruit would

52
00:03:43,320 --> 00:03:47,730
we just naturally know that we need to make a request to some other service name fruit.

53
00:03:47,730 --> 00:03:52,030
What if it was actually managed by like some produce service or something like that.

54
00:03:52,050 --> 00:03:56,070
So not only do we need to know the service names we also need to know which routes correspond to which

55
00:03:56,130 --> 00:04:02,060
services fortunately all that information has already been encoded in another location.

56
00:04:02,160 --> 00:04:06,070
We've already set up all that information inside of ingress and connects.

57
00:04:06,180 --> 00:04:10,890
So rather than using option number two and having our client reach directly out to our service we're

58
00:04:10,890 --> 00:04:12,610
going to go with option number one.

59
00:04:12,840 --> 00:04:16,530
We're gonna say that in time we need to fetch data from a service inside of our communities cluster

60
00:04:16,730 --> 00:04:22,530
we're going to have our next J.S. application reach out to an ingress engine X which is already running

61
00:04:22,530 --> 00:04:29,050
inside the cluster ingress engine X can then figure out where to send this request off to based upon

62
00:04:29,140 --> 00:04:31,410
just the path by itself.

63
00:04:31,420 --> 00:04:35,920
So all we have to do is say hey ingress engine X I'm trying to make a request to API users current user

64
00:04:36,340 --> 00:04:41,990
and ingress engine X already has the set of relevant rules and we put together right here.

65
00:04:42,250 --> 00:04:47,530
It knows how to take a request to some arbitrary endpoint and map it up to some service and some actual

66
00:04:47,530 --> 00:04:49,890
port.

67
00:04:49,910 --> 00:04:54,950
Now there's just a little bit of a challenge with this approach for option number one and that is what

68
00:04:54,950 --> 00:04:55,820
domain.

69
00:04:55,820 --> 00:05:01,730
How are we making the request to how do we somehow reach out to ingress engine X while we are inside

70
00:05:01,730 --> 00:05:06,410
of some pod we can very easily reach out to ingress engine X from our local machine by just making a

71
00:05:06,410 --> 00:05:12,050
request to local host port 80 or as we have set it up ticketing dot Dev that's going to forward the

72
00:05:12,050 --> 00:05:17,850
request on to ingress engine X but how do we do that same thing when we are already inside the cluster.

73
00:05:18,050 --> 00:05:22,250
So that will be something for us to figure out we need to figure out how to make a request directly

74
00:05:22,250 --> 00:05:27,740
to ingress engine X when we are inside the cluster that's a little bit of a challenge to figure out.

75
00:05:27,770 --> 00:05:30,340
There's one other little challenge as well.

76
00:05:30,380 --> 00:05:36,320
Remember our entire authentication mechanism right now works based upon cookies.

77
00:05:36,370 --> 00:05:40,660
And so as we're talking about somehow fetching the current user we need to keep in mind in the very

78
00:05:40,660 --> 00:05:46,480
back of our head that we have some requests coming into our next as application and it includes a cookie

79
00:05:47,100 --> 00:05:52,350
and at some point in time we're going to make a follow up request from inside of next and that follow

80
00:05:52,350 --> 00:06:00,290
up request is probably going to have to include that cookie information right now back inside of our

81
00:06:00,350 --> 00:06:06,260
index dot J ust file when this gets executed on the server or inside of next we do not have access to

82
00:06:06,260 --> 00:06:09,890
the browser to automatically manage that cookie or anything like that.

83
00:06:09,920 --> 00:06:14,570
This line of code when it's executed in a no j ust environment doesn't care about cookies.

84
00:06:14,570 --> 00:06:18,610
Cookies are the last thing that it could possibly care about in the world.

85
00:06:18,710 --> 00:06:23,030
So we need to figure out some way to make sure that we make this request from next J us.

86
00:06:23,030 --> 00:06:29,270
We take a look at the original incoming request we extract that cookie off there and include it in the

87
00:06:29,270 --> 00:06:35,160
request off to ingress engine x so that when this request finally gets routed through ingress engine

88
00:06:35,160 --> 00:06:43,000
X over to the all service and I like that right there the all service will see that incoming cookie.

89
00:06:43,040 --> 00:06:43,270
All right.

90
00:06:43,280 --> 00:06:44,090
So as you can tell.

91
00:06:44,540 --> 00:06:44,740
Yeah.

92
00:06:44,750 --> 00:06:47,450
This stuff is kind of crazy pretty darn complicated.

93
00:06:47,450 --> 00:06:52,620
As I mentioned last video this is really all why I wanted to take the server side rendering approach.

94
00:06:52,670 --> 00:06:58,190
I want you to see some these challenges around making requests to other services from inside of our

95
00:06:58,190 --> 00:06:58,710
cluster.

96
00:06:59,460 --> 00:07:01,360
OK so we got our work cut out for us.

97
00:07:01,430 --> 00:07:04,160
So let's take a quick pause right here and continue in just a moment.