Migrate to Next.js App Router

[CodeWithShreyans]

I've started the migration to the App Router #50.

A couple things that need to be done:

• [ ] Replace the getLayout functions with nested layouts.
• [ ] Put use client on all pages for now and slowly migrate.
• [ ] Update any dependencies that have added support for App Router.

[gamedevsam]

We should be careful to only use functionality that is compatible with next export: https://nextjs.org/docs/app/building-your-application/deploying/static-exports

AppRouter is fine, but I recommend not tying this project to any backend functionality from Next.js, so we can be backend agnostic and easy to self-host.

[tmyracle]

We should be careful to only use functionality that is compatible with next export: https://nextjs.org/docs/app/building-your-application/deploying/static-exports

AppRouter is fine, but I recommend not tying this project to any backend functionality from Next.js, so we can be backend agnostic and easy to self-host.

I agree in principle, but it would be great if we could get it to a point where we can have a deploy with Vercel button on the repo and people can click and go. Ideally you'd have the option to hit the easy button or go crazy or deploy on bare metal if you want to dev ops it yourself.

[CodeWithShreyans]

@gamedevsam next export afaik is to make a static export of you app. If we just wanna self host somewhere, that doesn't need to be static. There are plenty of tools like SST that bring the experience very close to Vercel.

[ExplorerAadi]

@DestroyerXyz I don't think upgrading to canary would be a good idea, we should upgrade to a stable release and the eslint-config-next should upgrade too because ideally it goes hand-in-hand with next version.

[CodeWithShreyans]

Yeah can do that @ExplorerAadi, Next's canary versions are usually pretty stable but sure we can go with stable for now, not considerably different. As for eslint-config-next, yes I'd be upgrading that and any other packages we need to along with it.

[gamedevsam]

@gamedevsam next export afaik is to make a static export of you app. If we just wanna self host somewhere, that doesn't need to be static. There are plenty of tools like SST that bring the experience very close to Vercel.

I highly recommend avoiding this path, and sticking with Next.js's pages router and keep using Next.js as we are now (in other words use Next.js, but export its output and serve it as a static bundle). This gives us maximum flexibility and avoids making the codebase even more dependent on Next.js (it should be relatively easy to eject from Next.js to Vite or some other technology if Next.js decides to go in a direction we're not too happy with in the future).

We have a simple Express server now serving the output of Next.js as a static bundle along JSON APIs. We get to benefit from Next.js's file based routing and other nice utilities, but we're not too deeply tied to it, and get to keep maximum control of deployments without adding additional complexity like SST.

Reading this PR I get the feeling you're pushing to future proof the repo by adopting new shiny things Next.js is providing. I urge you and @Shpigford to keep things simple, avoid chasing shiny features and avoid making significant changes without clear, tangible benefits for users and favorable cost / benefit dynamics.

This PR delivers no benefits to users, and does not have favorable cost / benefits in my opinion.

[gamedevsam]

Next's canary versions are usually pretty stable but sure we can go with stable for now, not considerably different.

I don't agree with this perspective. We want to ensure stability at all times, being on of Next creates an unnecessary risk (even if it's a small risk).

[gamedevsam]

We should be careful to only use functionality that is compatible with next export: https://nextjs.org/docs/app/building-your-application/deploying/static-exports AppRouter is fine, but I recommend not tying this project to any backend functionality from Next.js, so we can be backend agnostic and easy to self-host.

I agree in principle, but it would be great if we could get it to a point where we can have a deploy with Vercel button on the repo and people can click and go. Ideally you'd have the option to hit the easy button or go crazy or deploy on bare metal if you want to dev ops it yourself.

I don't think this is a use-case we should be facilitating for. You can't just deploy on Vercel with no configs since you need a at least a DB to run the code. With that said, you could host the UI on Vercel very easily, but you'd still need to host the API Server & DB somewhere else.

[Shpigford]

I don't think this is a use-case we should be facilitating for. You can't just deploy on Vercel with no configs since you need a at least a DB to run the code. With that said, you could host the UI on Vercel very easily, but you'd still need to host the API Server & DB somewhere else.

To be clear, we absolutely want to work towards the use-case where you can click a button and deploy everything such that you've got a deployed app with minimal other work besides clicking said button.

[gamedevsam]

I don't think this is a use-case we should be facilitating for. You can't just deploy on Vercel with no configs since you need a at least a DB to run the code. With that said, you could host the UI on Vercel very easily, but you'd still need to host the API Server & DB somewhere else.

To be clear, we absolutely want to work towards the use-case where you can click a button and deploy everything such that you've got a deployed app with minimal other work besides clicking said button.

Agreed, but perhaps on Digital Ocean, Heroku or other places where you can where you can deploy Node servers to (not just Next.js applications). Having a Dockerfile / Docker compose would also go a long way to making this super easy to deploy and self-host.

[CodeWithShreyans]

Closing this in favour of #214.