Remote Functions

[dummdidumm]

The RFC was tweaked, see #13897 (comment) for a list of changes

tl;dr

Remote functions are a new concept in SvelteKit that allow you to declare functions inside a .remote.ts file, import them inside Svelte components and call them like regular functions. On the server they work like regular functions (and can access environment variables and database clients and so on), while on the client they become wrappers around fetch. If you're familiar with RPC and 'server functions', this is basically our take on the concept, that addresses some of the drawbacks we've encountered with other implementations of the idea.

You can try it out soon by installing from the corresponding PR once it's out...

... and add the experimental options

const config = {
	// ...

	kit: {
		// add this:
		experimental: {
			remoteFunctions: true
		},
		// ...
	},

	// we recommend using this in combination with Svelte's new async capabilities
	compilerOptions: {
		experimental: { async: true }
	}
};

We'll also link an example here, soon.

Background

Today, SvelteKit's data loading is based on the concept of loaders. You declare a load function inside a +page/layout(.server).ts file, fetch the required data for the whole page in it, and retrieve the result via the data prop inside the sibling +page/layout.svelte file.

This allows for a very structured approach to data loading and works well for sites where the loaded data is used on the whole page. When that isn't so clear-cut, some drawbacks become apparent:

• it leads to implicit coupling between what seem like disconnected files:
  • colocation suffers
  • data only needed in one corner of the page, or only under certain conditions, still needs to be put into the loader
  • deleting or refactoring code becomes harder since you need to keep in mind both where stuff is loaded and where it’s used
• sharing data means moving its data loading up and down the layout loader tree, leading to more complexity
• refetching data happens on a loader level, if you want it to be more granular SvelteKit can't help you

Additionally, since load and the resulting data prop are somewhat disconnected, we have to resort to very clever but somewhat weird solutions like generating hidden types you import as ./$types or even using a TypeScript plugin to avoid having to import the types yourself. An approach where we can use TypeScript natively would simplify all this and make it more robust.

Lastly, apart from form actions SvelteKit doesn't give you a good way to mutate data. You can use +server.ts files and do fetch requests against these endpoints, but it's a lot of ceremony and you lose type safety.

Asynchronous Svelte

A couple of weeks ago we introduced Asynchronous Svelte, a proposal to allow using await at the top level of Svelte components and inside the template.

This in itself is already valuable, but the way SvelteKit's data loading is architected right now you can't take full advantage of it inside SvelteKit.

Requirements

A solution should fix these drawbacks and take advantage of Svelte's capabilities, and specifically should:

• be secure and intuitive
• increase colocation, moving data loading closer to where it's used
• make loading and mutation type-safe
• put control of granularity in the developer's hands
• fully take advantage of asynchronous Svelte
• be maximally efficient

An important additional requirement is that modules that can run in the client (including components) must never include code that can only run on the server. A remote function must be able to safely access things like database clients and environment variables that should not (or cannot) be accessed from the client.

In practice, this means that remote functions must be declared in a separate module. Over the last few years various systems have experimented with 'server functions' declared alongside universal/client code, and we're relieved to see a growing consensus that this is a flawed approach that trades security and clarity for a modicum of convenience. You're one innocent mistake away from leaking sensitive information (such as API keys or the shape of your database), and even if tooling successfully treeshakes it away, it may remain in sourcemaps. While no framework can completely prevent you from spilling secrets, we think colocating server and client code makes it much more likely.

Allowing server functions to be declared in arbitrary locations also masks the fact that they are effectively creating a publicly accessible endpoint. Even in systems that prevent server functions from being declared in client code (such as "use server" in React Server Components), experienced developers can be caught out. We prefer a design that emphasises the public nature of remote functions rather than the fact that they run on the server, and avoids any confusion around lexical scope.

Design

Before we jump in we want to make clear that this does not affect load functions, they continue to work as is.

Remote functions are declared inside a .remote.ts file. You can import them inside Svelte components and call them like regular async functions. On the server you import them directly; on the client, the module is transformed into a collection of functions that request data from the server.

Today we’re introducing four types of remote function: query, form, command and prerender.

query

Queries are for reading dynamic data from the server. They can have zero or one arguments. If they have an argument, you're encouraged to validate the input via a schema which you can create with libraries like Zod (more details in the upcoming Validation section). The argument is serialized with devalue, which handles types like Date and Map in addition to JSON, and takes the transport hook into account.

import z from 'zod';
import { query } from '$app/server';
import * as db from '$lib/server/db';

export const getLikes = query(z.string(), async (id) => {
  const [row] = await db.sql`select likes from item where id = ${id}`;
  return row.likes;
});

When called during server-rendering, the result is serialized into the HTML payload so that the data isn't requested again during hydration.

<script>
  import { getLikes } from './data.remote';
  
  let { item } = $props();
</script>

<p>likes: {await getLikes(item.id)}</p>

Async SSR isn’t yet implemented in Svelte, which means this will only load in the client for now. Once SSR is supported, this will be able to hydrate correctly, not refetching data

Queries are thenable, meaning they can be awaited. But they're not just promises, they also provide properties like loading and current (which contains the most recent value, but is initially undefined) and methods like override(...) (see the section on optimistic UI, below) and refresh(), which fetches new data from the server. We’ll see an example of that in a moment.

Query objects are cached in memory for as long as they are actively used, using the serialized arguments as a key — in other words myQuery(id) === myQuery(id). Refreshing or overriding a query will update every occurrence of it on the page. We use Svelte's reactivity system to intelligently clear the cache to avoid memory leaks.

form

Forms are the preferred way to write data to the server:

import z from 'zod';
import { query, form } from '$app/server';
import * as db from '$lib/server/db';

export const getLikes = query(z.string(), async (id) => {/*...*/});

