I'm really happy that you launched next-payload!!
Out of curiosity, why did you decide to use the 'template approach' and copy over all of the logic into the developers' project instead of a catch-all route similar to next-auth with a singular, comprehendible file? While I appreciate the flexibility this approach provides, I don't think the average developer desires to make any changes to the copied files. How are you planning to communicate changes that have to be made in case of an update to the package?
I've always valued Payload for its simplicity and the great DX, but I've found that the 'next-payload' package doesn't quite align with that philosophy... Could you provide some insight into the benefits and considerations that led to this decision?
Hey @leonardstruck these are all great questions! I have not personally seen what
next-auth
does but it sounds interesting. But here's our thinking:
Vercel themselves say that bundling everything into a single serverless handler is an anti-pattern (
https://vercel.com/guides/using-express-with-vercel) and I tend to agree. Specifically, bundling into one endpoint will make it harder to keep our serverless JS bundles
as small as possible.We are going to continue to move toward minimizing bundle size, which will improve cold starts and then in the future allow us to deploy as edge functions. So the name of the game is to keep everything as deliberate as possible.
We are actually about to release an update to the
next-payload
package that does exactly what you suggest - keep the handler logic
in the package itself, so you don't need to re-runnext-payload install
. This will be live within the next 24 hours - and when it's live, you won't have to ever run the install command again and don't need to worry about having the logic in your app itself. Instead, you'll still have stubbed out endpoint handlers, but they will be very concise and the bulk of the logic will exist in the package itself.
Last note - I definitely agree that the DX here is a bit wonky, and I wish there was a cleaner way to bind routes / handlers / inject pages without having to actually have a file present in the repo. I'd be pumped if there were a way to inject those routes / handlers from the Next config itself, but we couldn't find a way to do that!
Hey James, thanks a bunch for the insights! Your commitment to minimizing bundle size makes total sense to me. I'm happy to hear that you're about to release an update to the package that will make things even better for developers!
Any update on this release? Just about to start a new side project and would love to have this
working on it now
you should be able to use it right now, and you'll just need to re-run
npx next-payload install
after our updates
Oh awesome, so it'll handle un-doing a previous
next-payload install
?
yes
Winner, not waiting around then
Star
Discord
online
Get help straight from the Payload team with an Enterprise License.