Now that we've got our mongoose modeled class put together we can use it to create a new record inside
of our users collection.
Any time a user first signs up to our app.
So the first thing we need to ask ourselves is where are we going to place this logic inside of our
application when is inappropriate time to create this new user.
Well if you recall inside of our services passport G-S file we have our Google strategy.
And the second argument that Google strategy was a callback function that was automatically called any
time a user was redirected back to our application from the Google flow.
This callback function has the access token refreshed token and Google user profile as arguments.
So this Google user profile right here it contains the Google User ID which is the unique identifier
token that we want to persist and save into our user record.
So before it just kind of dive in and write this code I think we should probably get this console log
get all three of these logs to appear in our terminal.
Just one more time so we can verify that the profile does in fact have some type of unique user ID.
So going to make sure that my server is still running.
It's like I closed mine at some point and then once my server is running I'm going to go through my
waterflow one more time just to see that counts log.
So pull up a new browser window or go to localhost 5000 slash off slash Google and then at this point
all I have to do is navigate there that automatically kicks me through the entire flow and then I'm
just pending in the browser waiting on the server to do something with my request.
And remember we are not properly handling the request on the server right now so everything is just
going to kind of sit.
However if we flip over to our terminal we will see the three console logs appear.
So here is our access token our refresh token and then the Google user profile.
OK so here's the ID.
This is the Google user id remember this is the token that we are assuming is going to be very consistent
and the exact same every single time this user right here like me comes back and runs through the overflow
inside of our application.
So we are really depending on this idea right here to always be the same no matter what.
OK so we've got the user profile.
We've got the ID all we have to do now is use that mongoose middle class to create a new record containing
this ID and then save it to our database.
So going to change back over to my code editor.
I don't think that we really need these conses logs anymore so I'm going to clean them up.
And the first thing that we need to do is make sure that we can get access to our mongoose model inside
of this file right here.
Now traditionally for everything else so we've really done inside of our application so far we have
exported code from some given file and then required it or imported it into another.
So you might be thinking that we need to somehow export our user model class from the user G-S file
and then require it into the passport G-S file.
And that is usually what we would do.
However for everything that uses mongoose model classes like what we just created inside of year we
are not going to use require statements and there's a very good reason for that.
So just a quick aside I want to explain why we are not going use require statements here.
Sometimes when you use mongoose inside of a testing environment so like say you're running some tests
you're running Moka or you're running just whatever it is you're running some type of tests over your
codebase.
Sometimes your model files will be required into the project multiple times.
Mongoose will get really confused when that happens and it will think that you are attempting to load
in multiple models called users and then it will throw an error and say hey you've already loaded in
something called the users before.
And so this is specifically something that sometimes comes up in the testing environment.
And so just to make sure that you're never going to run into that issue in the future we are going to
require in the mongoose model class the user class in a slightly different fashion.
So here's what we're going to do.
Inside my passport file I'm going to first require in the mongoose library
and then underneath all my required statements I'm going to get access to that user model class by writing
Konst user is mongoose model users like so so back inside of user J us we created a user schema and
we loaded it into mongoose by saying model and their first argument of users.
And the second argument of the user schema so that loads a schema into mongoose we can pull ice schema
or pull a model out of mongoose by just giving a single argument.
So among those model users.
So one argument means we are trying to fetch something out of mongoose.
Two arguments means we're trying to load something into it.
So now the user object right here is our model class again remember that model class is something that
essentially gives us a relation or kind of a handle to the underlying collection that exists inside
of Mongo D-B.
So we can use this model class to create a new model instance and then save it or persist it to the
database.
All right so down inside of our callback function we're going to use the model class to create a new
instance of a user.
And we do that by saying new user with a capital U.
And then we pass in an object that contains all the different properties that this user will have for
us.
The only property that we care about right now is that google id property.
So back inside of password that Jesus will say create a new user who has a google id of profile dot
ID.
So remember the profile ID is the ID coming from the users Google profile.
OK so this right here creates a new instance of a user.
So this is like one discreet record it represents a record that exists or might exist inside of our
database.
Now when we first create a record using Mungo's like this or model instance to be precise it does not
automatically persist it or save it to the database so we can kind of imagine that at this point we
have created this model instance right here but because we have not saved it or persist in it to the
database its just existing inside the javascript world or inside of our express API.
And there is nothing that is automatically written or reflected to our Mongo database to get the model
instance to actually persistence self to the users collection or to persist itself to the Mongo D-B
database.
We have to call a function on that method called Daut safe like so so when we call save it will automatically
take this record.
It will take that model instance and it will save it to the database for us.
OK.
So I think we're ready to test this out now before we just jump back over to the browser.
I want to point out one very small issue to you.
If we change back over to our terminal right now you might see a big old error message something that
says hey app crashed please change something or you know hey fix the thing very much.
And so if we look at the error message it says schema hasn't been registered for model users.
So this is a very was kind of a tricky little air that we have right here.
So it appears that mongoose thinks that we have not yet loaded a schema into mongoose that describes
our users.
It's the reason I say this is kind of tricky.
It is that it's a total order of operations thing right now inside of our passports.
J.S. file we are trying to pull out that user model.
Right we're trying to pull out that user Mollah class right here.
The password that js file is executed when ever the index file requires it in.
And so here is the required statement for that passport dodgiest file.
However we first are running that passport file where we tried to pull the model out of mongoose and
then only after that do it executes or require in the user model class file which is where we actually
define the model class.
In other words we are seeing that error message because we are attempting to make use of the user model
before we have actually defined it.
So to solve that issue all we have to do is change the order of these two require statements.
Yes that is a very what's the word for it it's like a very tricky little thing.
It's a very fine grained detail.
Essentially I really just wanted you to see that error and be aware that the order of your require statements
can result in errors inside of your application.
So now if we save the index just file with the model being declared first and then passport trying to
use it second.
Now we can change back over to our terminal and it looks like everything is going to go.
Now we still do have those deprecation warnings but remember they're totally fine.
They are being caused by mongooses interaction with Mongo D-B and there's nothing we can do to solve
them right now.
OK.
So I think we're ready to test this out.
I'm going to open up a brand new browser tab.
I'm going to navigate to localhost Kolin 5000 slash auth slash Google.
And again it looks like everything is just kind of hanging right now.
But if we go back to our lab dashboard and hopefully you still have this open if you don't have it open
feel free to pause the video and go silent in lab and open up the e-mail database.
And then once I'm here I will refresh the page
and underneath my list of collections I should now see a user's collection.
So here it is right here.
If I click on it I will then see a list of all the records that exist inside that collection.
And so right here is my google id of 1 1 1 7 2 2 3 5 blah blah blah.
So cool looks pretty good.
It looks like we are correctly saving a new record to our database.
And so now in the future when we start to allow our users to create surveys or anything else inside
of our application we can start to associate those surveys with this saved user record right here.
So we've made some good progress but we still have a little bit of work to do on our authentication
flow.
So let's take a break and then continue in the next section.