export const addLike = form(async (data: FormData) => {
  const id = data.get('id') as string;

  await sql`
    update item
    set likes = likes + 1
    where id = ${id}
  `;

  // we can return arbitrary data from a form function
  return { success: true };
});

A form object such as addLike has enumerable properties — method, action and onsubmit — that can be spread onto a <form> element. This allows the form to work without JavaScript (i.e. it submits data and reloads the page), but it will also automatically progressively enhance the form, submitting data without reloading the entire page.

<script>
  import { getLikes, addLike } from './data.remote';
  
  let { item } = $props();
</script>

<form {...addLike}>
  <input type="hidden" name="id" value={item.id} />
  <button>add like</button>
</form>

<p>likes: {await getLikes(item.id)}</p>

By default, all queries used on the page (along with any load functions) are automatically refreshed following a form submission, meaning getLikes(...) will show updated data.

In addition to the enumerable properties, addLike has non-enumerable properties such as result, containing the return value, and enhance which allows us to customize how the form is progressively enhanced. We can use this to indicate that only getLikes(...) should be refreshed and through that also enable single-flight mutations — meaning that the updated data for getLikes(...) is sent back from the server along with the form result. Additionally we provide nicer behaviour in the case that the submission fails (by default, an error page will be shown):

<script>
  import { getLikes, addLike } from './data.remote';
  
  let { item } = $props();
</script>

