Docs global fetch alt

documentation/docs/01-routing.md

@@ -92,7 +92,7 @@ export async function get({ params }) {
 }
 ```
 
-> Returning nothing is equivalent to an explicit 404 response.
+> All server-side code, including endpoints, has access to `fetch` in case you need to request data from external APIs.
 
 The job of this function is to return a `{ status, headers, body }` object representing the response, where `status` is an [HTTP status code](https://httpstatusdogs.com):
 
@@ -101,10 +101,12 @@ The job of this function is to return a `{ status, headers, body }` object repre
 - `4xx` — client error
 - `5xx` — server error
 
-> For successful responses, SvelteKit will generate 304s automatically
+> For successful responses, SvelteKit will generate 304s automatically.
 
 If the returned `body` is an object, and no `content-type` header is returned, it will automatically be turned into a JSON response. (Don't worry about `$lib`, we'll get to that [later](#modules-lib).)
 
+> Returning nothing is equivalent to an explicit 404 response.
+
 For endpoints that handle other HTTP methods, like POST, export the corresponding function:
 
 ```js

documentation/migrating/05-endpoints.md

@@ -5,3 +5,5 @@ title: Endpoints
 In Sapper, 'server routes' — now referred to as [endpoints](/docs#routing-endpoints) — received the `req` and `res` objects exposed by Node's `http` module (or the augmented versions provided by frameworks like Polka and Express).
 
 SvelteKit is designed to be agnostic as to where the app is running — it could be running on a Node server, but could equally be running on a serverless platform or in a Cloudflare Worker. For that reason, you no longer interact directly with `req` and `res`. Your endpoints will need to be updated to match the new signature.
+
+To support this environment-agnostic behavior, `fetch` is now available in the global context, so you don't need to import `node-fetch`, `cross-fetch`, or similar server-side fetch implementations in order to use it.