All right.
So let's look at how we can implement Type ORM into our application and use it as our database of choice
instead of MongoDB.
Now, since we have an abstract repository in our application, it's going to be a lot easier to switch
out which database we're using.
Since all of our repositories in our microservices are extending this common one in our lives database
folder.
This abstract repository can be changed to work with type ORM.
We'll of course have to update our existing schemas and define them in a language that type ORM understands.
So let's go ahead and get started.
Now a quick note.
I'm going to be keeping all of this code related to moving over to Type ORM inside of a new GitHub branch
called Type ORM.
So if you want to see the completed code with all of the type ORM integration completed, you can run
Git checkout type ORM to get on this branch and I'm going to be working off of the main branch for this
series of lectures.
The first place we're going to start is our Docker compose file, where right now for our database you
can see we're running Mongo using the mongo image.
I want to swap this out for MySQL instead.
So to do this I'll change mongo to MySQL and for the image we're going to use the official MySQL image
and then we're going to specify an m file that the MySQL image will use to read in credentials for our
database.
So let's go ahead and specify this m file.
We'll create a new dot m at the root of our project where we will have environment variables specific
to just these extra images like MySQL.
So let's go ahead and create this dot env.
Now lastly, the database will be listening on port 3306 by default for incoming connections.
So let's go ahead and define a new ports list that will expose this port to our host machine by running
3306 colon 3306 which will map the target port to our machine's local port of 3306.
Now let's go to our Env and define some environment variables for this MySQL image.
Now just like we've done in all of the other M files in this project, this file would normally be git
ignored using the dot git ignore.
We'd add this to the git ignore so that we don't commit any sensitive information in this dot env as
I've done in the past.
I'm going to commit this dot m to make it easier for you in this project.
However, we wouldn't want to do this in production.
Let's go ahead and set up the MySQL database which is going to be the database or the default database
that MySQL will automatically create.
When it starts up.
We'll go ahead and call this sleeper, which is going to be our database name of choice next, we'll
specify a MySQL root password, which is going to be the root password used to connect to the database
server.
You can make this anything you'd like.
I'll just call it random root password.
So now at this point with Docker desktop running on my system, we can actually run Docker, compose
up and then specify this MySQL image to actually start up MySQL.
We can even see that we are listening on port 3306 for incoming connections.
Okay, so I've opened this application called MySQL Workbench, which is just a UI tool to allow us
to interact with our database.
You can easily download this by googling MySQL workbench and following along the installation instructions
for your system.
Once you've installed it, we can click on the plus sign here to add a new connections.
You can call this whatever you'd like, I'll call mine local Docker to and then we specify the default
host name here, which is our local loopback address.
And specify that default port of 3306.
The username is going to be root by default and for the password we'll click on store in Keychain where
we can then enter in our password.
So in our case it's random root password that we defined in that dot m file or whatever password you
were using.
Finally, we'll go ahead and click okay to add this connection.
So after adding this connection, I'll double click on it and you can see now we are brought to this
schema section here where we have our default database created, which we specified in the dot env.
We don't have any tables defined yet, but we can see we can connect to our Docker image and see this
default schema.
All right, so we're ready to start integrating Typekit into our app.
Let's go to the command line where I'll stop our server right now and then we need to run some dependencies.
And now we need to install some dependencies.
I'll go ahead and run npm install nestjs slash type ORM type ORM itself and then my too.
So now that we have the dependencies we need, let's go into our libs common folder and in our database
directory we'll open the database module back up and here we will refactor our database module to work
with type ORM instead of mongoose.
So now instead of using the Mongoose module for root async, I want to be running the type ORM module
dot for root async where we still have access to a use factory and here we will inject the config service.
But now we're going to expose a different set of environment variables to the type ORM module.
The first one we'll provide is a type here where we specify the type of database we're using.
We will use MySQL.
Then we're going to provide the host.
Now, like we did in MongoDB, we'll pull this off of the config service and I want to show you a different
way of also validating environment variables.
So in the past we've used joy to validate our environment variables.
However, instead we can use, get or throw, which will throw an error if the environment variable
doesn't exist in this call.
So this is the approach that we will take here.
We are going to get or throw the MySQL host environment variable.
We're going to go ahead and do the same thing for the port.
We need to call, get or throw and this will be the MySQL port.
Next we have the actual database name that we're connecting to.
So we will call, get or throw MySQL database, which we know is going to be sleeper as we've already
defined.
And finally, for authentication, we'll provide our username and password from the config service.
So this will be MySQL username.
And the password will be getter.
Throw my SQL password.
So another option that we're going to enable is called synchronize, which is going to automatically
create our database schema every time our app is launched.
If it doesn't match.
So importantly, we can see here that this should not be used in production, otherwise you could potentially
lose data.
So it's important and helpful to enable this when we're developing locally but not in production.
So we'll use an environment variable to pick this option up as well and call config service dot getter
throw MySQL synchronize.
Finally, the last property we'll enable is auto load entities and this is going to automatically load
all of the different entities, which is the same thing as schemas in mongoose in our application so
that we don't have to come back to here and define them every time we create them.
Nestjs will automatically load them using the metadata we provide on those classes, which is super
helpful.
Now let's come back to the database module for feature call.
We're currently we're taking in these models of type model definition.
Let's change this to entity class or schema from type ORM.
And you can see this auto import that occurred up top.
And instead of calling Mongoose module, we will return the type ORM module dot for feature and then
pass in these models.
So essentially we're doing the same thing we did in Mongoose when we had to register our schemas.
We're going to do the same thing here in the database module with type ORM and the entities is what
we call them.
So now we can go ahead and remove these imports up top that reference mongoose since we're no longer
using them.