{#if addLike.result?.success}
  <p>success!</p>
{/if}

<form {...addLike.enhance(async ({ submit }) => {
  try {
    // by passing queries to `.updates(...)` we will prevent a global refresh and the
    // refreshed data is sent together with the submission response (single flight mutation)
    await submit().updates(getLikes(item.id));
  } catch (error) {
    // instead of showing an error page,
    // present a demure notification
    showToast(error.message);
  }
}}>
  <input type="hidden" name="id" value={item.id} />
  <button>add like</button>
</form>

<p>likes: {await getLikes(item.id)}</p>

form.result need not indicate success — it can also contain validation errors along with any data that should repopulate the form on page reload, much as happens today with form actions.

Alternatively we can also enable single-flight mutations by adding the refresh call to the server, which means all calls to addLike will leverage single-flight mutations compared to only those who use submit.updates(...):

import { query, form } from '$app/server';
import * as db from '$lib/server/db';

export const getLikes = query(async (id: string) => {
  const [row] = await sql`select likes from item where id = ${id}`;
  return row.likes;
});

export const addLike = form(async (data: FormData) => {
  const id = data.get('id') as string;

  await sql`
    update item
    set likes = likes + 1
    where id = ${id}
  `;
  
+ await getLikes(id).refresh();

  // we can return arbitrary data from a form function
  return { success: true };
});

command

For cases where serving no-JS users is impractical or undesirable, command offers an alternative way to write data to the server.

import z from 'zod';
-import { query, form } from '$app/server';
+import { query, command } from '$app/server';
import * as db from '$lib/server/db';

export const getLikes = query(z.string(), async (id) => {
  const [row] = await sql`select likes from item where id = ${id}`;
  return row.likes;
});

-export const addLike = form(async (data: FormData) => {
-  const id = data.get('id') as string;
+export const addLike = command(z.string(), async (id) => {

  await sql`
    update item
    set likes = likes + 1
    where id = ${id}
  `;
  
  getLikes(id).refresh();

  // we can return arbitrary data from a command
  return { success: true };
});

This time, simply call addLike, from (for example) an event handler:

<script>
  import { getLikes, addLike } from './data.remote';
  
  let { item } = $props();
</script>

<button
  onclick={async () => {
    try {
      await addLike();
    } catch (error) {
      showToast(error.message);
    }
  }}
>
  add like
</button>

<p>likes: {await getLikes(item.id)}</p>

Commands cannot be called during render.

As with forms, we can refresh associated queries on the server during the command or via .updates(...) on the client for a single-flight mutation, otherwise all queries will automatically be refreshed.

prerender

This function is like query except that it will be invoked at build time to prerender the result. Use this for data that changes at most once per redeployment.

import z from 'zod';
import { prerender } from '$app/server';

export const getBlogPost = prerender(z.string(), (slug) => {
  // ...
});

You can use prerender functions on pages that are otherwise dynamic, allowing for partial prerendering of your data. This results in very fast navigation, since prerendered data can live on a CDN along with your other static assets.

When the entire page has export const prerender = true, you cannot use queries, as they are dynamic.

Prerendering is automatic, driven by SvelteKit's crawler, but you can also provide an entries option to control what gets prerendered, in case some pages cannot be reached by the crawler:

import z from 'zod';
import { prerender } from '$app/server';

export const getBlogPost = prerender(
  z.string(),
  (slug) => {
    // ...
  },
  {
    entries: () => ['first-post', 'second-post', 'third-post']
  }
);

If the function is called at runtime with arguments that were not prerendered it will error by default, as the code will not have been included in the server bundle. You can set dynamic: true to change this behaviour:

import z from 'zod';
import { prerender } from '$app/server';

export const getBlogPost = prerender(
  z.string(),
  (slug) => {
    // ...
  },
  {
+   dynamic: true,
    entries: () => ['first-post', 'second-post', 'third-post']
  }
);

Optimistic updates

Queries have an withOverride method, which is useful for optimistic updates. It receives a function that transforms the query, and must be passed to submit().updates(...) or myCommand.updates(...):

<script>
  import { getLikes, addLike } from './data.remote';
  
  let { item } = $props();
</script>

<button
  onclick={async () => {
    try {
-      await addLike();
+      await addLike().updates(getLikes(item.id).withOverride((n) => n + 1));
    } catch (error) {
      showToast(error.message);
    }
  }}
>
  add like
</button>

<p>likes: {await getLikes(item.id)}</p>

You can of course do const likes = $derived(getLikes(item.id)) in your <script> and then do likes.withOverride(...) and {await likes} if you prefer, but since getLikes(item.id) returns the same object in both cases, this is optional

Multiple overrides can be applied simultaneously — if you click the button multiple times, the number of likes will increment accordingly. If addLike() fails, the override releases and will decrement it again, otherwise the updated data (sans override) will match the optimistic update.

Validation

Data validation is an important part of remote functions. They look like regular JavaScript functions but they are actually auto-generated public endpoints. For that reason we strongly encourage you to validate the input using a Standard Schema object, which you create for example through Zod:

import { query } from '$app/server';
import { z } from 'zod';

const schema = z.object({
  id: z.string()
});

export const getStuff = query(schema, async ({ id }) => {
    // `id` is typed correctly. if the function
    // was called with bad arguments, it will
    // result in a 400 Bad Request response
});

By default a failed schema validation will result in a generic 400 response with just the text Bad Request. You can adjust the returned shape by implementing the handleValidationError hook in hooks.server.js. The returned shape must adhere to the shape of App.Error.

// src/hooks.server.ts
import z from 'zod';

export function handleValidationError({ result }) {
  return { validationErrors: z.treeifyError(result.error)}
}

If you wish to opt out of validation (for example because you validate through other means, or just know this isn't a problem), you can do so by passing 'unchecked' as the first argument instead:

import { query } from '$app/server';

export const getStuff = query('unchecked', async ({ id }: { id: string }) => {
    // the shape might not actually be what TypeScript thinks since bad actors might call this function with other arguments
});

In case your query does not accept arguments you don't need to pass a schema or 'unchecked' - validation is added under the hood on your behalf to check that no arguments are passed to this function:

import { query } from '$app/server';

export const getStuff = query(() => {
    // ...
});

The same applies to prerender and command. form does not accept a schema since you are always passed a FormData object which you need to parse and validate yourself.

Accessing the current request event

SvelteKit exposes a function called getRequestEvent which allows you to get details of the current request inside hooks, load, actions, server endpoints, and the functions they call.

This function can now also be used in query, form and command, allowing us to do things like reading and writing cookies:

import { getRequestEvent, query } from '$app/server';
import { findUser } from '$lib/server/db';

export const getProfile = query(async () => {
  const user = await getUser();
  
  return {
    name: user.name,
    avatar: user.avatar
  };
});

// this function could be called from multiple places
function getUser() {
  const { cookies, locals } = getRequestEvent();
  
  locals.userPromise ??= findUser(cookies.get('session_id'));
  return await locals.userPromise;
}

Note that some properties of RequestEvent are different in remote functions. There are no params or route.id, and you cannot set headers (other than writing cookies, and then only inside form and command functions), and url.pathname is always / (since the path that’s actually being requested by the client is purely an implementation detail).

Redirects

Inside query, form and prerender functions it is possible to use the redirect(...) function. It is not possible inside command functions, as you should avoid redirecting here. (If you absolutely have to, you can return a { redirect: location } object and deal with it in the client.)

Future work / open questions

Server caching

We want to provide some kind of caching mechanism down the line, which would give you the speed of prerendering data while also reacting to changes dynamically. If you're using Vercel, think of it as ISR on a function level.

We would love to hear your opinions on this matter and gather feedback around the other functions before committing to a solution.

Client caching

Right now a query is cached and deduplicated as long as there's one active subscription to it. Maybe you want to keep things around in memory a little longer, for example to make back/forward navigation instantaneous? We haven't explored this yet (but have some ideas) and would love to hear your use cases (or lack thereof) around this.

Prerendered data could be kept in memory as long as the page is open — since we know it’s unchanging, it never needs to be refetched. The downside is that the memory could then never be freed up. Perhaps this needs to be configurable.

Conversely, for queries that we know will become stale after a certain period of time, it would be useful if the query function could communicate to the client that it should be refetched after n seconds.

Batching

We intend to add client-side batching (so that data from multiple queries is fetched in a single HTTP request) and server-side batching that solves the n + 1 problem, though this is not yet implemented.

Streaming

For real-time applications, we have a sketch of a primitive for streaming data from the server. We’d love to hear your use cases.

[elliott-with-the-longest-name-on-github]

yet another long-awaited feature

[Ayushkumar48]

but It will definitely make SvelteKit a great framework like a Swiss knife of the frameworks.

[saturnonearth]

The hype is real for this - amazing changes - and validation!!! Omg..

For real-time applications, we have a sketch of a primitive for streaming data from the server. We’d love to hear your use cases.

*cough* Zero *cough* 👀

[Rich-Harris]

I assume it refers to https://zero.rocicorp.dev...

[saturnonearth]

I assume it refers to https://zero.rocicorp.dev...

Ha yes!! Probably should have been more clear. I am just a strong advocate for sync/local-first and would love Svelte to lead the charge.

Loving the future for Svelte and SvelteKit

[JonathonRP]

Possibly also convex 😉

[samal-rasmussen]

All these real time frameworks are way overbuilt. All we need is a primitive like the command fn that subscribes to data over a websocket and returns a signal/observable/store, and we can build our own solutions on top of that.

[Rich-Harris]

This should give you an idea where our head's at: #12973 (comment)

[abdelfattahradwan]

I am about to cry 🥹 This is a freaking great feature!.

[chanmathew]

Brilliant 🎉

[ottomated]

I'm excited to see the idea for validation! Have you considered something like this to avoid the extra import and slightly awkward nested functions?

export const getStuff = query.validate(schema, async ({ id }) => {
  // `id` is typed correctly. if the function
  // was called with bad arguments, it will
  // result in a 422 response
});

[Rich-Harris]

Yes, considered and rejected — it's more surface area (you need command.validate, form.validate, prerender.validate and so on) and less composable (you might want to use validation with a function that's called by a query, rather than the query itself). Much better to use composition

[ottomated]

Makes sense! My only counter-argument would be that validation should be the default case 99.9% of the time, and it doesn't feel like that with the composed approach. I don't know if it exists, but I would love to see a clean solution that pushes users towards validating all their functions (I hope we agree that all server functions being validated is the ideal!)

[Rich-Harris]

I'm going to copy and paste what I wrote during an internal discussion on this topic:

In the case of a query, which has no side-effects (unless you are actively choosing to shoot yourself in the foot), malformed input will just return something useless — there's no way to use this for mischief:

export const find_nearest_city = query((lat: number, lng: number) => {
  let min_distance = Infinity;
  let closest = null;

  for (const city of cities) {
    const distance = get_distance(city, { lat, lng });
    if (distance < min_distance) {
      min_distance = distance;
      closest = city;
    }
  }

  return city;
});

---

Even with commands, sometimes there are no arguments — there's nothing to validate here, so if command expected a schema it would just be annoying boilerplate:

export const hit_counter = command(() => {
  await db.increment('hits');
});

---

And even when there are arguments, the value of validation is overstated. In a case like this, I only need to check that the user is authenticated (which Standard Schema obviously can't help me with). Validating that id is a number doesn't really give me any additional protection, because the requester can only interact with their own posts, and because if they passed something other than a number the most likely outcome is that db.get_post(id) would just fail.

// we need validation here, but of the user, not the arguments,
// and the logic really needs to go inside the function itself
export async function delete_post(id: number) {
  const { locals } = getRequestEvent();

  if (!locals.user) error(401);

  const post = await db.get_post(id);
  if (post.author !== locals.user.id) error(403);

  await db.delete_post(id);
}

---

Validation doesn't magically make things secure. It's a valid user ID? Cool. Whose?

So I don't think we should require validation, we should just encourage it by offering a validate function that uses Standard Schema:

import { validate } from '@sveltejs/kit';
import * as v from 'valibot';

const schema = v.tuple([
  v.pipe(v.number(), v.minValue(-180), v.maxValue(180)),
  v.pipe(v.number(), v.minValue(-180), v.maxValue(180))
]);

export const find_nearest_city = query(
  validate(schema, ([lat, lng]) => {
    // ...
  })
);

Given that a validation error could occur because of someone probing remote function endpoints, the appropriate response here is a 400 with a generic 'Bad Request' message, rather than detailed instructions on how to pass validation. More granular checks like 'this email address is already in use' should be handled manually by the developer and result in 422s.

[ottomated]

Here's an example of a vulnerability that could arise:

export const delete_post = command((id: number) => {
  const post = await posts.findOne({
    id
  });
  if (!user_can_delete(post)) error(403);
  await posts.delete({
    id
  });
});

Looks fine, right? What if a malicious user sends the following:

await delete_post({ lte: 20 });

The findOne could return post 20 and pass the check, and then delete all posts from 0-20.

[jose-manuel-silva]

@Rich-Harris I get the reasoning about validation not being a magic security bullet, and the composability stuff makes sense.

But @ottomated's injection example shows how dangerous the "malformed input just returns useless data" assumption can be. The TypeScript signature says id: number but that's meaningless at runtime - malicious clients can send whatever JSON they want.

Looking at how other libraries do this, the nested approach feels weird:

tRPC does:

.input(schema)
.mutation(({ input }) => { ... })

next-safe-action does:

action(schema, (input) => { ... })

Everyone else puts validation first, handler second. SvelteKit's approach of burying the handler inside the validation function is pretty unique.

I get your composability point about validating sub-functions, but you could still achieve that with a validation-first API:

// Common case: validation prominent  
export const deleteUser = command(
  z.object({ id: z.string() }),  
  async ({ id }) => {
    // id is typed correctly, 400 on bad input
  }
);

// Your composability case: validate a sub-function
const validateInput = z.object({ id: z.string() }).parse;

export const complexThing = command(
  validateInput,  // any transformation function works
  async (validated) => { 
    // can call other functions with validateInput
  }
);

// Edge case: explicit opt-out
export const hitCounter = command.raw(() => {
  await db.increment('hits');
});

This keeps your composability while making validation visually prominent for the dangerous cases. The current nested approach makes it too easy to skip validation.

What do you think?

[itsmikesharescode]

wow!

[geodask]

Wow, this is awesome! It seems so intuitive and satisfying to use!

[ollema]

sounds great!

I have been struggling to implement a fairly complex SvelteKit-app that renders sequences of sensor data from lidars, cameras and radars.

each frame in a sequence can be 20-100 mb. at the same time, the sensor data is pretty static so caching can and will be used on as many levels as possible.

super interested in what you have planned for caching!

Server caching

We want to provide some kind of caching mechanism down the line, which would give you the speed of prerendering data while also reacting to changes dynamically.

this would be great and it would basically replace what I have implemented on my own to cache requests. it would be great with control over at least max size when used as some LRU-cache. but also max size in terms of size on the disk and maybe also some TTL. and of course some way to manually invalidate the cache per function or globally, if needed.

Client caching

Right now a query is cached and deduplicated as long as there's one active subscription to it. Maybe you want to keep things around in memory a little longer, for example to make back/forward navigation instantaneous? We haven't explored this yet (but have some ideas) and would love to hear your use cases (or lack thereof) around this.

Prerendered data could be kept in memory as long as the page is open — since we know it’s unchanging, it never needs to be refetched. The downside is that the memory could then never be freed up. Perhaps this needs to be configurable.

yeah this would also be useful! I would even go one step further and consider some sort of persistent cache for users - maybe in IndexedDB or something along those lines?

otherwise that is something I plan to implement anyways - so I don’t have to stream hundreds of megabytes to a user if they accidentally refresh the page. again one thing less I would have to implement in userland so if this was provided as some opt-in feature by sveltekit it would be the dream.

the same level of configuration I brought up for the server caching would be useful in a persistent client side cache as well

—-

please let me know if I can provide feedback in any more structured way, I would love to test this out in practice later on and help out as much as I can

[darrylyeo]

A built-in client-side cache would be amazing. Would allow me to completely remove TanStack Query as a dependency.

[ziedHamdi]

This reminds me of the days I was a GWT expert, back in 2010-16. I must say there were disappointments with the RPC calls architecture, but I forgot the use cases. What I remember is that it was frustrating to call them manually, eg. from a mobile app, so I had to isolate then as only callers to service methods (having them like boilerplate code). Maybe the architecture would allow a non proprietary protocol so that it can be implemented in case of need...

[wiesson]

Where can I subscribe so that I get a notification once this is testable? The form part is incredibly valuable <3

[dummdidumm]

PR will hopefully go up later this week, we'll update the discussion with a link to it and example then.

[Defman]

Any updates =)

[rebasecase]

#13957

[rossrobino]

This is going to be incredible, this and async address all of the features I have been wanting from Svelte.

One question for the team, have you considered adding a Form component property instead of spreading? I feel like could be a bit more readable, especially with enhance.

<script>
  import { getLikes, addLike } from './data.remote';
  
  let { item } = $props();
</script>

<addLike.Form enhance={async () => {...}}>
  <input type="hidden" name="id" value={item.id} />
  <button>add like</button>
</addLike.Form>

<p>likes: {await getLikes(item.id)}</p>

[Rich-Harris]

Aesthetically I'd prefer <addLike.form ...> (and <addLike.button> for <button formAction="...">), but yes, this is worth considering.

The main reason not to do it is that you can no longer use element-specific directives like transitions — our goal is to replace those with more flexible programmatic APIs that can be used with attachments, but for now attachments only replace actions, and there's still stuff like bind:clientWidth which works on elements but not components.

[theetrain]

I'm not sure if <addLike.Form> (or <addLike.form>) resemble any existing markup pattern; I believe custom elements can only be dash-separated like <addlike-form>; and Svelte components must be capitalized like <AddLike.Form>. Even when explained, it's challenging for me to mentally map <addLike.Form> to an eventually-rendered <form>.

How about this twist:

<script>
  import { getLikes, addLike } from './data.remote';

+ import { Form } = addLike
  
  let { item } = $props();
</script>

+<Form enhance={async () => {...}}>
  <input type="hidden" name="id" value={item.id} />
  <button>add like</button>
+</Form>

<p>likes: {await getLikes(item.id)}</p>

Though I'm unsure if we can compiler away the theoretical Form component property on addLike when unused.

I still prefer the markup as proposed, with <form {...addLike}> and <form {...addLike.enhance(() => {})}> since it fits neatly in the world of Svelte and HTML. There's also the concern of styling <Form> since there's no way currently to pass scoped styles down to components.

[Rich-Harris]

Svelte components must be capitalized

nope, they must be capitalized or use dot notation

[huseeiin]

if await getLikes(item.id) is like react/solid <Suspense> how do we have a fallback?

[Rich-Harris]

with <svelte:boundary> sveltejs/svelte#15845

[samal-rasmussen]

EDIT: Ignore this. I didn't see it was a template string.

db.sqlselect likes from item where id = ${id}

Please use prepared statements in your sql examples 😭

[Rich-Harris]

Why?

[samal-rasmussen]

Because teaching newbies to trust that a function that accepts and runs an sql query against a db will be doing proper sanitizing for them, will let them down.

[elliott-with-the-longest-name-on-github]

not really, this is just how modern sql libraries do parameterization: https://orm.drizzle.team/docs/sql#sql-template, https://www.npmjs.com/package/@vercel/postgres, https://www.npmjs.com/package/postgres

[JabSYsEmb]

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals

[samal-rasmussen]

Lord I didn't even spot it was a template literal. Sorry about that. That is very different from a function call. Modern js is magical.

(Sometimes I wonder how I manage to be a professional developer even when I am often character blind like this.)

[kran6a]

While I don't think I will use this many times since I build mostly true SPAs with a separate backend, I really believe these will be very useful for fullstack apps or backend-for-frontend apps.

There are two additions I would add:

Output validation

Not so much due to the validation but due to the validator being able to transform the output (setting default values for null/undefined fields, removing extra keys, etc.).

I think a tRPC-like signature like this would be more ergonomic if output validation is added but the signature is definitely not a big deal:

const my_procedure = rpc
    .input(input_schema)
    .output(output_schema)
    .query(schema, async (input) => {
        //body
      })
    //maybe allow chaining a .mutation here to create a mutation that implicitly invalidates the query?

Support for middleware (using the tRPC-like signature above)

Middlewares are a great way to manage dependency injection in a declarative manner.

const my_procedure = rpc
    .input(input_schema)
    .output(output_schema)
    .middleware(services) //Whatever is returned from a middleware is passed to the next middleware as the first parameter
    .middleware(logging)
    .middleware(stats)
    .middleware(with_cache({storage: 'redis', ttl: 3600})) //The function returned by with_cache() would be accessing a redis service returned by the first middleware
    .query(schema, async (input, ctx) => { //ctx holds the awaited return value of the last middleware
        //body
      })

I also would like to know what are the plans regarding load functions.
Is this considered a replacement that will eventually lead to load functions being marked as deprecated?

Personally I think load functions fill a different role, specially on SPAs, where they can be used as a mechanism for dependency/service injection and state management. I even consider them a better context alternative.
When I started building SPAs with svelte-kit I overlooked them because they were way more limited as they couldn't use browser APIs and did not support returning $state-ful values, but now I think they are the best cross-component state and dependency management solutions out there for SPAs: state and services stay scoped to the page/layout where they are defined (you can even create +layout.ts files without their corresponding +layout.svelte file just for state/dependency management purposes!), automatic and intuitive composition due to their monadic nature, automatic invalidation, type-safety, automatic injection via the data prop, ability to preload state and initialize services needed by the page you will visit next... The only thing I miss is not being able to define teardown logic in load functions to deinit services, but it is a minor inconvenience given the DX they provide.

[elliott-with-the-longest-name-on-github]

output validation

Why would this ever be needed / isn't this what TypeScript is for? You're already in control of the data you return from the function, so just... don't return data in the wrong shape / type the result of your function. (Am I missing something?)

middleware

Is this necessary in a world where you have access to getRequestEvent? Wouldn't you put your services on locals and access them there?

[Rich-Harris]

@elliott-with-the-longest-name-on-github i assume you meant this to be a reply to the previous thread

[kran6a]

Why would this ever be needed / isn't this what TypeScript is for? You're already in control of the data you return from the function, so just... don't return data in the wrong shape / type the result of your function. (Am I missing something?)

This requires using a return type annotation on the handler function. Otherwise, a query like "SELECT * FROM table" or the ORM equivalent would return new fields should you update your DB schema without breaking anything in typescript.

Having to annotate return types increase maintenance/refactoring time, as they are not automatically updated when you update your typed SQL/ORM queries and depending on the typescript config you are using, it may not report additional properties being present as an error. Also I bet the return type annotation will make the compiler lie to the frontend about the true returned data type, which may lead to sensitive fields traveling through the network unnoticed. Reporting additional properties as an error might be something you don't want to turn on (at least I don't do it even if I inherit from @tsconfig/strictest).

There is also the case where you get weird return types from third party libs like

type User = {
    followers: User[] | null //This is null when the user has no followers. Replacing null by an array simplifies dealing with the field
    created_at: Date, //We want to stringify Dates
    last_active: Date | null //This is null if the user never logged in because our DB guy needed it for stats (users that registered but never logged in). Replacing null by the created_at field would be a sensible choice
}

You can actually do something like

return {
    ...user,
    followers: user.followers ?? [] satisfies User["followers"],
    last_active: user.last_active?.toString() ?? user.created_at.toString()
}

Or even wrap that logic in a function taking an User, but I find having a user_schema definition that does this same thing using zod way more readable and composable, specially if there are several endpoints that return objects of the User type coming from the same third party library/service/ORM.

Is this necessary in a world where you have access to getRequestEvent? Wouldn't you put your services on locals and access them there?

This will depend on the complexity of your backend. For low to medium complexity backends it would be enough, but as your backend starts needing to scale you will start encountering things that cannot be done properly or safely by defining a global and static set of services:

You may want to provide different service implementations (or service configurations) to different endpoints (redis cache VS in-memory cache, a per-endpoint set of rabbitmq queues or event buses with typed names and schemas, etc). Otherwise you will end with all rabbitmq queues, caches and event buses available to all endpoints, which results in a cluttered intellisense autocomplete and options that will certainly cause bugs being listed as available (ie: an immutable edge cache appearing as an option on an endpoint that returns variable data, events being emitted on the wrong event bus, etc.).

[Rich-Harris]

Both of these problems are better solved with normal functions

[rebasecase]

Whenever your function's output may depend on untrusted or dynamic inputs whose validity your type annotations cannot actually enforce at runtime.

[francismanansala]

I'm looking forward to this feature. Has it been discussed how auth would be used with remote functions?

[Rich-Harris]

You can use getRequestEvent in remote functions

[ptrxyz]

Since all these calls will be wrapped in standard fetch requests, do we get a way to manipulate fetch options? Sometimes setting headers might be useful or setting credentials, an abort signal, or the like.
And a way to control timeouts would be great, in case we are dealing with bad connections, just to avoid having to do promise.race all the way.

[thedelanyo]

I don't know, but if that'll be the way to go, then exposing the client fetch, wouldn't it be a bit tricky?

Because, it seems according to the current spec, fetch is only called on the client. On the server, it is just a regular data loading function. (To my understanding, fetch is used to call your actual remote server function (RPC). It is the server that actually handles the data loading duty).

This is good, because as a developer, for security reasons, it's important not to leak external API keys/secrets.

[rmunn]

In the question asked two hours before yours, Rich mentioned that you can call getRequestEvent in order to read or write cookies. See the "Accessing the current request event" section of the original post (there don't seem to be any <a> elements in the post so I can't give you a link, but you can use Ctrl+F to get to that header).

[ptrxyz]

I am not sure what a good solution would look like, just describing the problem. Maybe exposing fetch is not a good idea but a custom configuration object would be added? But on the other hand fetch didn't come up with its config options for no reason, many of those are actually used and have valid applications.

[NickClark]

This is looking really exciting!

A couple things that would keep us from being able to use it right now:

1. Server Sent Events (SSE)
2. Shared middleware (especially for sharing auth logic between functions)

We currently use ORPC which does this very well. Ideally I would love it if Svelte remote functions felt like it was sugar over that API. 😄
Some things I love about the ORPC api:

1. You can easily make new functions based on any arbitrary middleware stack you want

// Shared config
const pub = apiBase.use(sessionMiddleware);
const authed = pub.use(requireAuthMiddleware);

export const api = {
  public: pub,
  authed,
};
  
 // RPC function
export const all = api.authed.handler(async () => {
  return await db.select().from(users);
});

2. It's nice that the API here properly builds up the correct typings for the context obeject based on the actual middleware stack you end up prefixing to your RPC handler.

3. SSE is easy to implement handlers for. Same as your normal RPC, except your handler function is an async generator function. You can use the Abort Signal they give you to be aware of canceled connections and you can finish the connection by simply returning. SSE docs

const changes = api.authed.handler(async function* ({ input, lastEventId }) {
    while (true) {
      yield { message: 'Hello, world!' }
      await new Promise(resolve => setTimeout(resolve, 1000))
    }
  })

4. Integration with Tanstack query. Now I know we shouldn't need that here. The already described API above for query seems like the ticket and should be even simpler. But just to point out how simple it is to use data from something like ORPC:

// From a normal RPC:
const query = useQuery(orpc.useres.all.queryOptions())

// From a SSE source (streamed):
const query = useQuery(orpc.streamed.experimental_streamedOptions({
  input: { id: 123 },
  queryFnOptions: {
    refetchMode: 'reset',
    maxChunks: 3,
  }
}))

5. Bonus points: Websockets?

Anyways, very excited for this new feature. Nice work!

[novaotp]

For SSE (and websockets), you can look into the draft for implementing realtime into Kit.

[NickClark]

Thanks for referencing that! That's looking great! I somehow missed that draft. Looks like the Svelte Team is on top of it!

[realfakenerd]

I got an question now, how would the +server.ts endpoints function now? Are you guys planning to remove these +server.ts?

[realfakenerd]

@thedelanyo that sounds nice, i thought of RSC because it could make an allusion on RPC

[thedelanyo]

Right. I got it 👍

[rebasecase]

[Rich-Harris]

This page is a place to discuss the RFC. Every time you add a comment, hundreds of people get emailed. Let's keep it focused (and no, we're not going to rename them)

[rebasecase]

Okay

[timootten]

The branches rpc-ssr-2 and async contain the latest updates for async Svelte and the remote functions (command, query, prerender, form).
Is there already a branch for the new query.stream feature, or is it currently just an idea that hasn’t been implemented or tested yet?

[elliott-with-the-longest-name-on-github]

Currently an idea that hasn't been implemented yet!

[timootten]

Currently an idea that hasn't been implemented yet!

Okay, thanks

[TweedChristian]

Something I have found difficult with the progressive enhancement primitives of SvelteKit is that there's not really a clear path for nested data or arrays. I love the form remote function concept here, but it has the same issue. It might be my lack of old-school knowledge, but this is something I think could be added into the form function. A first class option to assemble data out of the FormData object (or generate HTML input names) would fill this gap, and knowing the DX from the team this would be a fantastic option.

Currently, I rely on Superforms to do the data transformation on the client, but even there it's not progressively enhance-able. This RFC is consuming most of Superforms features, which makes its future tenuous (especially since it still hasn't adopted runes).

[paoloricciuti]

Unfortunately that's just a limitation of the platform...there's no way to send arrays or objects as FormData, not without JS at least.

There are some libraries that use naming convention to allow you to do that. For example if you name your inputs my_arr[0] and my_arr[1] it will parse your FormData and assemble it in an Array with the value of the first input in the 0 spot and the value of the second input in the 1 spot but tbf all of this is pretty "brittle" anyway and i would not recommend it.

Another way you can model arrays is by using getAll

const data = new FormData();
data.append("a", "1");
data.append("a", "2");

console.log(data.getAll("a")); // ["1", "2"];

but all of this is heavily dependent on your project.

[TweedChristian]

@paoloricciuti Thanks for the input, and yeah, I've learned that the hard way. I've dug around for some ways around it and people often use property access notation for input names.

<input name="author.books[0].title" />

This would let the client treat FormData as a flat object where the input names could be dynamically generated, and the server would "unflatten" the data.

I took a stab at this in Superforms, but the PR is still in development and review. Honestly, even if the team doesn't solve it a blog post or something demonstrating how to do complex data structures with the new form function would be incredibly helpful.

[rebasecase]

Can you share a real world example where this kind of nesting is truly necessary, or even a plausible scenario where you’d structure form data as an array without using JavaScript, in a way that isn’t already achievable with multiple input fields?

Since PHP has long been the de facto reference source for handling form data and arrays, it would make sense to look to its conventions for guidance. e.g. https://stackoverflow.com/questions/9073690/post-an-array-from-an-html-form-without-javascript/45233604

n.b. Passing indices is unnecessary and complicates matters, arrays are ordered by definition

[sina-salahshour]

Is it possible to make remote function endpoints have unreadable names and not exported variable name in prod environment?

[paoloricciuti]

Wouldn't this help you debug stuff? What would be the advantage of having them mangled? Security through obscurity is never a good idea

[rebasecase]

Security through obscurity is never a good idea

An often repeated meme...

In practice, obscurity can serve as a useful layer in a defence in depth strategy. In any road lossless encryption is only obfuscation, just using complex mathematics.

Pedantry aside.. Using garbled function and property names can be a good first line of defence to reduce the visibility of your API surface and deter opportunistic attacks.

That said, I think this should be out of scope. This can be done with a postprocessor, should such extensibility points exist. You could try and argue it could be mangled for the sake of optimising a few 10s of bytes! This would definitely hinder debugging.

[samuba]

But they're not just promises, they also provide properties like loading and current..

Do they also get a error property? If I understand correctly we could then have this, with no need for svelte boundary usage.

const todos = getTodos()
...

{#if todos.loading}
   loading...
{:else if todos.error}
   failed: {todos.error.message}
{:else if todos.current}
   {#each todos.current as todo}
      {todo.name}
   {/each}
{/if}

[rebasecase]

I do not think they should have an error property. Conceptually, your error boundary is equivalent to a catch statement.

The status of these promise-like objects is either that they succeeded or they failed. If they fail, that failure is handled by the error boundary, not by setting an error property.

So, having an error property on the object isn’t necessary, since the error boundary already serves that role.

[KTibow]

IMO it makes more sense to either just use a boundary or use #await if you want syntax closer to what was proposed

[aster-void]

the code example doesn't use await keyword, therefore it should be possible to handle error state without await either.

the svelte:boundary should become the error boundary when and only when it uses await keyword in the component.

[dummdidumm]

We could add an error property to allow this, yes.

[sina-salahshour]

after having async svelte, what problems does builtin remote functions solve that third party libraries like orpc doesn't?
they also have more complex feature set because the main focus of library is that specific problem.

[novaotp]

Not having to import a third party library for something like data fetching, for instance.

[sina-salahshour]

my problem with that is, it has additional cases that builtin one doesn't handle and gives forced defaults without ability of changing them.
it has tanstack query like features, but not all of them and without configuration. same with orpc

[sina-salahshour]

and also it's not essential for the framework to run. i mean yes, async is very nice and made new things possible and easier to handle. also it wasn't possible to be handled by third party libraries. but it's not the same with the remote functions

[dummdidumm]

• built in
• deep integration with the rest of the framework (for example it knows about the transport hook, or you can redirect from a query)
• SSR+hydration support
• progressive enhancement via remote form functions
• single flight mutations

[Rich-Harris]

• nicer API (subjective, but... true)
• more flexibility about where you put your server-side logic — things like oRPC and tRPC kind of expect you to define everything in one place, or at the very least have a central RPC router, which makes them a not-great fit for the BFF pattern in which server-side logic that's only needed for a specific feature of your app is defined alongside that feature

TanStack Query is a totally different beast — it's completely backend-agnostic. It has nothing to say about how your client and server talk to each other beyond giving you a place to solve that problem yourself. Remote functions, on the other hand, are about solving that problem. (In fact you could use remote functions inside your TanStack queryfn; there'd just be no point.)

[cooolbros]

1. Would it be possible to add a simple object router for .remote.js files?

import { query, command, router } from "$app/server"
export const comments = router({
    get: query(z.string(), { ... }),
    create: command(z.object({ text: z.string() }), ({ text }) => { ... }),
    edit: command(z.object({ id: z.string(), text: z.string() }), ({ id, text }) => { ... }),
    delete: command(z.string(), (id) => { ... }),
})

This would just help to organize remote.js files with many functions, as well as reduce the number of imports and add autocompletion when calling remote functions from .svelte files

(As an alternative you could import * as comments from "comments.remote.js, but it would only support 1 level of depth)

---

2. Do querys send POST requests when called from the browser?

If not the size of the serialized input will be limited when using a reverse proxy with Sveltekit (for example nginx's large_client_header_buffers), tRPC solved this with allowMethodOverride, which sends query input data in the body of a POST request.

[dummdidumm]

1. So far there are no plans to add support for something like this, I'm not sure this level of nesting is valuable
2. Queries send GET requests. We will see how far it goes with respect to the input, we may add some kind of support to switch over to POST (maybe even automatically) if the URL gets too large. What kinds of queries are you doing where you are hitting limits?

[AndreasHald]

Something we use quite a lot of is another loading indication sometimes called delayed or slow essentially just derived from the loading value and deferred by x ms. This is really useful to avoid UI flickering if the query/form resolves really quickly.

Superforms has a really great page about the concept

Anyway I'm fairly certain you will wan't people to solve this in userland, I just wanted to suggest it in case you had not thought about it.

[saruman-tech]

Hello, I want to know when this feature will be released. It doesn't work when I pull the sample. I really need this feature. I am deeply troubled. When I need to connect to multiple backend APIs, I need to add +server.ts first and then add load. The code structure is very messy and there are a lot of boilerplate codes. This feature perfectly solves all the problems without the need for an additional bff layer service.

[JensvanZutphen]

check the PR #15844 sveltejs/svelte#15844

[JensvanZutphen]

also this one #13986

[aster-void]

We must think of naming convention for this, it's very confusing otherwise:

<!--
is `getLikes` a normal async function or a remote query?
if this is normal function, it should be deduped to reduce network traffic.
-->
<span>
{await getLikes(post.id)} likes
</span>

<!-- somewhere else ... -->
<LikeButton
  count={await getLikes(post.id}
  onclick={() => {
    // is `like` just an async function or a remote command?
    // if it's a command, it should update the getLikes with `updates` for one-round trip update.
    await like(post.id);
    await getLikes(id).refresh();
  }}
/>

[aster-void]

I'm thinking of something like

xxxQuery for queries
xxxCommand for commands

because

• it's very clear that these are queries and commands
• it's auto-completion friendly
• although slightly verbose

[dummdidumm]

You are free to impose naming conventions on your projects but we will not force anything like that

[ESchouten]

Would remote functions SSR work with workbox-strategies?
This service worker native way of caching and syncing data being incompatible with the load function SSR is a big part of having to opt out of SSR for applications that should remain working offline.

[Rich-Harris]

Can you elaborate on what that entails exactly? If it means something like 'populating a cache with server-rendered data' then no, I don't think it would be, but I would like to explore turnkey strategies for this stuff that are better integrated with the framework.

Things like workbox involve you duplicating your routes in your service worker, which is convoluted and brittle (no shade, that's just what's required of an unopinionated solution) — to my eyes it would be better if you defined things like 'this query can be cache-first, this one should be network-first, this one is network-only' in the query. SvelteKit can populate caches on startup with server-rendered data, while respecting your strategy and cache duration preferences (prerender data can be cached immutably, of course, as long as the cache key includes the deployment version).

Note that since we control the requests, we don't even need a service worker for this to work — we can just inspect window.caches directly (though it would work fine with your service worker if you were using one to e.g. make pages available offline).

[sillvva]

Will you be able to call the remote functions from the <script module> block of a page?

[Rich-Harris]

You can call them from wherever your heart desires