Remote Functions

[dummdidumm]

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 any number of arguments. The arguments are serialized with devalue, which handles types like Date and Map in addition to JSON, and takes the transport hook into account.

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

export const getLikes = query(async (id: string) => {
  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 { query, form } from '$app/server';
import * as db from '$lib/server/db';

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

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 to 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 {
    await submit();

    // if this occurs immediately after the submission,
    // it will prevent a global refresh
    getLikes(item.id).refresh();
  } 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.

We can go one step further and enable single-flight mutations — meaning that the updated data for getLikes(...) is sent back from the server along with the form result — by moving the refresh call to the server:

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 { query, form } from '$app/server';
+import { query, command } 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;
+export const addLike = command(async (id: string) => {

  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 for a single-flight mutation, or on the client after the command has run, 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 { prerender } from '$app/server';

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

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 { prerender } from '$app/server';

export const getBlogPost = prerender((slug: string) => {
  // ...
}, {
  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 { prerender } from '$app/server';

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

Optimistic updates

Queries have an override method, which is useful for optimistic updates. It receives a function that transforms the query, and returns a function that removes the override:

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

<button
  onclick={async () => {
+   const release = getLikes(item.id).override((n) => n + 1);

    try {
      await addLike();
    } catch (error) {
      showToast(error.message);
+   } finally {
+     release();
    }
  }}
>
  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.override(...) 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, releasing the override will decrement it again, otherwise the updated data (sans override) will match the optimistic update.

Validation

Data validation can be performed with the validate function, which accepts a Standard Schema object and a callback:

import { validate } from '@sveltejs/kit';
import { query } from '$app/server';
import { z } from 'zod/v4';

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

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
  })
);

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 =)

[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

[bobTheBuilder7]

<script>
const users = await getUsers() // a remote function
</script>

1. I guess it will be using fetch api for this, how are we going to set request timeouts, cancellations.
2. What if the server throws an error, how is it going to be handled on the client side?
3. In getUsers function on the server, will we have access to locals?
4. Will hooks.server.ts be called before [file].remote.ts?

[Rich-Harris]

1. the framework can handle cancellations on your behalf — it should only be cancelled when the query is no longer used, or has been refreshed. haven't thought about timeouts
2. the error will be thrown on the client (with message/stack redacted if it didn't use error(...)) and be caught by the nearest error boundary
3. yes
4. yes

[sydlos]

I noticed that command would throw serialization errors when we try to send unicode data like emojis. Apparently character limitations of the underlying atob/btoa functions.
There might be a reason for this behavior, but it's helpful to be aware.

[samuba]

Please tell me this is considered a bug and will be fixed. It's totally unexpected and will be a real pain in the ass to debug in prod.

[Rich-Harris]

of course it's a bug

[ottomated]

Tanstack Query's refetchOnWindowFocus option is enabled by default and is very valuable imo, is that something that can be provided by the framework? It could be implemented in userland but document visibility can be janky iirc.

[Rich-Harris]

it's basically just this

<svelte:window
  onvisibilitychange={() => {
    if (document.visibilityState === 'visible') {
      refreshAll();
    }
  }}
/>

[ottomated]

That gets pretty close, I think tanstack query also takes staleness into account somehow to avoid spamming refreshes. Do you think it's not a sensible default, in that case?

[Rich-Harris]

takes staleness into account

what do you mean by this?

[ottomated]

Tracks how long since a query has been fetched and only re-fetches if it's older than N seconds

[Rich-Harris]

That should probably be up to the query — we don't have this yet, but are thinking along these lines:

// on the server
export const my_query = query(() => {
  query.cacheFor(30);
  return whatever;
});

Any refresh of my_query() within this window would be a no-op.

[irsyadpage]

I'm planning on svelte project where the same code deploys on multiple server with different subdomain for fault-tolerance. Is there any possibility to allow cross-origin remote function call?

[dummdidumm]

Could you describe your use case in more detail? I don't really understand how you would (want to) model a fallback from one subdomain to the other

[irsyadpage]

The project has the following properties:

• The sveltekit app must be deployed on multiple servers with different domain for fault-tolerance and to avoid single point of failure (SPOF). So the app can be accessible via *.domain.com where each subdomain pointing to a specific server. Using load balancer in front of these servers is unsuitable as the load balancer itself could became SPOF.
• The app use localStorage or IndexedDB for storing data and offline access. This storage has same-origin policy.
• If server a.domain.com is down, I would like to call the remote function at b.domain.com without redirecting the whole app. Redirecting the whole app to new a subdomain would cause the data in localStorage or IndexedDB from previous subdomain is inaccessible as the storage has same-origin policy.

Let me know if anything is unclear.

[dummdidumm]

Remote functions are inherintely connected to their own backend, i.e. the domain they run on. We could make remote functions allow cross origin through setting the csfr option to false, and you could then patch fetch to not go to subdomain a but b. So it would be doable but a) I don't think this is a good design to make a fault tolerant app b) we won't explicitly support that / consider this in our design decisions.

[irsyadpage]

Yeah, it is not really a good design. Thank you for the feedback. Much appreciated 👍.

[Bewinxed]

I think you can enable this via server hooks? If you're referring to cross site submissions the only workaround I know of atm is setting checkOrigin to false

…

On Sat, 28 Jun 2025 at 6:57 PM Irsyad Aminuddin ***@***.***> wrote: I'm planning on svelte project where the same code deploys on multiple server with different subdomain for fault-tolerance. Is there any possibility to allow cross-origin remote function call? — Reply to this email directly, view it on GitHub <#13897 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACFY5BKGAG2CGYDI3O5Q3E33F23PFAVCNFSM6AAAAAB7QZ57FKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGNRQGU3DINQ> . You are receiving this because you commented.Message ID: ***@***.***>

[shivan-s]

This will be useful @shivan-eyespace.

[KTibow]

i hope command will use devalue

[Rich-Harris]

It does

[Thiagolino8]

It would be nice if remote functions with validation performed the validation on the client as well to avoid a wasteful trip, especially form actions

[Rich-Harris]

There's validation and there's validation. The kind that you're talking about - 'this string should be a valid email address' - makes sense in the client (it's a subset of the validation you would conduct inside a command/form function, which also includes stuff that only makes sense on the server like 'this email is already in use').

But that's not what the built-in validation is for. Built-in validation is to ensure that a malicious actor isn't trying to trick your app into doing something it shouldn't (like deleting the wrong data, or showing data to someone it doesn't belong to) by sending data of the wrong type. There is no reason to do that in the client since that's not the route the malicious actor is taking.

The first kind of validation should result in useful feedback and form controls being repopulated; the second should result in a generic 400 that gives as little information to attackers as possible. They're different things and really ought to have different names, though I'm not sure what those names should be!

[ollema]

is the first kind of validation something that sveltekit will solve/provide or something we will have to implement on our own or with superforms?

[Rich-Harris]

For things like 'is this an email address?' what API could we provide that would be better than existing libraries like Zod and Valibot? For things like 'is this email address already in use?', what API could any library provide? I'm not sure the problem is well-specified enough for SvelteKit to offer a first-class solution

[ollema]

I'm not sure what the best API is, I am very humble in that I have much less experience designing web frameworks, so I will just describe how I work with client/server validation right now and how I interpret that it will work in the future

right now with superforms you just have to define your schema once, and it is validated both on the client and on the server, which is a great user experience and also a great dev experience IMHO.

for the email address form example, let's say that I define this schema in schema.ts.

with superforms, using the single schema.ts file:

• I can trust the data on the server and know the the type is correct
• the user is given immediate feedback if they input something that does not conform to the schema, in this case an invalid email address

but with the new form function, I can define the same schema.ts and use that with validate to:

• I can trust the data on the server and know the the type is correct
• if the user inputs an invalid email address, they have to wait until the full form is submitted and for the server to validate before I can present feedback to the user
• in some cases this can be avoided by using the platform to add input validation properties. but those are not as expressive as Standard Schema schemas and I would also then have to define the schema twice, once on the server and then try to port it to validation attributes

--

so basically, what I am trying to say is that it would be cool if SvelteKit also allowed me to progressively enhance my forms so that it is possible to use the same schema for server AND client side validation.

on the server you would often have to perform additional validation as in "is this email address already in use?" but that is not what I am trying to describe here

[codepainting]

The point here is not to have to write the following type of validation twice — e.g.:

z.string().max(256, { message: "Must be 256 or fewer characters" });

So we use one schema file, which is being used by the client and the server. The advantage being, that a single schema file guarantees that the client and server validation does not get out of sync.

The "is this email address already in use?" type of "validation" would indeed be better named differently, since this is business logic (not schema validation).

[bennymi]

Maybe a stupid question, but do remote functions work without a server? I know it's implied in the name that they live on the server... but wondering if they would still work for pure SPAs that call other APIs client side, or if there are plans to offer a similar functionality as the query function for SPAs that also provide the .loading , refresh(), and .override() methods, because they are really useful. Or is this something that is expected to be implemented in user land?

[Rich-Harris]

prerender functions will work without a server. Queries and commands require a server by definition, but we intend for 'resources' (the things with .loading and .refresh() and .override(...)) to be part of Svelte; query functions would return resources in the client, and objects with a resource-like API on the server. So you would be able to create (and refresh) non-query resources in any Svelte SPA.

[exentrich]

It would be great if all remote functions could work even in a static build. The idea is simple: I want to host my web app on Vercel or Cloudflare Pages with server-side rendering for better TTFB, but also be able to export it as a static build and package it as a desktop Electron app — all while still fetching data from an external API.

[builtbybengt]

Thats actually very awesome. A problem for me was always that form actions are always had a coupling to the route and this fixes it. Great work.

[l0uisgrange]

Hi, great work, I love it! Do you have any idea of a release date or timeframe for when this feature might be available as experimental? Just curious if we're talking weeks, months, or next year.

[filiabel]

Hopefully very soon - weeks rather than months (...)

#13897 (reply in thread)

[l0uisgrange]

Thanks @filiabel, I missed it!

[garytube]

About streaming and realtime applications:

My main usecase would displaying changes to all visitors of a given site.

I currently work on a site where race results (round times on a track) get uploaded for attendees to look at. Once uploaded & processed the new race results should displayed. Without having to do setinterval.fetching...

[codepainting]

Steaming and real-time use-cases in our application:

1. Show user avatars of users joining a collaborative document
2. Live cursor for select users and highlighting of objects selected/edited by those users
3. Live updates of edited objects in the opened document (after object has been edited and the change submitted by editor)
4. RT comments in context of the opened document
5. Real-Time notifications (like "new message in inbox", "new comment" etc.)
6. Background sync of document listings (new documents created by other users show up in listings)
7. (and later chat)

[beowulf11]

I wanted to share my current setup with streaming response from +server.ts endpoints. I am developing an AI application so a lot of streaming is necessary to inform the user of ongoing activity.

I use a combination of SSE and returning a ReadableStream.

I have and endpoint which generates a summary of a document. This is the return from the POST api.

...
const geminiResponse = await gemini.models.generateContentStream({
   ...
})

const stream = new ReadableStream({
  async start(controller) {
    for await (const chunk of geminiResponse) {
      send(controller, chunk.text);
    }
    controller.close();
  },
});

return new Response(stream, {
  headers: {
    'Content-Type': 'text/event-stream',
  },
});

and then on the client I do

export async function * streamReader<T = any>(stream: ReadableStream<Uint8Array<ArrayBufferLike>>) {
    let buffer = '';
    const reader = stream.pipeThrough(new TextDecoderStream()).getReader();

    for (;;) {
        const { value, done } = await reader.read();
        if (done) break;
        buffer += value;

        let idx;
        while ((idx = buffer.indexOf('\n\n')) !== -1) {
            const raw = buffer.slice(0, idx).trim();
            buffer = buffer.slice(idx + 2);

            if (!raw || raw.startsWith(':')) continue; // heartbeat/comment

            let data = JSON.parse(raw.replace(/^data:\s*/, '')) as T;

            yield data;
        }
    }
}

...

const call = await fetch(url, { method: 'POST' });
for await (const chunk of streamReader<string>(call.body)) {
    ...
}

It works pretty well but I had some problems with closing the stream and ERR_QUIC_PROTOCOL_ERROR but that seems to have been incorrect usage of headers and using Cloudflare.

In addition if I need to re-observe an operation in progress I use a very similar setup but with SSE.

Hope it helps :).

[thedelanyo]

Aside from the .remote.ts filename conversion, it'll be great if we can also adopt a remote folder 📂 similar to what we have for server.