Can we combine a NestJS app with React? 

Ah yes thank you! Yup in the newer versions turbo expects you to set long running process (e.g. things in watch mode) as “persistent”. Fyi my most recent video is an expansion of this setup which includes creating type safety between the api and client, if you’re interested, but it also shows the most up to day setup that we did in this video.

@@mariusespejo Hello Marius, I love your content. Could you please do a video on how to deploy this codebase 😍😍 ? Thank you very much for your amazing video🤜🤛

@@mariusespejo Yeah!

Nx, rspack and vite, excellent combo for netsj/react | vue

Hope your project goes well!

Thanks!! Glad you found it useful

Yeah I imagine that’s not straightforward since Nest locally runs on webpack while remix comes with their own app server I think. Personally I’d probably just run the two servers separately in all environments to get dev/prod parity

Turborepo has support for internal packages for shared code. I assume it’s set up to restart apps locally if changed, not positive but worth a try

Glad to help!

It’s a tutorial on setting up a monorepo for any client, routing for a specific client is completely out of scope. Anyways if you’re curious you just need to use react-router which is well documented, and setup the server such that it always returns index.html unless the path starts with /api

@@mariusespejo didn't know it would work that simple. thank you for fast response.

Thank you Asim!

@@mariusespejo I changed reactjs to astro I did it since it is vite 👍 I will try to learn more about Nestjs

Glad to help!

Yeah good thought, will think about it, thanks!

I do think server and client having their own deployments ultimately would scale better. But yeah if you have a need to deploy changes from both ends together, then you might benefit from a monorepo and a single CI/CD pipeline. Also when you’re making a feature that changes something on both sides, then you can have a single git branch for that… can share code, types, and eslint/prettier config, etc.

Turborepo does have support for that, you can configure a common lib for the apps to pull from

You can maybe try something like this: turbo.build/repo/docs/handbook/sharing-code/internal-packages I mean in general also understand that single repo means each of yours app technically should have access to any common code/folder

You’re welcome!

Yup it’s agnostic since SPAs are all mostly just an index.html with static files

Yeah I’ll see if I can but at a high-level deploying a nest app is really like deploying any other node app, which you can do on platforms like vercel, aws, etc. For the pipeline pick whatever tool you like, have it pull code from your repo, use turbo to build your app, the build output is basically your deployable.

@@mariusespejo That makes sense, cheers! :)

I'd love to see how to dockerize it and deploy automatically, I'm a newbie and it will be very helpful

Good question and actually a great video idea, but to answer your question: turborepo has this concept of “internal packages” which is really any code that you want to share across your apps, so in my mind that’s a pretty good place to maintain a contract

@@mariusespejo Thanks for such a quick reply! As I'm reading more about TurboRepo, I definitely agree with you on that. Keep up the awesome work!

Because in local development you’re changing the code often and you need an actual dev server, like with vite or webpack, which can do things like hot module reload or auto refresh browser on changes, etc. It’s just more convenient

I do not currently have a video for that. But I imagine you can get memory leaks from things like caching, ORMs (can sometimes load a bunch of data into memory), things relating to EventEmitter (e.g. maybe too many listeners), etc. anything really that might not be properly garbage collected. I don’t know that I have any specific advice on how to avoid, but make sure to keep an eye on your app’s memory usage in test environments, run some stress testing to see how it handles large loads. Then in production make sure you have alarms set for when memory goes unexpectedly high. Hope that helps!

The two apps are still fairly independent, changing code in one side doesn’t necessarily affect the other. It just so happens that the nest server serves up the client build, so that’s fairly light coupling in my mind. But yes, in more complicated projects you’d probably want to scale each side independently, at which point separate deployments would make a lot of sense. And yes you totally could use Nx as an alternative, definitely seems more feature rich, turbo just felt dead simple to get started with for me personally

@@mariusespejo once you go Nx you can never go back ;). It does all of the config etc that you needed to do with turbo, and all the generators work while you can also easily build your own plugins (for more advanced projects. Another favorite feature is that is supports whatever programming language you want to use while still keeping everything managed and ran as npm scripts. Would love to see a video of you covering NX too. :) love your videos, keep up the great work!

You might also need to configure stuff for vercel specifically, via vercel.json vercel.com/guides/how-to-enable-cors Note I haven’t tried deploying a nest app to vercel so I’m not 100% sure

There are several tools that can give you that ability but I have been using Warp personally

yeah I use oh-my-zsh but I'll give this a go! Thanks. Keep it up

Similarity doesn’t necessarily mean it would make more sense lol I would pick solutions based on actual tradeoffs (e.g. in comparison to similar tools in the space like react, vue, etc.)

I use screenflow but I know most other tutorial channels do use OBS, it’s a good choice. The blurry text could be from incorrect export settings. It’s also often good to use bigger font sizes so there’s more pixels (I think). Plus the color/theme of editor also plays a part to a degree, e.g. consider themes with higher contrast.

