WEBVTT

1
00:00:00.000 --> 00:00:05.199
Alright, so in this latest lecture, we've updated all of our dependencies in our Prisma branch.

2
00:00:05.199 --> 00:00:11.840
And this includes Prisma at v7. Now Prisma v7 introduces a few breaking changes to how we've

3
00:00:11.840 --> 00:00:16.079
previously configured Prisma. And so in this lecture, we're going to walk through these

4
00:00:16.079 --> 00:00:19.920
changes to see how you can upgrade your application. So I'm going to leave a link

5
00:00:19.920 --> 00:00:25.760
below to these changes to the repository that show you the exact changes we made in this commit.

6
00:00:25.760 --> 00:00:31.280
So you can review all them. But let's go ahead and jump in to see the changes. Now the primary

7
00:00:31.280 --> 00:00:36.319
change here in Prisma is if we go to off, for example, where we know we have Prisma setup,

8
00:00:37.119 --> 00:00:43.040
you'll notice that we now have a new file called Prisma config.ts here at the root.

9
00:00:43.759 --> 00:00:49.360
Now in Prisma v7, we have this new file, which is sort of like drizzle config. If you use drizzle

10
00:00:49.360 --> 00:00:55.040
before where we define configuration inside of TypeScript directly. So you can see here,

11
00:00:55.040 --> 00:01:01.040
we're importing dot m, which is the actual library that sgs config uses under the hood

12
00:01:01.040 --> 00:01:07.279
to load environment variables. And so this is the default configuration we import from Prisma

13
00:01:07.279 --> 00:01:15.279
config to find this config file where we define the path to our schemas, the path to our migrations.

14
00:01:16.080 --> 00:01:20.959
And finally, data source where we actually provide the database connection URL.

15
00:01:21.199 --> 00:01:26.239
Now you can use the m function from Prisma, which will use dot m under the hood to extract

16
00:01:26.239 --> 00:01:31.360
an environment variable. So in this case, we're extracting our database URL, which we know we've

17
00:01:31.360 --> 00:01:35.919
set up to point to our Postgres DB. Now importantly, there are some additional

18
00:01:35.919 --> 00:01:42.400
dependencies we need for this Prisma seven integration. So make sure you have PG installed,

19
00:01:43.040 --> 00:01:48.480
which is a node driver for Postgres, as well as dot m directly, which we use to read in

20
00:01:48.559 --> 00:01:53.760
environment variables. And finally, you're going to want Prisma slash adapter dash PG

21
00:01:54.639 --> 00:01:58.879
to have an adapter to Postgres that we can use in our node client.

22
00:02:00.879 --> 00:02:06.559
So with this Prisma config TS configured, we also have our Prisma folder here as before.

23
00:02:07.360 --> 00:02:11.759
And so inside of here, we have our schema dot Prisma file, which has changed a bit.

24
00:02:12.320 --> 00:02:20.000
So notice first here, our provider has been renamed to Prisma client without dash j s.

25
00:02:21.679 --> 00:02:27.919
Also, our output has changed. So previously, we actually generated output to node modules.

26
00:02:27.919 --> 00:02:33.520
Now we generate it to source. So inside of our source folder, we have the generated types,

27
00:02:33.520 --> 00:02:38.160
which is better for our import resolution for our code. And this is also means it's inside

28
00:02:38.160 --> 00:02:43.520
of our source control. So we can actually track our changes to our generated code.

29
00:02:45.839 --> 00:02:51.199
Lastly, we no longer have binary targets. But instead, we should have module format that is

30
00:02:51.199 --> 00:02:59.279
set to common j s. Because in latest Prisma seven, Prisma only generates an ESM by default,

31
00:02:59.279 --> 00:03:06.000
well, we know nest j s is still only supported in common j s. So we need to tell it to generate as

32
00:03:06.000 --> 00:03:13.119
common j s, which is what we do here. Now the final change we made is removed the database URL

33
00:03:13.119 --> 00:03:19.199
from the data source DB, we no longer provide the connection string here in the schema Prisma,

34
00:03:19.199 --> 00:03:24.720
that instead now comes from the Prisma config TS file. Now importantly, we also do have some

35
00:03:24.720 --> 00:03:30.639
changes to our source code as well. So make sure we go ahead and open up our Prisma service.

36
00:03:31.360 --> 00:03:38.160
So we'll start off with the reservations. We have our Prisma service, which we know was our database

37
00:03:38.160 --> 00:03:44.800
service. Previously, all we had to do here was extend the Prisma client and then call this

38
00:03:44.800 --> 00:03:50.800
connect. But now we actually have to instantiate the underlying connection to the database that we

39
00:03:51.839 --> 00:03:58.880
are using. And in this case, this is why we set up this Prisma adapter PG dependency before,

40
00:03:58.880 --> 00:04:03.839
because now inside of the constructor, the first thing we're doing here is creating a new pool

41
00:04:03.839 --> 00:04:10.479
object. So this pool object is a connection pool inside of Postgres. And a connection pool is

42
00:04:10.479 --> 00:04:16.480
essentially just multiple connections that can be reused and shared. Instead of having to close and

43
00:04:16.480 --> 00:04:22.640
reopen each new connection to the database, we can maintain this pool of connections which are

44
00:04:22.640 --> 00:04:27.519
always open and reuse so that we don't have to go through the overhead of establishing a new

45
00:04:27.519 --> 00:04:32.320
connection each time. So this is great for performance and for concurrent requests to the

46
00:04:32.320 --> 00:04:38.239
database in our app. And then with this pool object, we simply pass it into the Prisma PG

