`fetch` in endpoints

Is your feature request related to a problem? Please describe.

I’m hosting a blog post on /blog/[slug].svelte. This blog post is powered by /blog/[slug].json, generated by an endpoint. In the endpoint we want to include some html which serves as the body of the blog post. This html is composed by markdown, and its location is defined by an articleUrl parameter.

The final output for /blog/[slug].json might look something like this:

{
  "slug": "my-article",
  "articleUrl": "/articles/my-article.md",
  "articleHtml": "<h1>My article</h1>\n<p>This is my article</p>"
}

Making relative requests to fetch additional content, let’s say /articles/my-article.md, is awkward if you use something like node-fetch. You have to make assumptions about the hosted environment, ergo:

import fetch from "node-fetch";

export async function get(request) {

  (...)

  const url = new URL(project.articleUrl, "http://localhost:3000");
  const res = await fetch(url);
  const markdown = await res.text();

  project.articleHtml = renderMarkdown(markdown);

  return {
    headers: {
      'Content-Type': 'application/json'
    },
    body: project
  }
}

Describe the solution you’d like

If fetch was available in endpoints, similar to how they are implemented in load() for pages, this could easily be solved like:

export async function get(request, fetch) {

  (...)

  const res = await fetch(project.articleUrl);
  const markdown = await res.text();

  project.articleHtml = renderMarkdown(markdown);

  return {
    headers: {
      'Content-Type': 'application/json'
    },
    body: project
  }
}

Describe alternatives you’ve considered node-fetch would normally be an option, but since we are dealing a relative path to a locally hosted file there are the shortcomings elaborated on above.

How important is this feature to you? It’s not really obvious how to solve this particular issue without this feature, so it could help prevent some headaches in the future if there was parity with load().

[Rich-Harris]

As of recent versions, fetch is available globally. In environments where it already exists, like Cloudflare Workers and Deno, we can just use the global; in other environments like Lambda the adapter is expected to make it available, which it can do thusly:

import '@sveltejs/kit/install-fetch';

That solves the problem of external fetches.

I don’t think it makes sense to provide a special custom fetch to endpoints for relative fetches. I can’t think of a situation where you’d use it that wouldn’t be better solved with whatever tool you’re using inside the fetched endpoint (fs, a database, an external fetch, whatever). All it creates is overhead, and confusion about what’s actually happening under the hood.

Even in the case where you’re fetching something from static, as far as the endpoint is concerned it is an external fetch (endpoints have no privileged access to static assets), so it’s appropriate that you’d do something like this:

fetch(`https://${host}${assets}/${file}`)

[benmccann]

fetch seems a bit different to me than the other use cases you mentioned because we already provide a fetch implementation. If we don’t make fetch available then users need to know the implementation detail that we use node-fetch or they might end up with two fetching implementations.

Also if you want to share code between a page and endpoint you’d hope the fetching works the same in both places. Right now we have to do some kind of ugly stuff like:

https://github.com/sveltejs/kit/blob/5554accd7677e5e5caeb45c6c4e0230c218cbd48/examples/realworld.svelte.dev/src/lib/api.js#L15