Combine all routes to 1 route handler

[thgh]

Some suggestions:

If I'm not mistaken, by wrapping all endpoints in separate routes, every route incurs a cold start. I would suggest to have one 1 route: pages/api/[...payload].ts that catches all requests.

Why still use the pages directory? It sounds like a route handler in the app directory would work too?

[jmikrut]

Honestly, that’s a damn good question. Vercel themselves say that bundling everything into a single endpoint is an anti-pattern. I can see why, because file size should be absolutely minimized for both serverless functions and edge functions. But yeah, it does seem like we could reduce the amount of cold starts if we only had one handler for sure.

This will become more complex once Payload further reduces its bundle size, however. The actual functions will need to be extremely small and each designed specifically for their individual task. We are making progress towards this and it won’t be long until hopefully everything will be on edge functions where cold starts won’t be a problem.

I wish we could use app route handlers, but unfortunately the API is so significantly different from express-like request and responses that a lot of the stuff we use, passport included, is 0% compatible.

I smashed my head against the wall for a good two weeks, trying to fit all of this stuff into App route handlers, rather than continuing to use the pages/api folder but I failed big time. Maybe in the future we can get that to work as well. Here’s hoping!

[thgh]

Thanks for the insight! How will edge functions improve cold starts? Based on the Vite bundler poc I thought that start time is most dependent on config complexity which poses a bottleneck in every environment. Reducing bundle size always helps though ^^

Haven't used route handlers myself, but did bump on similar issues with Deno. Could next-connect be the missing piece?

[jmikrut]

Edge functions are fundamentally different in how they are "spun up" when compared to serverless functions. A serverless function is basically just a tiny VM that needs to boot up before executing a script, but edge functions are literally just scripts that get executed.

I am sure I'm glossing over some things and not 100% correct here but supposedly edge functions almost entirely avoid cold starts, which is the big thing that I'm interested in there.

Also - - re: next-connect, I've looked into that deeply and have even opened up an issue:

hoangvvo/next-connect#220

We'll see if they add route handler support. That would be great if they did!

[thgh]

Played a little with it and got the basics working. Next up is wrapping express in a proxy and checking which methods payload actually uses.

[mattddean]

@thgh i have a bit of experience shoehorning things into route handlers. Let me know if you want to collaborate on this.

[thgh]

@mattddean perfect! I will create a PR later today on the next-connect repo. Would be cool if someone can poke holes in it.

[thgh]

@mattddean ^ here it is, do you think this approach could work?

[jacobsfletch]

Hi all, this repo will soon be archived because it's been merged into the main Payload repo here: https://github.com/payloadcms/payload/tree/main/packages/next. Payload 3.0 ships with native support for Next.js and is currently out in beta here: https://github.com/payloadcms/payload-3.0-demo. I'm going to close this issue now but feel free to keep the conversation going either as a GitHub Discussion or on Discord. If think issue persists, feel free to open a new ticket on either the demo repo or the monorepo with the 3.x-beta label, and be sure to include a reproduction so we can fix it faster.