What's a good way to refactor the api client to use SK's fetch?

[hsb-tonmoy]

I'm using a very similar approach in my app to this one: Sveltekit-realworld to make requests to my REST API. But, since the latest changes, I'm seeing weird behaviors in my app and some people have suggested to use the Sveltekit provided fetch to do my server-side fetches. I was just wondering what might be a good idea to implement that?

Maybe something like this but it gets kind of redundant:

....
....
if (server_fetch) {
		return server_fetch(`${API_URL}${path}`, opts);
	} else {
		return fetch(`${API_URL}/${path}`, opts);
	}

[thenbe]

I'd love to see a good answer to this question.

FWIW, here's the way I'm currently doing this. I'm not sure if a better pattern exists, especially with the latest changes. But the pattern I'm using is a remnant of the now deceased stuff & session (illustrated by Rich here)

Basically, I'm creating the api object in the top +layout.ts, then re-using that api throughout the rest of my load functions. What's nice is that the api object remains correctly typed thanks to the latest sveltekit moves towards type-safety. The only pain point is having to await parent in every load function to be able to use api.

// routes/+layout.ts
export const load: LayoutLoad = async ({ fetch, data }) => {
  const api = createApi({
    loadFetch: fetch,
    token: data.accessToken,
    roleId: data.user.roleId,
  });

  return {
    api: api,
  };
};

// routes/dogs/+page.ts
export const load: PageLoad = async ({ parent }) => {
  const parentStuff = await parent();
  const dogs = await parentStuff.api.dogs.findAll();

  return { dogs };
};

The createApi function returns a typed fetch client that is generated by consuming my backend's openAPI schema.

Also, here are some issues that might be relevant to this discussion:

• Add way to not fetch data twice in load when provided fetch cannot be used #3729
• A function for getting the current load arguments #2979