WEBVTT 00:00.050 --> 00:04.370 Okay, now let's take a look at creating a production build of our react application. 00:04.370 --> 00:11.930 And our goal of this is we're going to effectively build and compile our application into physical files. 00:11.930 --> 00:17.240 And where we're going to output these files to is actually our API folder. 00:17.330 --> 00:24.560 We're going to use our dotnet kestrel server, the web API server to host our client application. 00:24.560 --> 00:31.760 And when I say host, what this is effectively going to do is when our client browser goes to localhost 00:31.760 --> 00:38.870 5001, we're going to configure our API to return the contents of a root folder. 00:38.870 --> 00:45.590 And the client will effectively download our react application and then use that downloaded code. 00:45.620 --> 00:50.360 So to accomplish this we need to go to inside our client folder. 00:50.930 --> 00:54.590 We need to go to our vite config dot js. 00:54.590 --> 01:02.820 And inside our config we can specify a build property open curly brackets and add the comma layer. 01:02.820 --> 01:05.460 And we can specify an output directory. 01:05.460 --> 01:09.060 And we're going to output this to period. 01:09.090 --> 01:09.630 Period. 01:09.630 --> 01:14.460 Forward slash API forward slash ww w root. 01:14.460 --> 01:16.260 So that's fairly straight forward. 01:16.290 --> 01:18.990 What we also want because we've got an. 01:19.020 --> 01:24.270 Dot e env file that we're using for certain configuration. 01:24.270 --> 01:33.000 The API URL and the white stripe publishable key will also have a production version of this configuration 01:33.000 --> 01:33.570 as well. 01:33.570 --> 01:39.810 So I'm just going to right click the client folder say new file and say dot env dot production. 01:40.170 --> 01:47.190 And this production version of this file will be used when we're running our application in production 01:47.190 --> 01:47.820 mode. 01:47.820 --> 01:52.470 And because this is a client side app, whether or not we add this to git, ignore doesn't particularly 01:52.470 --> 01:58.740 matter for this application, but we can always add it if we want to. 01:58.770 --> 02:04.030 We might as well we've added our developer configuration there, so we can just go to our Source control 02:04.030 --> 02:07.180 tab and we can add this to git ignore. 02:07.270 --> 02:12.550 So it's not going to be stored in with our other files inside GitHub. 02:13.000 --> 02:19.210 So back to Folder Explorer and back to our env dot production. 02:19.210 --> 02:25.870 Let's just open up the dot env file as well because we might as well copy what we currently have here. 02:25.870 --> 02:31.450 So I'm just going to control a control C and paste this into env production. 02:31.450 --> 02:35.020 We'll keep the stripe publishable key as it is. 02:35.020 --> 02:37.450 We don't have a different one for production for that. 02:37.450 --> 02:43.930 And we can effectively take out https localhost 5001 here. 02:43.930 --> 02:51.910 So our production API url is simply forward slash API, because our client application is going to be 02:51.910 --> 02:53.470 hosted with the API. 02:53.500 --> 02:53.770 The. 02:53.980 --> 02:54.940 Net API. 02:54.970 --> 03:02.360 Then all we need to do is go to it's relative path when we make a request to our API from the client. 03:02.390 --> 03:09.170 Another thing we want to look at if we go to our base API, then inside here we have a delay, which 03:09.200 --> 03:13.610 of course is fine whilst we're developing our application, but we don't really want that to happen 03:13.610 --> 03:15.440 when we're running in production. 03:15.440 --> 03:20.180 So we can check to see which mode we're running in and if we're running in production, then we will 03:20.180 --> 03:21.800 not add a fake delay. 03:21.800 --> 03:28.850 So we're going to check and we're going to say if import dot meta dot EMV dot. 03:28.850 --> 03:30.560 And then we can choose dev. 03:30.950 --> 03:33.890 Then we will sleep effectively. 03:33.890 --> 03:36.980 And of course when we're in production we're not going to see that fake delay. 03:36.980 --> 03:42.020 So our application, especially when running locally is going to be pretty fast. 03:42.020 --> 03:46.100 So let's take a look at what's going to happen if we build our application. 03:46.100 --> 03:47.990 So I'm just going to open up the terminal. 03:48.200 --> 03:50.690 And I've left this for a while. 03:50.690 --> 03:56.240 So I'm going to stop the stripe client for the time being. 03:56.240 --> 04:04.770 And I'm going to go to our tab where we've got our client, and I'm just going to stop this application. 04:04.770 --> 04:09.480 Looks like plenty of logs have been going on there, so I'm just going to Ctrl C and stop this. 04:09.480 --> 04:13.140 And what we're going to run to effectively build our application. 04:13.140 --> 04:22.230 If we go to package.json then we have a number of scripts and inside our build scripts then it's going 04:22.230 --> 04:29.340 to use the V8 build command, as well as use the TypeScript compiler to effectively compile our application 04:29.340 --> 04:34.920 into JavaScript, use the V8 build command, and then it's going to output these files into our API 04:34.950 --> 04:35.340 folder. 04:35.340 --> 04:41.010 So let's go take a look and see what happens when we run npm run build. 04:41.010 --> 04:42.600 And I'll press return. 04:43.410 --> 04:47.160 And okay, so it looks like we've got our files built here. 04:47.160 --> 04:52.350 And if we take a look we can see what's been created inside the API root folder. 04:52.350 --> 04:58.260 And all of the files that make up our client side application, we've got a warning about some chunks 04:58.260 --> 05:01.340 are larger than 500kB after minification. 05:01.400 --> 05:06.050 Consider using dynamic import, etc. and or. 05:06.050 --> 05:11.150 We could also adjust the chunk size limit to effectively remove this warning. 05:11.150 --> 05:19.010 Now after gzipping, this is going to be output as 237kB, which is fine for a client side application, 05:19.190 --> 05:23.840 so I'm not going to worry about it being slightly higher than the 500 kilobyte warning. 05:23.840 --> 05:28.700 But I will actually turn off that warning because I'm not a big fan of warnings that I'm not going to 05:28.730 --> 05:30.230 do anything to fix. 05:30.380 --> 05:37.280 And also, we've got this use empty output directory to override because of the location of where we're 05:37.280 --> 05:39.020 outputting these files. 05:39.050 --> 05:42.200 So a couple of tweaks that we're going to make to our configuration. 05:42.200 --> 05:52.280 If we go back to the vets config file then inside our build section here we'll add a chunk size warning 05:52.280 --> 05:52.760 limit. 05:52.760 --> 05:55.820 And I'm going to set this to 102 for for a megabyte. 05:55.820 --> 06:00.990 And I'm also going to use the empty output directory and specify this is true. 06:00.990 --> 06:03.270 And if we go, take a look. 06:03.300 --> 06:09.000 In fact, before we run that command again I just want to demonstrate what happened inside our API folder. 06:09.000 --> 06:11.820 We've now got a root folder. 06:11.940 --> 06:16.740 Inside here is an assets folder with all of our different assets that the client will download. 06:16.740 --> 06:22.140 We've got our images that are literally copied as are from the public folder. 06:22.650 --> 06:24.930 And we've got our index.html. 06:24.930 --> 06:31.110 And because it's a single page application, this is the single page that the client would request. 06:31.110 --> 06:35.580 And we've got our assets and index.js effectively. 06:36.270 --> 06:37.830 And our CSS. 06:37.830 --> 06:41.340 And what we have here is referred to as output hashing. 06:41.340 --> 06:47.850 So when we rebuild our application we'll have a different hash for our JavaScript file. 06:47.850 --> 06:53.940 And what that means is that the browser would typically try and cache any static assets that it receives. 06:53.940 --> 06:56.940 And JavaScript and CSS, they're static assets. 06:56.940 --> 07:01.510 So if we do update our Data application, then we would like a different hash so that the browser, 07:01.540 --> 07:07.720 when requesting this index.html file will say aha, I don't have that JavaScript file in my cache because 07:07.720 --> 07:10.690 it's going to have a different name because of this output hashing. 07:10.690 --> 07:17.470 And it would go and fetch the updated version of that JavaScript file and then cache that in the browser. 07:17.470 --> 07:20.200 So we've made a couple of changes to our config. 07:20.200 --> 07:24.160 So let's go and rerun the build command. 07:24.190 --> 07:27.190 And I'll just use npm run build again. 07:27.280 --> 07:33.640 And this time we should get our output clean without any warnings. 07:34.960 --> 07:37.390 And sure enough that is the case. 07:37.390 --> 07:41.950 And if we had any code changes then the JavaScript file would be updated. 07:41.950 --> 07:47.170 But because we haven't actually made any code changes, then it's using the same JavaScript file. 07:47.170 --> 07:48.040 So that's fine. 07:48.040 --> 07:48.790 Great. 07:48.790 --> 07:54.580 So now we have our react application effectively published to our API. 07:54.610 --> 07:59.110 Next we'll take a look at how we can run that application from our API.