1
00:00:00,720 --> 00:00:05,820
Now that we've got our mongoose modeled class put together we can use it to create a new record inside

2
00:00:05,820 --> 00:00:07,320
of our users collection.

3
00:00:07,320 --> 00:00:10,080
Any time a user first signs up to our app.

4
00:00:10,320 --> 00:00:15,120
So the first thing we need to ask ourselves is where are we going to place this logic inside of our

5
00:00:15,120 --> 00:00:19,420
application when is inappropriate time to create this new user.

6
00:00:19,740 --> 00:00:27,120
Well if you recall inside of our services passport G-S file we have our Google strategy.

7
00:00:27,360 --> 00:00:33,030
And the second argument that Google strategy was a callback function that was automatically called any

8
00:00:33,030 --> 00:00:37,600
time a user was redirected back to our application from the Google flow.

9
00:00:37,710 --> 00:00:45,240
This callback function has the access token refreshed token and Google user profile as arguments.

10
00:00:45,390 --> 00:00:51,580
So this Google user profile right here it contains the Google User ID which is the unique identifier

11
00:00:51,600 --> 00:00:56,060
token that we want to persist and save into our user record.

12
00:00:56,100 --> 00:01:00,810
So before it just kind of dive in and write this code I think we should probably get this console log

13
00:01:00,870 --> 00:01:03,020
get all three of these logs to appear in our terminal.

14
00:01:03,020 --> 00:01:09,690
Just one more time so we can verify that the profile does in fact have some type of unique user ID.

15
00:01:09,780 --> 00:01:11,840
So going to make sure that my server is still running.

16
00:01:11,970 --> 00:01:17,820
It's like I closed mine at some point and then once my server is running I'm going to go through my

17
00:01:17,950 --> 00:01:21,450
waterflow one more time just to see that counts log.

18
00:01:21,450 --> 00:01:29,430
So pull up a new browser window or go to localhost 5000 slash off slash Google and then at this point

19
00:01:29,460 --> 00:01:33,930
all I have to do is navigate there that automatically kicks me through the entire flow and then I'm

20
00:01:33,930 --> 00:01:37,950
just pending in the browser waiting on the server to do something with my request.

21
00:01:37,950 --> 00:01:42,150
And remember we are not properly handling the request on the server right now so everything is just

22
00:01:42,150 --> 00:01:43,940
going to kind of sit.

23
00:01:44,010 --> 00:01:48,460
However if we flip over to our terminal we will see the three console logs appear.

24
00:01:49,110 --> 00:01:54,800
So here is our access token our refresh token and then the Google user profile.

25
00:01:55,260 --> 00:01:56,430
OK so here's the ID.

26
00:01:56,430 --> 00:02:02,420
This is the Google user id remember this is the token that we are assuming is going to be very consistent

27
00:02:02,700 --> 00:02:09,260
and the exact same every single time this user right here like me comes back and runs through the overflow

28
00:02:09,330 --> 00:02:10,910
inside of our application.

29
00:02:10,950 --> 00:02:18,430
So we are really depending on this idea right here to always be the same no matter what.

30
00:02:18,470 --> 00:02:20,280
OK so we've got the user profile.

31
00:02:20,330 --> 00:02:26,120
We've got the ID all we have to do now is use that mongoose middle class to create a new record containing

32
00:02:26,120 --> 00:02:29,590
this ID and then save it to our database.

33
00:02:29,940 --> 00:02:32,420
So going to change back over to my code editor.

34
00:02:32,480 --> 00:02:36,250
I don't think that we really need these conses logs anymore so I'm going to clean them up.

35
00:02:36,800 --> 00:02:42,170
And the first thing that we need to do is make sure that we can get access to our mongoose model inside

36
00:02:42,170 --> 00:02:43,550
of this file right here.

37
00:02:43,880 --> 00:02:48,800
Now traditionally for everything else so we've really done inside of our application so far we have

38
00:02:48,920 --> 00:02:54,520
exported code from some given file and then required it or imported it into another.

39
00:02:54,770 --> 00:03:00,980
So you might be thinking that we need to somehow export our user model class from the user G-S file

40
00:03:01,370 --> 00:03:04,200
and then require it into the passport G-S file.

41
00:03:04,310 --> 00:03:06,530
And that is usually what we would do.

42
00:03:06,570 --> 00:03:13,310
However for everything that uses mongoose model classes like what we just created inside of year we

43
00:03:13,310 --> 00:03:17,350
are not going to use require statements and there's a very good reason for that.

44
00:03:17,540 --> 00:03:21,700
So just a quick aside I want to explain why we are not going use require statements here.

45
00:03:22,550 --> 00:03:28,700
Sometimes when you use mongoose inside of a testing environment so like say you're running some tests

46
00:03:29,120 --> 00:03:34,250
you're running Moka or you're running just whatever it is you're running some type of tests over your

