If the monorepo route isn't for you, or you have an existing stack and converting to a monorepo isn't practical, you can always create a separate npm scoped library that holds your contracts and you import the package into each project. In other words, an SDK.
Yeah I’d like to cover deployments in general at some point, but in general: The end result of this setup is really just a single Nest app. You would deploy it just like any other node app.
In terms of solving type-safety yes it’s one of the solutions although ts-rest takes a slightly different approach, e.g. it allows you to design your API as you would normally with REST. If I were using NextJS here I’d probably consider trpc however for NestJS ts-rest has a much better first class support for it. Also trpc defines the API implementation as the contract whereas ts-rest keeps it separate. There are some benefits to that. ts-rest.com/docs/comparisons/rpc-comparison
trpc does it better than a neutral contract. with trpc your "source of truth" is the backend and you only need to match the frontend to adhere to it. with this setup the "source of truth" is external to both frontend and backend and any change to the contract requires changes in 2 spaces, not just 1.
Like I said, it’s just a different approach with its own tradeoffs. There is no black and white “better” for every situation, e.g. from the link I posted above they talk about a good example: “One example of this is with NX, in NX you can rebuild only "affected" packages, however, if you export your contract (e.g. tRPC) from the backend, your front end will need to be rebuilt as well. ts-rest negates this issue by allowing (in NX) for a library for the API contract to be created, this then means the only case in which the front and backend need to be rebuilt is when the contract changes.” Do understand that I am personally not saying either one is better, just that in this specific setup ts-rest has much better direct support for nestjs (that I’ve seen, I could also be wrong). Both are great tools.
Contract first is also a valid approach which both client and server must adhere to. And in this case neither backend or frontend would own it. In the non-node world it’s not uncommon to do it. One advantage here is that clients can use mock data on contracts to already start testing without waiting for the backend implementation to be done.
Thank you, interesting concept. I really like this monorepo approach. I belive we can achive something similar with OpenAPI as a contract and we can generate the models / api client. It would be nice to have some generator, which would give us the controllers with DTO validation already.
You totally can do that, but writing the contract in Typescript provides the best experience in my opinion vs writing OpenAPI spec by hand, there is no codegen necessary because we’re already writing in TS to begin with. Btw if swagger docs is the requirement, you can also generate openAPI from the ts-rest contract.
@@mariusespejo How can one generate openAPI swagger docs from the ts-rest contract? And will it be accessible from the /docs route? Thank you for the awesome video.
@johnisutsa1641 ts-rest has first-class support for it, you can see usage and examples for Nest and express below. And yes, it’s up to you which path you host it on ts-rest.com/docs/open-api
Are you talking about the contract routers? You just nest them inside another one, so like you need a root router with keys to other nested routers if that makes sense
Great video. I'm interested to know what application are you using for drawing on canvas and writing document in the same place? I've been looking for something like this!
thank you! does ts-rest set up work with angular too ? Any guidance / link etc. would be super appreciated! thanks again. (I did not not see angular support in the docs but google AI says it is possible so was hoping to get your take / input)
Hi! A question: is ts-rest full compatible with every NestJS functionality like pipes,guard,middlewares,interceptors? did you find any problem using Ts-Rest with NestJS? thank you!...
They definitely should be on the single handler approach, since that’s a 1:1 mapping to regular controllers. Multi-handler might make things more complicated if you need to have those decorators at the method level. But other than that the only thing they call out in docs as not supported is version and global prefixes
Is my assumption correct that for large applications, using a monorepo might not be the best choice due to potential coupling issues? For instance, if we decide to create a mobile application, we might face challenges with a monorepo setup. Similarly, if we want to split our server into microservices, having a monorepo could complicate things. On the other hand, is it true that a monorepo setup is more suitable for relatively small projects?
I think that it depends on your overall pipeline and deployment infrastructure. Fun fact for example, I believe google stores all of their code in a monorepo. Personally I would think of monorepos in a scenario where code sharing is beneficial, but like with everything it has pros and cons, and you need to pick based on which tradeoffs are okay with you. A native mobile app for example I don’t really see benefiting much from a monorepo where the other apps in the repo are in totally different languages and technologies.
I was just searching for a tutorial like this. I have one question. You are not using DTOs because you set a lot of constrains in the controller with the contracts, but in the communication between controllers and services or services and services you still need them. I guess. There's a way to directly derivate a DTO from a contract?
The “library” in this video where we store the contract can also export other things, e.g. you can export the zod schemas that you create or you can export the type inferred from those schemas. That basically gives you the “shape” of your DTOs that you can pass around between services. And yes technically you can also import zod schemas on the frontend and use it for validation. E.g. in react you can use it with react-hook-form which has support for zod
Are you saying nuxt can create type-safe APIs on it’s own? I couldn’t find anything with a quick doc/google search but I’m not as familiar with it. I do know with NextJS server components also solves the problem since you can make backend calls right in component code
How do you handle cookies on the server with this setup, the ts-rest headers don't seem to work as intended, and also when you add the monorepo internal package to the nestjs' dependencies it messes up the transpiling and adds other folders from the root of the monorepo to the dist folder. I did some hacky stuff to go around it but i'd love to know if there are optimal ways of handling both of these issues
First of all thank you for content of such quality. Could you also share the GitHub repository? I'm encountering an issue when attempting to import the api-contract package into the Nest server. I'm receiving the following error message: "Cannot find module 'api-contract' or its corresponding type declarations." Importing with a relative path resolves the issue: "import { contract } from './../../../../packages/api-contract/dist';". Interestingly, importing in the Vite project functions correctly. I've added the dependency to both projects' package.json files.
Have you encountered any errors when importing the react mui library to the frontend project? It seems it does not play well with the rollup commonjs plugin
@@mariusespejo Hey sure no problem. For anyone having issues with MUI what worked for me was to exclude the node_modules folder in the rollup commonjs plugin like this: commonjs({ exclude: [/node_modules/] })
How should be the monorepo setup if I want to make a server side rendered web app so nextjs with nestjs(using both these tech together does this make sense)? What are the pros and cons of using ts-rest over something like graphql, trpc ?
If you decide to use NeXtjs I would recommend you first try to see if you can get away with just doing it all in that one application. Utilize making direct backend requests (e.g. database calls) in Server Components within the new App Router. If you find that you need a much more sophisticated backend, NeStJS will provide you with a lot more flexibility and yes you can still follow this exact setup. It just would mean that in your deployment strategy you will have to think about having two applications to run. Your second question I think honestly would be best explained in another video but if I can think of a couple key points: Ts-rest and trpc are alternatives to each other. Ts-rest focuses on REST (meaning any client can still make requests the traditional way even without an api client) and tRpc is very much rpc-like (hence why both are named this way). Ts-rest keeps the contract as an external source of truth, whereas with trpc the API implementation itself is the source of truth. There are pros/cons to these approaches but hard to get into in a comment here. GraphQL I feel like is an entirely different beast. Think of it more like a complete alternative to REST, and that comparison alone is a pretty loaded topic. It does not however solve type-safety like ts-rest and trpc does because it defines the API schema in an entirely different language. So the only way it could help with typescript is via auto generated types. You’ll notice that ts-rest for example we didn’t have to generate anything, it’s already in typescript. Anyways hope that gets you some high-level differences, I’ll think about covering this in a follow up video
Hi @MariusEspejo , thanks for the video ,i really enjoy this setup , i have been trying to implement it in my own project and have trouble setting cookie headers , usually i would set it with response.setHeader, do you have any idea on how to achieve the same outcome using ts-rest ?
@@mariusespejo Thanks for your response :) , In the end i've found a solution so we need to pass the passtrough option to true in the Res anotation for tsHandler to maintain control over the response handling. @Res({passtrough: true}) response Thanks again for your content and taking the time to answer my comment. Keep it up :D
Good question, ts-rest also supports “single handler approach” meaning if you want to have individual controller methods for each route you can still do that. The effectively means you can still individually add extra decorators such as guards. Also any global guard should still work I believe ts-rest.com/docs/nest/#single-handler-approach---easy-migration-and-flexibility-%EF%B8%8F
I only briefly mentioned it in the video but since the React client here is a SPA, you can actually have the Nest server statically serve it in production so that you only have one server. In that scenario, it’s just as easy. Deploy it anywhere you can deploy a node app. Btw it’s worth mentioning that NextJS with the app router and server components already solves problems with lack of type-safety, you might not even need trpc unless you have route handlers. Anyways NextJS in general is the alternative to this whole thing, however NeStjs opens you up to a much more mature API framework with lots of possibilities.
Hi, can you elaborate/give advice how would one go about hosting this setup but insted of react its nextjs with nestjs,thanks! Not much experience with hosting in general
I would recommend learning about hosting nodejs apps and what that generally requires and what different options there are. There is no one way to do it, the answer is always “it depends”, specifically on your requirements. It’s not really easy to explain in a comment because you have so many options depending on what balance of complexity vs cost you want. For example you can host on VMs on the cloud and configure everything yourself, you could do a containerized strategy like with docker, you could go serverless… lots of different platforms which allow you to do these things With a nest + next setup you effectively have two apps to deploy… so you want to decide do you want to run both in one instance of a machine? Do you want them separate (e.g. so each one can scale on their own)? Sorry not really giving you a solid answer here but hopefully that gives you some starting points. Will think about a video covering various deployment options
So in this video I showed ts-rest’s “multi-handler” approach for maximum type-safety, but they do also allow “single-handler” approach which would bring you back to traditional single controller method per route, which should allow you to add any other decorator that you need for the method. Although I haven’t tried that myself specifically with guards
Thanks for the tutorial. I'm getting an error on the 'async handler()' part of the API implementation "The inferred type of 'handler' cannot be named without a reference to '.pnpm/@ts-rest+core@3.33.0_zod@3.22.4/node_modules/@ts-rest/core'. This is likely not portable. A type annotation is necessary." Have you encountered this issue or do you know how to resolve it?
Not familiar with that error but it might be specific to pnpm monorepos, you might need a slightly different tsconfig setup than mine Take a look through this thread: github.com/microsoft/TypeScript/issues/42873#issuecomment-906308997
Do you have experience with next.js instead of react? I followed but used next.js,works also but now thinking about hosting,also can't get react query to work on server side in next..any opinion or experience?
I do use Next in some current projects. Honestly if you are using NeXt, try to see how far you can get with using just Next on its own. If you utilize Server Components in the new app router, you’ve already got type-safety right there. No need for actual api routes. If you do end up needing a more sophisticated backend and need to introduce a second application (NeSt in this case) then yes this setup totally still works, it just means that your deployment strategy will require spinning up two servers. Regarding your question on using react-query, two things: 1.) you DON’T have to. Ts-rest can also create a barebones client which just utilizes fetch under the hood, so you can use that in Server Components. 2.) If you do decide to use react-query in NeXt, you will have to do it in “use client” components. So yes it can still work and is still useful in a lot of situations
I don't think it will work in with other stack except node JS. this video is nice to get updated with new tech but it doesn't guaranteed to be useful in any situation. esp. if you're not using TS in backend.
Nothing is guaranteed to be useful in every situation. The point here was to have end-to-end type-safety across the entire stack. Most modern web clients are written in typescript. If your backend isn’t also in TS, it means that you would have to generate TS-compatible types to pull it off which is not great.
Upload more NestJs tutorials. And nest tips maybe in short 💚
Thank you very much for your time and effort 😊
I definitely hope to produce more, just need to find the time 😄
If the monorepo route isn't for you, or you have an existing stack and converting to a monorepo isn't practical, you can always create a separate npm scoped library that holds your contracts and you import the package into each project. In other words, an SDK.
Yup totally!
Very high quality content! You have a very good way to take the viewer through the problem and how it is solved in the selected stack. Subscribed!
Thank you! I appreciate your comment 🙏
Good timing,, I'm doing research on this :D
💪💪💪
Amazing work, man. If I may request, could you possibly create a video on how to deploy an app like that on an on-prem server and cloud server?
Definitely a +1 on this pretty please
Yeah I’d like to cover deployments in general at some point, but in general: The end result of this setup is really just a single Nest app. You would deploy it just like any other node app.
Been waited for your new video buddy! It's always good to see you back.
Thanks! I’m looking to produce more consistently, it’s been a struggle haha
Is'nt that what trpc is supposed to do?
In terms of solving type-safety yes it’s one of the solutions although ts-rest takes a slightly different approach, e.g. it allows you to design your API as you would normally with REST. If I were using NextJS here I’d probably consider trpc however for NestJS ts-rest has a much better first class support for it. Also trpc defines the API implementation as the contract whereas ts-rest keeps it separate. There are some benefits to that.
ts-rest.com/docs/comparisons/rpc-comparison
trpc does it better than a neutral contract. with trpc your "source of truth" is the backend and you only need to match the frontend to adhere to it. with this setup the "source of truth" is external to both frontend and backend and any change to the contract requires changes in 2 spaces, not just 1.
Like I said, it’s just a different approach with its own tradeoffs. There is no black and white “better” for every situation, e.g. from the link I posted above they talk about a good example:
“One example of this is with NX, in NX you can rebuild only "affected" packages, however, if you export your contract (e.g. tRPC) from the backend, your front end will need to be rebuilt as well. ts-rest negates this issue by allowing (in NX) for a library for the API contract to be created, this then means the only case in which the front and backend need to be rebuilt is when the contract changes.”
Do understand that I am personally not saying either one is better, just that in this specific setup ts-rest has much better direct support for nestjs (that I’ve seen, I could also be wrong). Both are great tools.
Contract first is also a valid approach which both client and server must adhere to. And in this case neither backend or frontend would own it. In the non-node world it’s not uncommon to do it. One advantage here is that clients can use mock data on contracts to already start testing without waiting for the backend implementation to be done.
I am really interested watching your videos. Keep it up!
thanks, glad you’re finding the channel useful!
@@mariusespejo I am watching the all videos on the channel!
so basically it's review on how to use ts-rest, nice video like your quality that you highlight things and nice voice
Yes but in combination with making it work with turborepo, a couple folks in the comments were asking to see that example. Thanks for stopping by!
Thanks for this video! Do you have an example/hints on how to dockerize this app to deploy using the docker image?
Could you please share the Github repo for this awesome setup, please ? 🙏
+1 on this, pleaaaaasseeeee
Thank you, interesting concept. I really like this monorepo approach. I belive we can achive something similar with OpenAPI as a contract and we can generate the models / api client. It would be nice to have some generator, which would give us the controllers with DTO validation already.
You totally can do that, but writing the contract in Typescript provides the best experience in my opinion vs writing OpenAPI spec by hand, there is no codegen necessary because we’re already writing in TS to begin with. Btw if swagger docs is the requirement, you can also generate openAPI from the ts-rest contract.
@@mariusespejo
How can one generate openAPI swagger docs from the ts-rest contract? And will it be accessible from the /docs route?
Thank you for the awesome video.
@johnisutsa1641 ts-rest has first-class support for it, you can see usage and examples for Nest and express below. And yes, it’s up to you which path you host it on
ts-rest.com/docs/open-api
pay attention that the manual for turborepo 1.x but if you install it now you will get by default turborepo 2.x and it has many breaking changes.
Thanks for callout!
Love this stack. Good vid!
how can i combine multiple `s.router` objects?
Are you talking about the contract routers? You just nest them inside another one, so like you need a root router with keys to other nested routers if that makes sense
@@mariusespejo thanks, i just figured it out the other day.
Make full project tutorial for movie streaming api,food delivery,etc...
Great video.
I'm interested to know what application are you using for drawing on canvas and writing document in the same place? I've been looking for something like this!
This was eraser.io I was actually trying it for the first time, check it out!
thank you! does ts-rest set up work with angular too ? Any guidance / link etc. would be super appreciated! thanks again. (I did not not see angular support in the docs but google AI says it is possible so was hoping to get your take / input)
The base client is based on Fetch API so it should be agnostic to any client
Hi! A question: is ts-rest full compatible with every NestJS functionality like pipes,guard,middlewares,interceptors? did you find any problem using Ts-Rest with NestJS? thank you!...
They definitely should be on the single handler approach, since that’s a 1:1 mapping to regular controllers. Multi-handler might make things more complicated if you need to have those decorators at the method level. But other than that the only thing they call out in docs as not supported is version and global prefixes
Great video, thanks! How about input validation and swagger? Is it possible to implement them?
Yes you can generate openapi document from the contract, and nest can generate swagger docs off of that. And yes input validation is also supported
packages/api-client should be named packages/api-contracts? Otherwise it gives an error
Is my assumption correct that for large applications, using a monorepo might not be the best choice due to potential coupling issues? For instance, if we decide to create a mobile application, we might face challenges with a monorepo setup. Similarly, if we want to split our server into microservices, having a monorepo could complicate things. On the other hand, is it true that a monorepo setup is more suitable for relatively small projects?
I think that it depends on your overall pipeline and deployment infrastructure. Fun fact for example, I believe google stores all of their code in a monorepo. Personally I would think of monorepos in a scenario where code sharing is beneficial, but like with everything it has pros and cons, and you need to pick based on which tradeoffs are okay with you. A native mobile app for example I don’t really see benefiting much from a monorepo where the other apps in the repo are in totally different languages and technologies.
I was just searching for a tutorial like this. I have one question. You are not using DTOs because you set a lot of constrains in the controller with the contracts, but in the communication between controllers and services or services and services you still need them. I guess. There's a way to directly derivate a DTO from a contract?
Now that I think more about it, can it be used to validate input on the frontend and generate error messages? Like "this field is required"?
The “library” in this video where we store the contract can also export other things, e.g. you can export the zod schemas that you create or you can export the type inferred from those schemas. That basically gives you the “shape” of your DTOs that you can pass around between services. And yes technically you can also import zod schemas on the frontend and use it for validation. E.g. in react you can use it with react-hook-form which has support for zod
Hey great vid! Do you have a video on how to use nestjs serve static with this setup?
Thanks! I covered it in an on older turborepo setup vid, take a look here:
ua-cam.com/video/nY0R7pslbCI/v-deo.html
Please can you do a tutorial of combining nextjs and nestjs
It’s basically the same idea, but now you deploy with two servers. What are you looking for exactly?
What is the tool you use for diagrams in this video please
Eraser.io it’s pretty cool!
Nuxt 3 is ruling the end-to-end type-safety, no extra packages needed, just saying it's worth checking out...
Are you saying nuxt can create type-safe APIs on it’s own? I couldn’t find anything with a quick doc/google search but I’m not as familiar with it. I do know with NextJS server components also solves the problem since you can make backend calls right in component code
How do you handle cookies on the server with this setup, the ts-rest headers don't seem to work as intended, and also when you add the monorepo internal package to the nestjs' dependencies it messes up the transpiling and adds other folders from the root of the monorepo to the dist folder. I did some hacky stuff to go around it but i'd love to know if there are optimal ways of handling both of these issues
First of all thank you for content of such quality.
Could you also share the GitHub repository? I'm encountering an issue when attempting to import the api-contract package into the Nest server. I'm receiving the following error message: "Cannot find module 'api-contract' or its corresponding type declarations." Importing with a relative path resolves the issue: "import { contract } from './../../../../packages/api-contract/dist';". Interestingly, importing in the Vite project functions correctly. I've added the dependency to both projects' package.json files.
I have now the same issue, have you resolved it? But for me it doesn't work not for app, neither for client
Have you encountered any errors when importing the react mui library to the frontend project? It seems it does not play well with the rollup commonjs plugin
Sorry I haven’t used mui
@@mariusespejo Hey sure no problem. For anyone having issues with MUI what worked for me was to exclude the node_modules folder in the rollup commonjs plugin like this: commonjs({ exclude: [/node_modules/] })
what if working as a team front-end and back-end, and the front-end cannot be allowed to access the back-end source code?
Monorepo is only for the benefit of having the code in the same place, sounds like you have a scenario where you probably shouldn’t use it
@@mariusespejo I see... Thanks man..
Hmmm... I think I prefer a monorepo + nestjs graphql + codegen urql to share typescript type
Yeah not a bad approach, graphql has its own pros/cons
Hey dude,ypu are perfect in nestjs.can you do a microservices tutorial by nestjs?
Definitely on my todo list
@@mariusespejo i am waiting for it dude.
Create something like industrial projects in nestjs how it is use in industry 🙃
How should be the monorepo setup if I want to make a server side rendered web app so nextjs with nestjs(using both these tech together does this make sense)? What are the pros and cons of using ts-rest over something like graphql, trpc ?
If you decide to use NeXtjs I would recommend you first try to see if you can get away with just doing it all in that one application. Utilize making direct backend requests (e.g. database calls) in Server Components within the new App Router. If you find that you need a much more sophisticated backend, NeStJS will provide you with a lot more flexibility and yes you can still follow this exact setup. It just would mean that in your deployment strategy you will have to think about having two applications to run.
Your second question I think honestly would be best explained in another video but if I can think of a couple key points:
Ts-rest and trpc are alternatives to each other. Ts-rest focuses on REST (meaning any client can still make requests the traditional way even without an api client) and tRpc is very much rpc-like (hence why both are named this way). Ts-rest keeps the contract as an external source of truth, whereas with trpc the API implementation itself is the source of truth. There are pros/cons to these approaches but hard to get into in a comment here.
GraphQL I feel like is an entirely different beast. Think of it more like a complete alternative to REST, and that comparison alone is a pretty loaded topic. It does not however solve type-safety like ts-rest and trpc does because it defines the API schema in an entirely different language. So the only way it could help with typescript is via auto generated types. You’ll notice that ts-rest for example we didn’t have to generate anything, it’s already in typescript.
Anyways hope that gets you some high-level differences, I’ll think about covering this in a follow up video
Hi @MariusEspejo , thanks for the video ,i really enjoy this setup , i have been trying to implement it in my own project and have trouble setting cookie headers , usually i would set it with response.setHeader, do you have any idea on how to achieve the same outcome using ts-rest ?
As far as I know in ts-rest contracts only request headers can be defined upfront, but I don’t see any reason for it to affect response headers.
@@mariusespejo Thanks for your response :) , In the end i've found a solution so we need to pass the passtrough option to true in the Res anotation for tsHandler to maintain control over the response handling.
@Res({passtrough: true}) response
Thanks again for your content and taking the time to answer my comment. Keep it up :D
Nice good to know!
Hi,Can you still use all Nest features (Like Guards etc.)or is there some limitation there?
Good question, ts-rest also supports “single handler approach” meaning if you want to have individual controller methods for each route you can still do that. The effectively means you can still individually add extra decorators such as guards. Also any global guard should still work I believe
ts-rest.com/docs/nest/#single-handler-approach---easy-migration-and-flexibility-%EF%B8%8F
How are you going about deploying this stack? Nextjs + trpc has been so simple with vercel.
I only briefly mentioned it in the video but since the React client here is a SPA, you can actually have the Nest server statically serve it in production so that you only have one server. In that scenario, it’s just as easy. Deploy it anywhere you can deploy a node app.
Btw it’s worth mentioning that NextJS with the app router and server components already solves problems with lack of type-safety, you might not even need trpc unless you have route handlers. Anyways NextJS in general is the alternative to this whole thing, however NeStjs opens you up to a much more mature API framework with lots of possibilities.
@@mariusespejo thanks for the reply. I definitely agree Nest is more robust.
Hi, can you elaborate/give advice how would one go about hosting this setup but insted of react its nextjs with nestjs,thanks! Not much experience with hosting in general
I would recommend learning about hosting nodejs apps and what that generally requires and what different options there are. There is no one way to do it, the answer is always “it depends”, specifically on your requirements. It’s not really easy to explain in a comment because you have so many options depending on what balance of complexity vs cost you want. For example you can host on VMs on the cloud and configure everything yourself, you could do a containerized strategy like with docker, you could go serverless… lots of different platforms which allow you to do these things
With a nest + next setup you effectively have two apps to deploy… so you want to decide do you want to run both in one instance of a machine? Do you want them separate (e.g. so each one can scale on their own)?
Sorry not really giving you a solid answer here but hopefully that gives you some starting points. Will think about a video covering various deployment options
How do you implement core nestjs functionalities like UseGuards for specific routes in this case?
So in this video I showed ts-rest’s “multi-handler” approach for maximum type-safety, but they do also allow “single-handler” approach which would bring you back to traditional single controller method per route, which should allow you to add any other decorator that you need for the method. Although I haven’t tried that myself specifically with guards
Thanks for the tutorial. I'm getting an error on the 'async handler()' part of the API implementation "The inferred type of 'handler' cannot be named without a reference to '.pnpm/@ts-rest+core@3.33.0_zod@3.22.4/node_modules/@ts-rest/core'. This is likely not portable. A type annotation is necessary."
Have you encountered this issue or do you know how to resolve it?
Not familiar with that error but it might be specific to pnpm monorepos, you might need a slightly different tsconfig setup than mine
Take a look through this thread: github.com/microsoft/TypeScript/issues/42873#issuecomment-906308997
@@mariusespejo thanks for your reply, that thread was really helpful!!
Do you have experience with next.js instead of react? I followed but used next.js,works also but now thinking about hosting,also can't get react query to work on server side in next..any opinion or experience?
I do use Next in some current projects. Honestly if you are using NeXt, try to see how far you can get with using just Next on its own. If you utilize Server Components in the new app router, you’ve already got type-safety right there. No need for actual api routes. If you do end up needing a more sophisticated backend and need to introduce a second application (NeSt in this case) then yes this setup totally still works, it just means that your deployment strategy will require spinning up two servers. Regarding your question on using react-query, two things: 1.) you DON’T have to. Ts-rest can also create a barebones client which just utilizes fetch under the hood, so you can use that in Server Components. 2.) If you do decide to use react-query in NeXt, you will have to do it in “use client” components. So yes it can still work and is still useful in a lot of situations
@@mariusespejothanks,much appreciated!
How do you achieve type safety?
You use a typed language like Rust, C++ or Go
Yeah I think you missed the point of the video but thanks for commenting for the algorithms 👍🏼
I don't think it will work in with other stack except node JS. this video is nice to get updated with new tech but it doesn't guaranteed to be useful in any situation. esp. if you're not using TS in backend.
Nothing is guaranteed to be useful in every situation. The point here was to have end-to-end type-safety across the entire stack. Most modern web clients are written in typescript. If your backend isn’t also in TS, it means that you would have to generate TS-compatible types to pull it off which is not great.
can i get your mai id
Love your content! How can I combine the types from the api-client package with a mongoDB + mongoose model?