Usage with Next@13

[yakovlev-alexey]

At the latest Next.js Conf Next.js 13 was announced - https://nextjs.org/blog/next-13. It brings a lot of (experimental) changes including the introduction of Turbopack and (most notably) new routing system. You can check WIP documentation here - https://beta.nextjs.org/docs/app-directory-roadmap.

I figured it would make sense to create an issue where all observations and issues with nest-next used with Next.js 13 would get collected. As the issues arise and get solved (as well as the roadmap for Next.js get fulfilled) I will work on updating my tutorials and example repo.

I propose using this issue to discuss what changes need to be made in next-next to properly support new Next.js version.

---

From the brief experimenting I had (in a separate branch in nest-next-example) I discovered the following:

1) pages directory works as it did previously without (new) issues Can't really say much here - it works and thats fine 2) Turbopack can not be used with a detached server at the moment Official docs state that you may enable Turbopack by using next dev --turbo. However there is nothing on the topic of enabling it in a detached server (when creating a Next instance manually). I did not try looking at the actual sources for the Next server. It is possible that there is an option to enable it except it is not stated in the published types. Still I think it's worth creating an issue at Next repo. However I do not think it will break anything in nest-next 3) app directory can be used It will take some time to fully play around with and test all the new possibilities. The most important part is SSR and data fetching. I made the following observations:

• Data returned from Nest controllers ends up in searchParams props in pages (similar how it ended up in query props in previous versions).
• params props in pages gets somewhat malformed with no useful information in it (similar how it worked with previous versions). For example I navigate to /blogs/1, app directory contains app/blogs/[id]/page.tsx and params would be { id: '[id]' }.

• Nest controllers now get called on client-side navigations. Now this changes everything. Previously when (re)loading the page for the first time a Nest controller would get called. Later when you clicked a link in the browser an internal /_next/ endpoint would get called to invoke getServerSideProps function and recieve its results given the arguments (e.g. path params). Now when you click the link the actual path gets fetched.

  For example I navigate to /blogs/1 in the browser and /blogs/1 Nest controller endpoint with Render decorator gets called. It properly proxies the request to Next instance and it starts streaming data for React to update the page. This means it is now possible to use Nest services to fetch data directly from DB for your pages. Still it would take some time to discover the best way to leverage new layouts, templates and other files in app directories. 4) Pages have to manually be set as server-side rendered. Next.js still supports SSR, SSG, ISR for your pages. As previously SSG that fetches data from Nest server fails to build since during the build process local instance is not up. I do not think this is a problem. However now pages (and layouts) without path params render statically during build time by default. I discovered that you can call headers or cookies from next/headers to manually tell Next you want to render this page/layout during the request.

I want to say that I am excited by the features brought by the new Next version and eager to see how they can be leveraged in Nest+Next stack. @kyle-mccarthy I want to ask you to share your thoughts on the new Next version and plans for this project in this issue as well. I may propose being a co-maintainer and introduce changes required for Next 13 since I have a bit of experience with nest-next and its code.

[rubenvereecken]

For what it's worth, I second @yakovlev-alexey as co-maintainer. He obviously knows his way around nest-next.

[kyle-mccarthy]

I would totally be open to making you a co-maintainer. Do you have any specific proposal in mind? Part of me wonders if setting up nest as a standalone application and exposing a router from nest-next to handle all the api routes would be best.

[yakovlev-alexey]

I would start by introducing a test suite testing the following:

• static pages
• getServerSideProps, getInitialProps, etc with context checking (values returned from controlled should end up in query)
• paths with single and multiple route params, nested and at the root
• static paths beside paths with routes params like in #93
• usage with baseUrl and other next.config.js options (asset url I believe also needs testing)
• dev mode and production builds

It would also make sense to develop tests in such a way that would allow us to run them with specific Next versions (a new Nest version is unlikely in my opinion so no need to specify that). This will also open up the possibility to run CI in a matrix to effortlessly make sure all supported versions work.

---

Setting up Nest as a standalone application seems like a cool idea. Though I think it offers an entirely different approach to Nest and Next integration. Want to play around with this idea a bit and see how it could work.

In this particular case perfomance could also be important. From my experience debugging Next it strongly leans toward serverless. Even when running as a server (detached or not) it will dynamically require built pages (Next emits both server and client bundles for each page with server being the larger one with SSR methods and their deps). Running standalone could end up creating a new Nest standalone app for each request.

That might have changed since my testing but I believe Next maintainers are very opinionated on Next usage and as a commercial company try to sell Vercel deployment by not introducing features that would help using Next effectively outside Vercel.

Monkey-patching Next detached server could work...

I think it makes sense to create two new separate issues on tests and Nest standalone usage and continue conversation there. And keep this issue for Next@13 and app directory shenanigans.

[TheLogan]

I followed the tutorial, here https://dev.to/yakovlev_alexey/creating-a-project-with-nestjs-nextjs-3i1i

Is there a solution for the whole getting '[id]' rather than the actual id value in the query, yet? :) As in, my query is {id: '[id]'} rather than {id: 1}

[yakovlev-alexey]

@TheLogan id issue is fixed in #93

[techeng322]

I have this issue now in Next.js 13.5.4

[mansidhall-CAW]

I am getting the same issue as @brittneytech818 While running next.js server I see no error, but while starting nestjs server I get this undefined nextConfig error for next versions 13.0 and above If I use a version lower than 12.0 then next is unable to detect @types/react So basically it works for only 12.0-13.0 (13.0 excluded)

[yowayb]

Does #111 fall under "app directory shenanigans"?