47
00:04:39.200 --> 00:04:46.559
constructor. And so this is the Prisma adapter PG, this is the adapter to connect Prisma and Postgres.

48
00:04:46.559 --> 00:04:52.959
So we create a Prisma PG object here and pass that adapter directly to the Prisma service

49
00:04:53.839 --> 00:04:58.239
super here. And so this is the updated constructor for our Prisma service to

50
00:04:58.239 --> 00:05:03.519
successfully establish a connection to the database. You should have this in both the Prisma

51
00:05:03.519 --> 00:05:09.679
service here for reservations, as well as in auth, which is the other service that we are using Prisma

52
00:05:09.679 --> 00:05:15.040
for. So this should look just the same in both. Now importantly, also note that we are extending

53
00:05:15.040 --> 00:05:20.640
the Prisma client from our generated folder, right? We don't import from node modules anymore.

54
00:05:21.600 --> 00:05:28.640
Instead, now we are actually using the generated code. So we told Prisma in the schema Prisma,

55
00:05:28.640 --> 00:05:34.000
that our generated path is now in source directly. So we have this all under source control as well,

56
00:05:34.000 --> 00:05:39.359
which is really nice. So these are the changes we need to the actual TypeScript itself. So this is

57
00:05:39.359 --> 00:05:43.519
all the source code changes we need. The other changes we're going to need are for our Docker

58
00:05:43.519 --> 00:05:50.160
file in Docker Compose. So we want to go into our Docker file for reservations to start. And let's

59
00:05:50.399 --> 00:05:55.440
take a look at the changes we've made. The first thing we've changed is we've removed previously,

60
00:05:55.440 --> 00:06:02.399
we had this copy statement here to copy our Prisma directory inside of reservations,

61
00:06:02.399 --> 00:06:07.760
we no longer need to do this or run Prisma generate or build inside of the development

62
00:06:07.760 --> 00:06:13.040
phase here. Instead, we're going to move this all to the production stage of our Docker build.

63
00:06:13.040 --> 00:06:18.239
Now importantly, we already have the Prisma directory available thanks to our apps reservations

64
00:06:18.239 --> 00:06:26.079
copy statement here. And so now inside of our production stage, you can see here on line 39.

65
00:06:26.079 --> 00:06:31.279
So this is the important Prisma related bit that we've added. So now we are copying from the first

66
00:06:31.279 --> 00:06:36.160
stage, the development stage where we know we have the reservations directory and the Prisma

67
00:06:36.720 --> 00:06:43.600
files inside. In this case, we're copying over our new Prisma config.ts file, which we know Prisma

68
00:06:43.600 --> 00:06:49.359
is going to reference to generate types and execute migrations. So we want to copy this TS

69
00:06:49.359 --> 00:06:54.559
file over into the final image. And that's what we do here to ensure we have it. And then we go

70
00:06:54.559 --> 00:06:59.839
ahead and copy over the rest of the Prisma directory. So we have the actual raw migrations

71
00:06:59.839 --> 00:07:05.839
that we know need to apply. And that is what we're doing in the last step here. So we've updated our

72
00:07:05.839 --> 00:07:10.799
run command. So there's no longer start prod directly. Instead, beforehand, we're running

73
00:07:10.799 --> 00:07:17.920
some commands where we CD into reservations, run our migrate deploy command, which is going to

74
00:07:18.480 --> 00:07:24.160
automatically apply our migrations against the database. And then finally, we CD back to the

75
00:07:24.160 --> 00:07:30.320
root of the app and execute Node JS against our main JavaScript file. So these are the steps we

76
00:07:30.320 --> 00:07:37.679
need to make sure we apply our migrations. Before we start our container, and that's exactly what

77
00:07:37.679 --> 00:07:43.440
we want to do. So this looks great. You'll notice that we have this same set of changes to the auth

78
00:07:43.440 --> 00:07:50.559
Docker file. So make sure we copy this over. And now the last change that we had to make for Prisma

79
00:07:50.559 --> 00:07:57.839
seven is to then update our Docker compose as well. So previously, our start command for our

80
00:07:57.839 --> 00:08:04.320
containers, we were able to just run migrate deploy directly and pass a schema argument to

81
00:08:04.320 --> 00:08:10.239
point to the Prisma schema. However, in Prisma seven, this is now deprecated, we can no longer

82
00:08:10.239 --> 00:08:16.000
apply that schema argument. So notice here that our start command for for example, our reservation

83
00:08:16.000 --> 00:08:21.760
service is now changed. Instead of running migrate deploy directly, we follow the same pattern that

84
00:08:21.760 --> 00:08:28.799
we just shown you in the Docker file where we CD into reservations, run the migrate deploy command

85
00:08:29.760 --> 00:08:35.919
to apply our migrations. We then also run Prisma generate to generate our types,

86
00:08:35.919 --> 00:08:41.119
and then run back to the root and run our start dev to start the dev server. So just like we did

87
00:08:41.119 --> 00:08:47.200
in the Docker file here, we're just updating this to work for the latest Prisma seven to deploy our

88
00:08:47.200 --> 00:08:52.719
changes and generate the types without the schema flag now. And so make sure you apply the same

89
00:08:52.719 --> 00:08:59.200
change, of course against off here as well. And so this is the last change we need for Prisma

90
00:08:59.200 --> 00:09:03.679
seven. With this in place, we should have everything we need to start up our containers

91
00:09:03.679 --> 00:09:08.719
and continue to use our application in production with Prisma latest version seven.