Not necessarily. I mean the idea is the same, you can have one root build command that builds both your apps. Single repo and same CI/CD pipeline. However you now have two servers to spin up upon deployment, whereas in this video we have one (because the Nest is serving up the static client).

Good question, no it does not count as server-side rendering. SSR means typically you are rendering the page of your client on the server, on the fly. In this case we are building the client upfront and simply having the server serve up those files. So you effectively have a single page application here. If you are interested in SSR your best bet are using frameworks such as NextJS or Remix

The point of monorepo is to have one repo for two or more applications, if you have two repositories that’s longer a monorepo. Hope that helps

Personally I think that Next can handle the backend on it’s own, unless you really need a standalone Nest API for other clients

That’s expected if your apps require dependencies at different versions

I can’t tell you if there is or isn’t a security problem with your setup, that depends totally on how your infrastructure is setup. Is your API publicly accessible and can anyone simply spoof a user with roles? If so then yes it’s a problem. Do you have the servers in a VPC to make sure only requests from your client are coming in? Then not having authentication on the API is probably okay if you set that up correctly. Why not just implement both authentication and authorization on the API though? That would make the most sense to me

@@mariusespejo thanks for the comment. Yes my bad, I started with nextJs first and I used next-auth because it’s easy but now when I get to focus more on the server side I start frustrating I am using nestjs with prisma and mongoDB. Do you have any tips or suggestions that I can follow because I am new to it.

There is a video in my channel on how to do auth with Nest. You also could just ditch nest and just do everything on Next, have you thought about that? If you only have basic API needs, you can just do your prisma/mongo work in Next directly

@@mariusespejo well noted! I'll have a look ! thank you.

It’s important to understand that the build output here is just a client SPA and a nodejs server (nest) which serves up that client build. So really it would be just like any other dockerized node app. Make sure you run build and make the client build available to the server

Yes if SEO is not a big concern and you’re okay with SPA no need for Next/Remix. They have their own pros/cons but not going to discuss that here. Re: your questions. You might be overthinking it a little bit. The main point is that both apps are in the same repo, so yes you can share code and types. However everything else is entirely up to you. If you want to you could still deploy your react app separately as you do today and nothing would change, just that now the code lives together. In the setup in this video the Nest server also becomes the client server in production so that you don’t need an extra server to serve up the client SPA. E.g if your server’s domain is samuelpares.com, then The Nest server would respond with the SPA (index.html) for all routes except what you designate as the api path, e.g. you can set it up so that sameuelpares.com/api doesn’t return index.html but instead sends requests to your API. Your react client would just then need to make requests like fetch(/api/whatever”); So that also means this setup has no effect on your auth strategy, you can pick either of those approaches. Hope that makes sense. Also if your main problem is simply sharing types or general end-to-end type safety check out my video on ts-rest

@@mariusespejo I see, thanks.. just another thing, about the proxy in development mode, I need that my server receives the subdomain is being accessed, do you have any ideas how could I do it using still relative paths in fetchs?

Possibly but I have a list of topics to cover and it might take a while. Note it’s not as complicated as it seems. All you need is a pipeline that runs “npm run build” and the output is simply a node/nest app that you can deploy in so many places

Yes, turborepo supports having local libraries for shared code

I don’t at this time but likely in the future!

Not really familiar with flutter sorry. I think yarn workspaces are only for js projects?

I have not! Looking to try out Nx sometime, I’ve heard good things. Lerna from my understanding is now owned by the folks behind Nx? So I assume that’s kind of going away

@@mariusespejo Nx and Lerna are orthogonal and simbiotic, but also check-out lerna-lite, which only adds what workspaces does not.

@@mariusespejo I think that is correct, if you are using lerna in a project then just keep doing that, but don't start another project with it.

Make sure to always check docs if you’re not sure. Also typically when you create projects like nest, it comes with a .gitignore, you might just need to move it to the root of your monorepo git-scm.com/docs/gitignore

@@mariusespejo The client and the api both have their own .gitignore files. Not sure how to combine them or if I even need it :\ Also thanks for the quick response!!

Right, use that as a starting point. Make a .gitignore at the root and copy things over to it, from each app, to combine them. You might just need to update the paths, taking into account that your apps are inside /apps. If that still doesn’t make sense to you I suggest reading the docs and truly understanding how gitignore works

Quick update: I just found a way to deploy it, uploading a video explaining right now

Yes to deploy the nest app you mostly need the dist folder, but in this instance you also need the build for the client

Sorry I wouldn’t know the problem from this comment alone, might want to ask in stackoverflow

vercel/turbo/issues/5331

Replace the react setup with however you create angular apps, the rest is 90% the exact same thing

@@mariusespejo Thanks a lot, btw have you used Nx monorepo ?

I have not but I’ve heard it’s a good alternative

@@mariusespejo I think it's better than Turbo in terms of community and ecosystem of plugins. You should give it a try. 👍