47
00:03:34,250 --> 00:03:35,180
codebase.

48
00:03:35,270 --> 00:03:40,460
Sometimes your model files will be required into the project multiple times.

49
00:03:40,790 --> 00:03:45,470
Mongoose will get really confused when that happens and it will think that you are attempting to load

50
00:03:45,470 --> 00:03:51,440
in multiple models called users and then it will throw an error and say hey you've already loaded in

51
00:03:51,440 --> 00:03:53,180
something called the users before.

52
00:03:53,180 --> 00:03:57,620
And so this is specifically something that sometimes comes up in the testing environment.

53
00:03:57,620 --> 00:04:02,120
And so just to make sure that you're never going to run into that issue in the future we are going to

54
00:04:02,180 --> 00:04:08,670
require in the mongoose model class the user class in a slightly different fashion.

55
00:04:08,690 --> 00:04:10,070
So here's what we're going to do.

56
00:04:10,460 --> 00:04:15,920
Inside my passport file I'm going to first require in the mongoose library

57
00:04:20,750 --> 00:04:27,440
and then underneath all my required statements I'm going to get access to that user model class by writing

58
00:04:27,440 --> 00:04:39,360
Konst user is mongoose model users like so so back inside of user J us we created a user schema and

59
00:04:39,360 --> 00:04:44,880
we loaded it into mongoose by saying model and their first argument of users.

60
00:04:44,910 --> 00:04:53,190
And the second argument of the user schema so that loads a schema into mongoose we can pull ice schema

61
00:04:53,190 --> 00:04:58,380
or pull a model out of mongoose by just giving a single argument.

62
00:04:58,380 --> 00:05:00,450
So among those model users.

63
00:05:00,510 --> 00:05:04,200
So one argument means we are trying to fetch something out of mongoose.

64
00:05:04,200 --> 00:05:07,920
Two arguments means we're trying to load something into it.

65
00:05:07,920 --> 00:05:14,940
So now the user object right here is our model class again remember that model class is something that

66
00:05:15,000 --> 00:05:20,730
essentially gives us a relation or kind of a handle to the underlying collection that exists inside

67
00:05:20,730 --> 00:05:22,060
of Mongo D-B.

68
00:05:22,260 --> 00:05:28,350
So we can use this model class to create a new model instance and then save it or persist it to the

69
00:05:28,350 --> 00:05:30,450
database.

70
00:05:30,540 --> 00:05:37,420
All right so down inside of our callback function we're going to use the model class to create a new

71
00:05:37,420 --> 00:05:38,610
instance of a user.

72
00:05:38,740 --> 00:05:43,040
And we do that by saying new user with a capital U.

73
00:05:43,510 --> 00:05:48,700
And then we pass in an object that contains all the different properties that this user will have for

74
00:05:48,700 --> 00:05:49,030
us.

75
00:05:49,030 --> 00:05:53,560
The only property that we care about right now is that google id property.

76
00:05:54,070 --> 00:06:02,750
So back inside of password that Jesus will say create a new user who has a google id of profile dot

77
00:06:02,830 --> 00:06:03,900
ID.

78
00:06:04,570 --> 00:06:10,130
So remember the profile ID is the ID coming from the users Google profile.

79
00:06:10,750 --> 00:06:13,730
OK so this right here creates a new instance of a user.

80
00:06:13,750 --> 00:06:19,930
So this is like one discreet record it represents a record that exists or might exist inside of our

81
00:06:19,930 --> 00:06:20,930
database.

82
00:06:21,220 --> 00:06:27,310
Now when we first create a record using Mungo's like this or model instance to be precise it does not

83
00:06:27,340 --> 00:06:32,740
automatically persist it or save it to the database so we can kind of imagine that at this point we

84
00:06:32,740 --> 00:06:38,110
have created this model instance right here but because we have not saved it or persist in it to the

85
00:06:38,110 --> 00:06:44,290
database its just existing inside the javascript world or inside of our express API.

86
00:06:44,590 --> 00:06:50,650
And there is nothing that is automatically written or reflected to our Mongo database to get the model

87
00:06:50,650 --> 00:06:55,810
instance to actually persistence self to the users collection or to persist itself to the Mongo D-B

88
00:06:55,810 --> 00:06:56,730
database.

89
00:06:56,830 --> 00:07:06,570
We have to call a function on that method called Daut safe like so so when we call save it will automatically

90
00:07:06,720 --> 00:07:08,230
take this record.

91
00:07:08,460 --> 00:07:12,880
It will take that model instance and it will save it to the database for us.

92
00:07:13,520 --> 00:07:13,790
OK.

93
00:07:13,800 --> 00:07:18,010
So I think we're ready to test this out now before we just jump back over to the browser.

94
00:07:18,030 --> 00:07:21,090
I want to point out one very small issue to you.

