Nuxt support with payload v3

[casualmatt]

Hi,

Super fresh in the payload world; I used supabase, strapi, and directus in the past, predominantly with Nuxt.
What will be the support for Nuxt with payload v3?

1. From what I understood, Payload Admin UI/Rest API will be based on Next, but will Next have a specific feature that Nuxt cannot have?
2. Do you plan to support Nitro as a Rest API Layer or provide a guide to use Payload with it? (Nuxt can execute nitro API endpoint as a function if SSR is enabled, and it makes everything much faster).
3. More broadly, what will be the support you think to have for nuxt/vue?

Ty, for your time and thoughts in advance.

Matt.

PS: I'm one of the maintainers of the Directus-Nuxt module, so if there needs to be a Payload module, I'm open to it.

[DanRibbens]

Hey @casualmatt,

Thanks for posting your questions here! Your comment nudged me to remember that we had a PR for the live-preview feature for vue that needed to be merged. A special thanks to @ChrisGV04 on the help with that.

I've only done a little bit of Vue prior to building Payload, so I may need backup the Vue users in our contributors here.

1. From what I understood, Payload Admin UI/Rest API will be based on Next, but will Next have a specific feature that Nuxt cannot have?

Since Nuxt can also work with server components, the answer is no. You can do anything with Nuxt that you can do with Next. The only difference is that Payload needs to have next at the moment to build and serve the admin UI and APIs leading to a bit larger of an app footprint having both.

2. Do you plan to support Nitro as a Rest API Layer or provide a guide to use Payload with it? (Nuxt can execute nitro API endpoint as a function if SSR is enabled, and it makes everything much faster).

I'm not familiar with Nitro, this sounds like something you could experiment with. I'm not sure if this could be implemented in a way that wraps the current Next endpoint handling for the API requests. To make the routing go through Nuxt, you would have to probably build a similar package to our next package https://github.com/payloadcms/payload/tree/beta/packages/next. Where I'm not sure from routing is how you'd go about serving the admin UI being all React and Next currently. You could experiment here, I'd be interested in what you find out.

3. More broadly, what will be the support you think to have for nuxt/vue?

We fully expect people to continue building frontends with Vue on top of Nuxt as people in the community have been doing. We even have the live-preview package ready to let you render your Vue frontend and see the outcome of your edits live in the admin interface.

I'd love to see a community contribution of a Nuxt/Payload project in our own examples along with a community blog post. I am sure people coming from Vue would find this very useful.

The end of the road for us on Vue support that isn't likely to change, is that the admin UI is totally based on React and so writing custom Vue components to work within the admin UI isn't an option. Outside of that, you can really do whatever you want to integrate Payload with other frameworks.

I'd love to hear your thoughts on all this and especially any easy wins where Payload can extend the olive branch to the Vue community to be a more open product.

Thanks!

[casualmatt]

Here's the revised version of your message with the added point:

Hi @DanRibbens,

I'm looking forward to experimenting more with Payload v3 once it exits beta. My primary concern has been whether Payload might leverage specific Next.js features in a way that could complicate integration with other frameworks.

Regarding Nitro, it's interesting to note that it now serves as the server engine not just for Nuxt, but also for Solid via Solidstart. My interest in using Payload with Nitro, particularly with Nuxt, is to streamline operations by reducing unnecessary API requests during SSR or SSG processes. Here’s how I envision the setup:

• I would deploy the CMS UI as a standalone application at cms.domain.com, avoiding the need for a serverless environment.

• For a website running on Nuxt or Solid, it could directly access its backend through Nitro using routes like /api/[path], similar to how one would structure Express routes having a catch-all path, and providing the event to payload directly.

This is important because, in Nuxt, any API endpoint is called as a local function during SSR or server component rendering to reduce latency. But, once the page is Hydrated and you get to switch to full client-side rendering, nuxt will fetch new data from the rest API endpoint. as a developer, I didn't have to do anything; it is all done by Nitro/Nuxt, and the useFetch composable.

I believe this integration approach is feasible, primarily since Payload still supports using Express for REST or GraphQL API endpoints. I'm keen to explore this further and would appreciate any insights or suggestions you might have.

Thanks for engaging in this discussion!

[DanRibbens]

What you're describing makes sense. I'd need to learn more if I were to plan it myself. It seems like you know what is needed and I would be happy to review a proof of concept approach if you come up with one.

Without knowing what it looks like I can't say how it fits in, whether it's an example, blog post, package or plugin.

I also want to further understand what the overall benefit is. Is it speed and performance or DX your after, both?

[casualmatt]

I will probably try to do a draft after v3 is out; I'm super excited to try, to be honest; it is a bit of time that I'm looking for an OSS software to replace BSL solution, and strapi was never ideal due to how they manage the end user permission.

Is it speed and performance or DX your after, both?

Probably both, having just 1 composable to use; in this case, useFetch makes it easy to use payload with REST API.
Performances are also a good point because, in this case, I never expose payload directly, even in client-side rendering, and compared to the server component, nuxt doesn't need to render anything, just fetch the data and serve it, saving resources.

[DanRibbens]

Ok, sounds great! Tag me if you need anything.

[casualmatt]

Quick question: do you plan to have a helper function that accepts web request object and reply web response or accepts node.req and replies with node.res ?

--> nitro event properties

If that's something you are building for your express compatibility, then to implement nitro is 1 line of code, and it should also allow the support (even in the case of node API) to run on a bun/deno and all the serverless platforms.

If not, I will have to build something similar to your next example or use a middleware to interact with it.

[devkon-at]

Hi @casualmatt,

I am also looking into integrating Nuxt with Payload. I tested a straightforward approach where i run payload and Nuxt with the same payload config and use payload inside the Nuxt server routes as an ORM, which gets me the type information on the backend aswell as the frontend with useFetch.

This works in a (very) simple test case inside Nuxt without hitting any immediate blocks with Next/Nuxt compatibility: https://github.com/devkon-at/test-nuxt-payload
Although Access Control is something that will be hard using this approach

I think that this could be amazing for the Nuxt/vue community especially given your experience with Directus, please update your post if you think about building something like this.

[casualmatt]

Hi @devkon-at,
The best would be to have a catch-all route, and that's it, but I'm not a fan of working without docs, so for now, I'm waiting.
(btw, use /api not /routes, /routes is at the same level of vue pages and can cause some issues if you are not organized with your code and naming).