Totally! it’s been around much longer so I definitely see that, it’s on my todo list to compare the two

I think that’s Cascadia Mono, it’s free!

@@mariusespejo thanks mate

In general the client needs some kind of server, it’s up to you what to use. But the point of the example here is that the all code is in one repo, we already have server for the api, so might as well have it serve up the client

Article or video ?

I can’t think of a reason why it would not allow to push. Make sure to check the any errors that show when you attempt to push. Also make sure that you don’t have accidentally added to your gitignore

Ok thanks @@mariusespejo

That was juste a .git create in api but not in client. And a .gitignore of .IDEA

You wouldn’t. See the core difference in the SPA setup here is that in production the client build is served by the nest server. So any api calls the client makes just goes to that same server. We proxy in dev to simulate that, because in dev the client has its own server. For a next + nest setup however you have two servers to spin up in production, so you would need to make http calls from next to nest. Totally different setup. I would suggest however if you plan to use Next, consider if you really need a separate app for the API still

I can’t tell from this comment alone what the problem might be, generally 404 means not found, figure out what’s missing in your config

I’m not totally sure about that, turbo definitely seems like a it’s meant to work with the node/npm ecosystem. If it’s a totally different language I’d probably just do it in a different repo if it was me personally

I need to know this as well 👀

Lots of different ways to get intellisense/autocomplete on the terminal but here I’m using warp which has that as a feature built-in

Probably but don’t think it would be the best setup, you’d be better off using Next.js

Must be lucky!

You need to make your server return the SPA on any route, then reserve a base path for your api like /api create-react-app.dev/docs/deployment/#serving-apps-with-client-side-routing

@@mariusespejo Yes with Express I know how to do it, but, do you know a solution for this in nest js?

Understand that nest is just a layer on top of express.. it’s basically the same solution, create a catch all route. Check the docs or any of my videos if you’re still not sure

I don’t have a strong opinion on that to be honest but if you do have common logic used across multiple apps, or perhaps common UI components used across multiple clients, then having that defined once in a shared package makes a lot of sense. Turbo also does support “internal packages” exactly for this purpose

If you specifically want ssr you’re better off using nextjs

​@@mariusespejo So How can we integrate nestjs with nextjs I think we can use nest-next package would appreciate if you make a tut for nextjs with nestjs

I don’t think it’s worth integrating them together. If you specifically want your APIs built with Nest, then just deploy it as it own app/api, proxy requests from next to it. The integration is basically the API requests. If you don’t have a real need for a standalone API however consider just using next alone, build the API there, it’s a fullstack framework

Okay thanks for your quick reply ❤️

You can if you want to, you can use whatever client framework

You can pass “envFilePath” param to ConfigModule.forRoot to customize where it should look for the file. If the path to it is different between your src and build/dist, then you need to add some conditional logic there, for example envFilePath: fs.existsSync(pathToFile) ? pathToFile : null However I would question why the path would be different. Personally I would suggest placing .env on the root of the entire project, not the api directory. That’s where configmodule will look for it by default, assuming you’re running the apps for the root of the project

​@@mariusespejo Thanks! Just a follow up question, having gone further into making my app, why is my npm build suddenly including a src directory on the dist of api? With that, there's error showing up that there's no module found in the path 'apps/api/dist/main' as the 'main' is now inside a 'src'. So I tried making it work by adding the /src before 'main' in root package json like ` "start": "node apps/api/dist/src/main" ` but now the client doesnt work. Rewatching the vid I can see that it's because ` ServeStaticModule.forRoot({ rootPath: join(__dirname, '../..', 'client', 'dist'), }), ` needs to add another ../ to find client/dist/index. What is the right way to do this? should I prevent having a 'src' directory on build inside my api/dist? if so how? Thanks again!

I would not expect there to be an src folder in dist. I would suggest fixing that problem specifically. I have seen that issue before though, I think it happens when you import stuff outside of src in your code, but I’m not positive

@@mariusespejo Fixed both of them! Seriously, thanks! Subbed

@@mariusespejo Hey, how are you doing! I wanna reach out again for a problem I've encountered. I'm trying to deploy to Vercel and I just couldn't make it work after trying out different suggestions and settings from anywhere. The error I got was there was no "public" directory for output. so I changed some settings there to use "apps/api/dist" which didn't work too. I tried with "apps/client/dist" as well but it doesn't find other pages to navigate with react-router. Maybe you have an Idea how to make this work? or any other deployment method (no need to be in vercel), to show a live build. Thanks.

Sorry it’s not in a repo, I recommend using the video as a guide. I spend time explaining things but it honestly is a pretty quick setup

Sorry I don’t really have the capacity to help people write their own code, I suggest reading docs and taking what you learned here and give it a shot yourself.

I mean I show exactly how to set it up in the video… it’s really not that much work

@@mariusespejo yes, but sometimes reading the code makes it better understood. and often faster. whatever, thank you for the video.