-
As I see there are some benefits when using the Local-API over REST. My current setup is a pretty default React SSR-Setup with express & payload as the backend and React rendered on now I wanted to use the Local API inside the React application, but as it needs to be hydrated by the client I see no way in providing the react application with the payload instance to use functions like .find()... is there currently any solution to this problem or can you suggest which frontend library works best with SSR backends for this use case? Thanks in advance for any suggestion, clarification, or help. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
Hey @Aruinerk — this is a great question! One of the tough parts about loading Payload in an SSR app that you roll by yourself is that you need to ensure that no server-side code makes its way into your client-side bundle. For example, Payload itself loads many Node packages, like Express, Mongoose, GraphQL, and other dependencies. You don't want your client-side bundle bloated with this code. Not to mention—some Node packages will simply break your code while running in the browser due to needing filesystem access, etc. However, some SSR frameworks like NextJS come with solutions to this packaged in. Next, for example, will automatically eliminate any dependencies that are only used in Take a look here: This tool shows you how Next eliminates code from your client-side bundles. It's basically magic. Also, here is a boilerplate that shows how to use NextJS and Payload's Local API in a single Express server: Take a look specifically at the That said, you can use local Payload methods inside of NextJS' Last note—if you're working with static rendering in general, using Gatsby or similar, the Payload Local API really only offers marginal benefits to you because at build time, to fetch say, a page, the Local API will only shave off HTTP transfer time, ~30-100ms, from your requests.... and then maybe some latency to and from your database wherever it's hosted. Meaning, the REST / GraphQL APIs will take a bit longer to fetch, but hey, you're only fetching at build time and it won't impact your users. TL;DR I LOVE NextJS. And it pairs very well with Payload. If you need Local API and SSR, Next is the way to go. Otherwise, I'd just use the good old REST / GraphQL APIs. |
Beta Was this translation helpful? Give feedback.
Hey @Aruinerk — this is a great question!
One of the tough parts about loading Payload in an SSR app that you roll by yourself is that you need to ensure that no server-side code makes its way into your client-side bundle. For example, Payload itself loads many Node packages, like Express, Mongoose, GraphQL, and other dependencies. You don't want your client-side bundle bloated with this code. Not to mention—some Node packages will simply break your code while running in the browser due to needing filesystem access, etc.
However, some SSR frameworks like NextJS come with solutions to this packaged in. Next, for example, will automatically eliminate any dependencies that are only used in
g…