95
00:07:21,240 --> 00:07:26,070
If we change back over to our terminal right now you might see a big old error message something that

96
00:07:26,070 --> 00:07:32,100
says hey app crashed please change something or you know hey fix the thing very much.

97
00:07:32,100 --> 00:07:38,400
And so if we look at the error message it says schema hasn't been registered for model users.

98
00:07:38,580 --> 00:07:43,810
So this is a very was kind of a tricky little air that we have right here.

99
00:07:43,830 --> 00:07:51,150
So it appears that mongoose thinks that we have not yet loaded a schema into mongoose that describes

100
00:07:51,150 --> 00:07:52,110
our users.

101
00:07:52,230 --> 00:07:53,810
It's the reason I say this is kind of tricky.

102
00:07:53,820 --> 00:08:00,140
It is that it's a total order of operations thing right now inside of our passports.

103
00:08:00,150 --> 00:08:03,060
J.S. file we are trying to pull out that user model.

104
00:08:03,060 --> 00:08:06,260
Right we're trying to pull out that user Mollah class right here.

105
00:08:06,690 --> 00:08:13,540
The password that js file is executed when ever the index file requires it in.

106
00:08:13,560 --> 00:08:17,530
And so here is the required statement for that passport dodgiest file.

107
00:08:17,580 --> 00:08:25,020
However we first are running that passport file where we tried to pull the model out of mongoose and

108
00:08:25,020 --> 00:08:31,470
then only after that do it executes or require in the user model class file which is where we actually

109
00:08:31,470 --> 00:08:33,830
define the model class.

110
00:08:33,840 --> 00:08:38,760
In other words we are seeing that error message because we are attempting to make use of the user model

111
00:08:39,120 --> 00:08:41,360
before we have actually defined it.

112
00:08:41,370 --> 00:08:46,850
So to solve that issue all we have to do is change the order of these two require statements.

113
00:08:46,860 --> 00:08:52,330
Yes that is a very what's the word for it it's like a very tricky little thing.

114
00:08:52,350 --> 00:08:54,520
It's a very fine grained detail.

115
00:08:55,050 --> 00:08:59,970
Essentially I really just wanted you to see that error and be aware that the order of your require statements

116
00:09:00,240 --> 00:09:03,630
can result in errors inside of your application.

117
00:09:03,630 --> 00:09:09,210
So now if we save the index just file with the model being declared first and then passport trying to

118
00:09:09,210 --> 00:09:10,530
use it second.

119
00:09:10,680 --> 00:09:15,360
Now we can change back over to our terminal and it looks like everything is going to go.

120
00:09:15,360 --> 00:09:19,130
Now we still do have those deprecation warnings but remember they're totally fine.

121
00:09:19,140 --> 00:09:23,880
They are being caused by mongooses interaction with Mongo D-B and there's nothing we can do to solve

122
00:09:23,880 --> 00:09:25,160
them right now.

123
00:09:25,690 --> 00:09:25,870
OK.

124
00:09:25,890 --> 00:09:27,920
So I think we're ready to test this out.

125
00:09:28,050 --> 00:09:31,210
I'm going to open up a brand new browser tab.

126
00:09:31,710 --> 00:09:37,530
I'm going to navigate to localhost Kolin 5000 slash auth slash Google.

127
00:09:37,530 --> 00:09:40,590
And again it looks like everything is just kind of hanging right now.

128
00:09:40,890 --> 00:09:46,110
But if we go back to our lab dashboard and hopefully you still have this open if you don't have it open

129
00:09:46,320 --> 00:09:51,030
feel free to pause the video and go silent in lab and open up the e-mail database.

130
00:09:51,270 --> 00:09:53,960
And then once I'm here I will refresh the page

131
00:09:56,820 --> 00:10:00,990
and underneath my list of collections I should now see a user's collection.

132
00:10:00,990 --> 00:10:02,130
So here it is right here.

133
00:10:02,310 --> 00:10:08,610
If I click on it I will then see a list of all the records that exist inside that collection.

134
00:10:08,630 --> 00:10:14,170
And so right here is my google id of 1 1 1 7 2 2 3 5 blah blah blah.

135
00:10:14,520 --> 00:10:15,930
So cool looks pretty good.

136
00:10:15,930 --> 00:10:19,420
It looks like we are correctly saving a new record to our database.

137
00:10:19,500 --> 00:10:24,990
And so now in the future when we start to allow our users to create surveys or anything else inside

138
00:10:24,990 --> 00:10:31,470
of our application we can start to associate those surveys with this saved user record right here.

139
00:10:31,530 --> 00:10:35,730
So we've made some good progress but we still have a little bit of work to do on our authentication

140
00:10:35,730 --> 00:10:36,470
flow.

141
00:10:36,480 --> 00:10:39,390
So let's take a break and then continue in the next section.