When we talk about monorepos, we don't talk about the frontend specifically. Quite contrary: an Nx workspace can also host our backend apps. This opens up completely new possibilities in terms of exchanging code between the frontend and corresponding backend API. But before diving deeper into this topic, let's first learn about how we can use the
@nrwl/express package to generate a Express based API application.
Instructor: [0:00] In our store application right now, if you go to the App component here, then you have basically here those get-all-games functionality, which actually will load through and create a variety of different material cars to visualize our board games.
[0:15] Now, this is not actual data. We import it from that fake API which is nothing else than here a folder and a static file which contains all of the data. Code sharing is a very appealing part of a monorepo structure. It doesn't mean only code sharing on a frontend part, but we can also share code with the backend part.
[0:35] First of all, let's generate a new backend application. If you go to the main documentation web page of NX and go to the getting started, then open up the plug-ins, we can see there is a variety of backend support as well.
[0:49] We have, for instance, plain node applications support. We have support for an express application. We have NestJS support, Next.js support as well. You can choose between all of these.
[1:00] Now, for the purpose of this example, let's just go with a plain old Express application. First of all, as you can see, we need to add that plugin to our workspace. Since I'm using yarn, I'm using here that yarn add command, and I'm adding Novel Express.
[1:18] Next, we want to generate an application. If you scroll a bit further down, we can see here the generate command. Now that we have added Novel Express, we now have also access to the generators for that application type.
[1:29] That has now an application here, and I'm going to give it a name and generate a new app. Let's go for that. I'm using yarn Nx generate at Novel Express application, we will call our app just API, because that's the API of our store application.
[1:45] Now, one interesting part, which we can do is to add the front end project, which in this case is store. This will already set up automatically a proxy for us locally, so that we can have a much better developer experience.
[1:59] You can see here it generates a couple of files, and also in our store app, it creates a proxy config. Let's see how that looks like and remove the dry-run flag. Now, if you go to the application folder up here, we see our API that has been generated, we see our main file, which contains all of the main application code of our Express application.
[2:19] Inside our Store app here, we actually see already a proxy config, which allows us to launch our store application everything that points to /API will be forwarded to the local host port, where our backend application runs.
[2:33] Let's actually launch our new node application. Again, we can go to the workspace JSON and we can look at our application. If you close your all the other ones, we will now have a new one, which is called API, which is the name. Again, down here in our architect part, we have a new target, which is called surf, which allows to surf the application. To start an app, let's just use yarn Nx.
[2:56] We give it parameter run. We give it a name, which is API in this case, and then a target reserve. Now, you can see how it gets compiled and here at the local host 333, we get our application running. Let's expose our data over the API. First of all, we go again to our main application here, which is store.
[3:17] We copy all the content here and bring it again over to our API, where we can simply go to the application folder and create a new file, let's call it game repository.yes, and we copy in our data.
[3:31] Next, we can go to our main file here and actually adjust our API, such that it returns the proper data, which we want. Let me just override these here and expose a new URL, which is basically /API/games and then for the detailed page, we want to expose a different API endpoint, which returns a single game.
[3:48] Also, of course, we need to import these. We can just get them from our game repository, which we just created. Let's again save, we see the API still serves. If you go here and do something like games, then we see all of the games that have been returned.
[4:04] We can also use single game via its ID, and if I add that user to API, we get just a single game from our API. If you go back and launch our Nx dependency graph, we can now see that we got a new application point up here.
[4:21] We have our store part and then we have that API application, which right now doesn't depend on any libraries and no one actually referenced that application yet.