How do we use different load() for clients and servers?

[sshockwave]

Hi, I'm new to Svelte. One of my projects is switching from React to Svelte for better performance. Thanks for all the work!

Currently, we can load data in +page.js and +page.server.js. From what I read from the documents, +page.server.js is always run (if present), and then +page.js is used to transform the server data into actual data to be passed into +page.svelte, either run on the server or in the browser.

Now let's consider a use case where we need to calculate something based on a user's account. A client can always store identity information using Web APIs. A server can identify a client using cookies and query the database for extra information. However, the cookies (and everything we can use to identify a user on the server, e.g. event.locals) are available only in ServerLoadEvent / +page.server.js and not in LoadEvent / +page.js. So the logic for the server must be written in +page.server.js, which causes a database hit on every render, regardless of whether the computation can be done solely on the client side.

I haven't come up with any efficient strategy for this use case using the SvelteKit framework. Here are my ideas:

• Always works but with performance regression:
  • Allow a request + a database hit on every page access.
  • Disable SSR ¹
• Framework enhancement needed:
  • Allow cookies, event.locals, $state(), or other server/client-specific states to be synchronized automatically along with the request/response ping/pongs. For example, add read-only Cookies to the PageLoad interface in +page.js so that the server can access the same information as the client. Then we can have different logic for servers and clients using (await import('$app/environment')).browser.
  • Add a +page.client.js that returns the same Data as +page.server.ts. When a page request occurs on the server, run +page.server.js to populate the data; when a page switch occurs in the browser, use +page.client.js. Finally, use +page.js for unified transform.
  • Allow the client to choose whether to disable +page.server.ts before a page switch in the client.

I would appreciate it for suggestions & references to existing solutions!

Footnotes

1. This can be beneficial if the server computation requires a database query. But it worsens time-to-first-paint in the converse case. ↩

[david-plugge]

Hi, welcome to svelte^^
If i correctly understand you want to use different data sources for server and client? If the client has the necessary data stored already it should be used instead of doing a request which results in a DB hit.

In that case you can not really use server load functions at all i assume since you need to check on the client before requesting from the server. Check out this example in sveltelab: https://www.sveltelab.dev/ss4xsa91vlq3l8v?files=.%2Fsrc%2Froutes%2Fdata%2F%2Bpage.ts

This approach still works with ssr but will always do a DB request if the /data page is openened as a full page navigation. On client side navigation it will check if the data exists and falls back to the server request.

I hope this is helpful to you!

[sshockwave]

Thank you @david-plugge for your response! It feels warm to have an active community.

I believe that you understood my use case well and your example definitely solves the problem for the project. Thank you again!

Here's more to the discussion: It is almost perfect though. Let's demonstrate the data path of your solution here:

# page navigate from server
server load()
    server fetch()
        server db hit
    -> server data
-> client

# page navigate from client
client load()
    client finds data locally
-> client

In comparison, the most ideal data path for the server side is:

server load()
    server db hit -> server data
-> client

The ideal path reduces one fetch() request abstraction and the server can call the corresponding service function directly. The fetch abstraction is productive in cases where both the client and the server want some data on the server. In the above case, however, the server and the client are already doing different things anyway (which means different code) and we shouldn't need to stick to the universal fetch() interface for that.

How does it sound? Is the performance or productivity gain worth it?

[david-plugge]

The fetch function that is passed into load functions is doing a bit of magic here. Take a look at https://svelte.dev/docs/kit/load#Making-fetch-requests (3rd bullet point). No additional network requests are made.

[sshockwave]

Wow. This is pretty powerful and I can already think of ways to simplify other parts of the server, too. And more REST-compliant. Thank you!