Give API Routes the same love as Form Actions

[ebrenner-code]

I see great potential for an improved dev experience, something I struggle with on every svelte project and I don't even think it would be hard to build.

Now that Svelte 5 is nearing release, I am sure that the team is working on the next version of SvelteKit. I have a lot of faith in the team to make decisions and add features that veterans love and improve adoption.

The Svelte team put a lot of work into Form Actions and those features have been received with a lot of enthusiasm.

There are times however when form actions don’t make the most sense and I reach for server endpoints. When you start writing frontend code that needs to access server side endpoints, it feels clunky in comparison to form actions. Svelte isn’t doing anything wrong here to make this process difficult, but it also isn’t doing anything to make it great.

Let me paint the scenario…

You have a button, that when clicked, should fetch a user's latest messages. You need to check the user has credentials for the db (via a secret key), so a server-side trip is necessary. Here’s how that works currently:

client-side fetch() → server.js fetch() → DB

if you want to reuse this function then it looks like:

import/call function() → client-side fetch() → server.js fetch() → DB

Here are the problems with this.

1. A lot of bolierplate: fetch functions already have a lot of bolierplate between adding headers, dealing with promises and encoding/decoding json.
2. You have to chase down the actual code that is doing the work by chasing the references to the endpoint file.
3. Organization/Security Consideration: You can end up with a lot of folders for all the different endpoints. Even if you are really organized, you can only have a GET/PUT/PATCH/POST/DELETE for each endpoint, you can't do custom named actions like you can with form actions.

Proposed solution

Allow the import of server-side functions to +page.svelte files. Under the hood, the compiler would simply create an endpoint with the function. It would prevent it from being accessed externally (maybe via Bearer Token). It would create a client side fetch that pass the function arguments as body params. It turns our 3 files into one. Takes our non-public endpoints out of our routes folder and handles much of the boilerplate involved in fetches.

Here’s all that expressed in code.

Existing Method

//------------ api/messages/+server.js
const secretKey = '********';

export const GET = async ({ locals }) => {
	userId = locals.validateUser().userId

	const res = fetch ('http://api.com/messages', {
		headers: {
			//
			secretKey
		},
		body: {
			userId,
		}
	})

	const data = await res.json()

	return new Response(JSON.stringify(data))
}

//------------ $lib/messages.js
const getMessages = async () => {
	const res = fetch ('/api/messages', {
		headers: {
			method: 'GET'
			//
		},
		body: {
			userId,
		}
	})

	return await res.json()
}

export {getMessages};

//----------- +page.svelte
import { getMessages } from '$lib/posts'

getMessages()

Proposed Structure

//------------ lib/server/messages.js
const secretKey = '********';


const getPost = async (locals) => {
	userId = locals.validateUser().userId
	const res = fetch ('http://api.com/messages', {
		headers: {
			//
			secret_key
		},
		body: {
			userId,
		}
	})

	return await res.json()
}

export {getPost};

//----------- +page.svelte
import { getMessages } from '$lib/server/messages'

getMesages()

This would compile into the existing method at build time.

I think just comparing the number of lines of code in each example diminishes the problem. The benefit grows with every element of complexity added to these functions. This removes the many directories/sub-directories from the “api” folder. It makes the purpose of these functions more clear as server functions, it means we don’t ned to chase the references to multiple files.

[ebrenner-code]

Just a quick follow-up almost 2 years later I am very happy to see that Remote Functions seem to address all of my points here and bring some additional structure. Great work as always from the svelte team @Rich-Harris. Can't wait to see this come out of experimental.