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.

[samuba]

I replaced telefunc calls in my app with remote functions and see interesting performance results:

Basically remote functions are slower and have bigger return bodies for the same data. I've run this many times over, and results are consistent.
We see that telefunc calls return mostly in the 50-60ms range whereas remote functions return mostly in 70-80ms.
Might be interesting to look at telefuncs implementation for further optimization.

Remote functions calls:

Telefunc calls:

Its exactly the same implementation, the only big difference is that, with remote functions, params are obviously no longer validated by telefunc shield but with valibot.

You can inspect this in my app just by (endless) scrolling down the home page. It loads new entries via telefunc/remoteFunctions.
Telefunc version: https://blissbase-4txkful17-samubas-projects.vercel.app/
RemoteFns version: https://blissbase-git-remote-fns-samubas-projects.vercel.app/
Its hosted on vercel standard in FRA1

[jjones315]

imo there are way to may variable to narrow down the latency, for what its work i looked at this and remote functions were 20% faster

[samuba]

Looks like your querying far away from FRA1. Its not surprising that network latency would overshadow this.
I think I'm gonna put up a simplified example of this and measure locally and on cloudflare workers as they deploy to all regions by default

[dummdidumm]

A minimum reproducible with access to the code would be good

[samuba]

Heres a simple app that runs both back to back and measures the speed: https://stackblitz.com/edit/sveltejs-kit-template-default-wkp4qxd8

Ive actually not been able to reproduce my measures from the real world app. But the measures I'm seeing are also interesting:

Local M2 Macbook: Telefunc 20% faster
Vercel: Fluctuating, most of the time Telefunc ~4% faster (sometimes remote functions 1% faster)
Cloudflare: Virtually no difference
Stackblitz: Remote Functions 80% faster (everythings in memory here I guess, still interesting)

Takeaway: Maybe Telefunc scales a bit better with more CPU/RAM?

Vercel hosted: https://svelte-rfns-test-hv49omeqa-samubas-projects.vercel.app/
Cloudflare hosted: https://svelte-rfns-test.szb.workers.dev/

[jjones315]

i ran your project from stackblitz locally (m3 pro mac and intel 14900k WSL)

in dev mode telefunc was usually around 10% faster, running a production build with vite build && vite preview remote functions were 5% faster running 500 calls, running 50 calls it was a toss up, often flipping back and forth.

i did switch to adapter-node and pnpm just out of habit, everything else was the same.

[LaneSun]

Are there any plans to integrate Remote Functions with Rune? After seeing the query.stream draft, I think this might be achievable.

A possible syntax could look like this:

// .remote.js

let a = $state(1);

export const getA = query(() => a);

export const setA = command('unchecked', (count) => a = count);

// .svelte

let a = $derived(getA());

// ...

<span>Counter: {a}</span>
<button onclick={() => setA(a + 1)}>Add</button>

Then, every time "Add" is clicked, the remote side would automatically detect that getA needs to be updated (thanks to Rune) and push the new result to the browser.

Of course, this approach breaks the stateless nature of the server, which might be intimidating. But consider the following code:

// .remote.js

const create_counter = () => {
    let count = $state(1);
    return {
        setCount: command('unchecked', c => count = c),
        getCount: query(() => count),
    };
};

export const load = () => {
    return {
        ...create_counter(),
    };
};

// .svelte

let { data } = $props();

let count = $derived(data.getCount());

// ...

<span>Counter: {count}</span>
<button onclick={() => setCount(count + 1)}>Add</button>

Personally, I often use SvelteKit to develop local applications, where Kit simply provides access to the local machine. In such cases, statelessness is more of a hassle than a benefit.

Also, while I'm not entirely sure about Rune's exact implementation, I think compiling the Rune version of Remote Functions into async generators would be relatively straightforward to implement and more consistent with the previously mentioned query.stream.

[Rich-Harris]

We don't plan to do this, no — it would be a complete reversal of how things currently work in Svelte. $state and $derived are only turned into signals when the compiler is targeting the browser, not the server, and that's part of why server-side rendering is so fast and memory-efficient in Svelte.

While stateful servers might be convenient for some tasks, they're a bad fit for the majority of apps. Even if you're running your own Node server (instead of using a serverless platform), it's rare that you want server-side state to be shared by all users, and if you have a per-user copy of everything then you've created a hell of a memory-management challenge for yourself. Just use a database!

[uglyreptile]

Regard to the query.stream feature, any approximate time of implementing it?

[aster-void]

What will be the most idiomatic way to use a database with realtime data updates?

AFAIK query.stream only streams events. (or does query.stream also deliver live data?)

[Rich-Harris]

any approximate time of implementing it?

As soon as we have time!

(or does query.stream also deliver live data?)

What's the difference?

[aster-void]

The main difference will be if they are fired on initial connection.

// this doesn't need to (and shouldn't) fire on initial connection
export const mentionsEvents = query.stream(async function* () {
  const userId = await getUserId();
  for (const ev = await eventEmitter.on("messageSend")) {
    if (ev.mentions.includes(userId)) {
      yield ev;
    }
  }
});

// this should.
export const messagesQuery = query.live(async (set) => {
  // assume this is the live DB client
  messagesStore.subscribe(set);
});

and the client expectations are also different.

// there is no "awaiting a mention" - it may or may not ever happen
mentionsEvents.subscribe((data) => {
  alert(`${data.sender} mentioned you: ${data.message}`);
});

// it should resolve after some loading
const messages = await messagesQuery();

[hugo-hsi-dev]

Hi all, I ran into an issue where consuming a single piece of state in two or more different queries caused lots of weird issues including warning spam in the browser console and de-synced query state in some scenarios. Here's the issue for more detail #14113.

My post here is not to rush the maintainers in fixing the bug that I found. Instead, I want to see if anyone else has encountered this bug, how they worked around it, and if there are any temporary solutions that others are using. I've seen a few people say here that the already shipped RFs to prod and fail to believe that not a single one of those have needed to send a single piece of state to two queries. Seems like this should be a pretty common use case for async and RFs.

[RonenEizen]

Hi. Not sure if this is a bug in remote functions. I noticed that all remote functions' route.id is set to null regardless where the file is saved when the handler receives a request event in hooks.server.ts. For instance, we are using (private) directory to store all of our protected routes in routes folder. All files, except for remote function files, will have route.id set to something like /(private)/[route].

[Rich-Harris]

This is by design. The behaviour of a remote function shouldn't depend on where it exists in your project

[RonenEizen]

Any suggestion on what to use inside of the hook to distinguish different remote functions, like those that are private and public for example? I wouldn't want to manually manage a map of function names.

[saturnonearth]

Hi. Not sure if this is a bug in remote functions. I noticed that all remote functions' route.id is set to null regardless where the file is saved when the handler receives a request event in hooks.server.ts. For instance, we are using (private) directory to store all of our protected routes in routes folder. All files, except for remote function files, will have route.id set to something like /(private)/[route].

See #14084.

This is by design. The behaviour of a remote function shouldn't depend on where it exists in your project

Honestly I think this adds some confusion, as SvelteKit is a filesystem-based router, so all having remote functions not be able to access their location relative to the file structure seems odd to me. I think it's a pretty common pattern to check the route.id and pass in data via locals based on that.

[Rich-Harris]

Not nearly as much confusion as you'd cause by having functions behave differently based on where they're declared! Especially when a new hire comes along and says 'it would be so much simpler if all these remote functions lived in src/lib' and next thing you know you're leaking sensitive data.

The pattern of doing auth stuff based on route ID is playing with fire, honestly. If a certain function should only be callable by a certain kind of user, express that in the function itself, as close to the data access as possible. We shipped getRequestEvent to make this easy:

// src/routes/(private)/data.remote.ts
import { query } from '$app/server';
import { check_if_stonecutter } from '$lib/auth';

export const who_controls_the_british_crown = query(async () => {
  await check_if_stonecutter();
  return 'we do';
});

export const who_keeps_the_metric_system_down = query(async () => {
  await check_if_stonecutter();
  return 'we do';
});

import { error } from '@sveltejs/kit';
import { getRequestEvent } from '$app/server';

export function check_if_stonecutter() {
  const event = getRequestEvent();
  const is_stonecutter = (event.locals.user_is_stonecutter_promise ??= user_is_stonecutter(event.cookies));

  if (!is_stonecutter) {
    error(401, 'Not a stonecutter');
  }
}

This way, it's easy to see just by looking at the function what the requirements are, and it will survive refactorings intact. And you can of course use function composition if you prefer:

function stonecutter_query(fn) {
  return query(async () => {
    await check_if_stonecutter();
    return fn();
  });
}

export const who_controls_the_british_crown = stonecutter_query(() => 'we do');
export const who_keeps_the_metric_system_down = stonecutter_query(() => 'we do');
export const who_keeps_atlantis_off_the_maps = stonecutter_query(() => 'we do');
export const who_keeps_the_martians_under_wraps = stonecutter_query(() => 'we do');

We also don't really want to be using the filenames to encode these endpoints (which is the only way you could really do anything useful with route.id). As weird as it would be to see calls to _app/remote/src/routes/(private)/utils/data.remote.ts/whatever/xyz123 in your network activity, it would be weirder still (not to mention not very useful) when those route IDs are things like ../../node_modules/.pnpm/@[email protected]/node_modules/@stuff/some-library/src/lib/data.remote.ts.

[saturnonearth]

Often times it's easier to run permission checks at a route/folder level, instead of in every single remote function or form action etc. At least on a basis of, "is user logged in", and then more fine grained checks on a file level. I'd actually argue this is often safer as if you forget to throw all the correct permission checks in a new server file, you are potentially exposing those functions to someone who is unauthorized.

it would be so much simpler if all these remote functions lived in src/lib' and next thing you know you're leaking sensitive data.

You have a good point, but at the same time, people moving files around in your system could always lead to security vulnerabilities.

Not nearly as much confusion as you'd cause by having functions behave differently based on where they're declared!

Yea I do agree, but that is sort of a more grandeur conversation about how hooks should be used, and the reason why this pattern is popular (imo) is because it helps solve SvelteKits lack of (proper) middleware support, where routes are used as middleware instead (since layouts are run once).

I hope this makes sense 🙏

[Tam2]

Not sure if it's us doing something wrong or a bug... We've create a remote function within a library

Then within the sveltekit application we're importing the remote function from the library (all the types are perfect)

But when navigating to the page it gives us a 404 not found when trying to run the remote function

Both library and sveltekit are on version 2.27.3 with svelte version 5.38.0 and the experimental flag is set

[Tam2]

Looks like there is a discussion open as you can't have remote functions within node_modules currently

#13979

[KTibow]

Is this a bug?

Edit: PR to fix: #14161

/t/repro (main)> cat svelte.config.js
import adapter from '@sveltejs/adapter-cloudflare';
import { vitePreprocess } from '@sveltejs/vite-plugin-svelte';

/** @type {import('@sveltejs/kit').Config} */
const config = {
	// Consult https://svelte.dev/docs/kit/integrations
	// for more information about preprocessors
	preprocess: vitePreprocess(),
	kit: { adapter: adapter(), experimental: { remoteFunctions: true } },
	compilerOptions: { experimental: { async: true } },
};

export default config;
/t/repro (main)> cat src/routes/resources.remote.ts
import { query } from "$app/server"
export const getResource = query(() => 1)
/t/repro (main)> cat src/routes/+page.svelte
<script lang="ts">
  import { getResource } from "./resources.remote.ts"
</script>
{await getResource()}

/t/repro (main)> git status

On branch main

nothing to commit, working tree clean

/t/repro (main)> pnpm build
Build output
> [email protected] build /tmp/repro
> vite build
vite v7.1.1 building SSR bundle for production...

✓ 190 modules transformed.

vite v7.1.1 building for production...

✓ 150 modules transformed.

.svelte-kit/output/client/_app/version.json                        0.03 kB │ gzip:  0.05 kB

.svelte-kit/output/client/.vite/manifest.json                      2.62 kB │ gzip:  0.53 kB

.svelte-kit/output/client/_app/immutable/entry/start.C_CnNc8Q.js   0.08 kB │ gzip:  0.09 kB

.svelte-kit/output/client/_app/immutable/chunks/CPGlLPED.js        0.11 kB │ gzip:  0.12 kB

.svelte-kit/output/client/_app/immutable/nodes/1.Bhxknu2O.js       1.01 kB │ gzip:  0.59 kB

.svelte-kit/output/client/_app/immutable/nodes/0.B7-fAMIj.js       2.68 kB │ gzip:  1.18 kB

.svelte-kit/output/client/_app/immutable/nodes/2.CQ2dASY0.js       2.91 kB │ gzip:  1.37 kB

.svelte-kit/output/client/_app/immutable/chunks/BcPHx9wQ.js        3.76 kB │ gzip:  1.98 kB

.svelte-kit/output/client/_app/immutable/entry/app.DWVKQ3RS.js     7.24 kB │ gzip:  3.44 kB

.svelte-kit/output/client/_app/immutable/chunks/Cfg3jylY.js       21.45 kB │ gzip:  8.60 kB

.svelte-kit/output/client/_app/immutable/chunks/CWiWHjCW.js       35.25 kB │ gzip: 13.76 kB

✓ built in 282ms

vite v7.1.1 building SSR bundle for production...

✓ 3 modules transformed.

dist/optimized/m85zqv.js  0.36 kB

dist/remote-entry.js      5.92 kB

✓ built in 9ms

.svelte-kit/output/server/.vite/manifest.json                  4.08 kB

.svelte-kit/output/server/chunks/false.js                      0.04 kB

.svelte-kit/output/server/remote/m85zqv.js                     0.16 kB

.svelte-kit/output/server/chunks/environment.js                0.19 kB

.svelte-kit/output/server/entries/pages/_page.svelte.js        0.37 kB

.svelte-kit/output/server/internal.js                          0.40 kB

.svelte-kit/output/server/chunks/paths.js                      0.41 kB

.svelte-kit/output/server/chunks/escaping.js                   0.53 kB

.svelte-kit/output/server/chunks/event.js                      0.82 kB

.svelte-kit/output/server/chunks/equality.js                   1.23 kB

.svelte-kit/output/server/entries/fallbacks/error.svelte.js    1.31 kB

.svelte-kit/output/server/entries/pages/_layout.svelte.js      2.88 kB

.svelte-kit/output/server/chunks/query.js                      4.54 kB

.svelte-kit/output/server/chunks/index.js                      5.29 kB

.svelte-kit/output/server/remote-entry.js                      6.44 kB

.svelte-kit/output/server/chunks/exports.js                    6.87 kB

.svelte-kit/output/server/chunks/event-state.js               15.39 kB

.svelte-kit/output/server/chunks/internal.js                  59.55 kB

.svelte-kit/output/server/index.js                           131.48 kB

✓ built in 1.83s
Run npm run preview to preview your production build locally.

Using @sveltejs/adapter-cloudflare

✔ done

/t/repro (main)> git status
On branch main
Untracked files:
  (use "git add ..." to include in what will be committed)
	dist/

nothing added to commit but untracked files present (use "git add" to track)
/t/repro (main)> cat .gitignore # Default gitignore for Cloudflare adapter
node_modules

# Output
.output
.vercel
.netlify
.wrangler
/.svelte-kit
/build

# OS
.DS_Store
Thumbs.db

# Env
.env
.env.*
!.env.example
!.env.test

# Vite
vite.config.js.timestamp-*
vite.config.ts.timestamp-*
/t/repro (main)> ls .svelte-kit/cloudflare # Designated Cloudflare outputs
404.html  _app/  _headers  robots.txt  _routes.json  _worker.js
/t/repro (main)> tree dist # Mysterious `dist` folder
dist
├── optimized
│   └── m85zqv.js
└── remote-entry.js

2 directories, 2 files

[yorickvandervis]

A very basic setup with the sv cli tool including drizzle for database doesn't seem to build whenever a db call is used in the remote functions. Maybe I don't understand good enough, but I'd preferably use the dynamic over static DATABASE_UL import in the db/index.js here right? When I comment out the remote function code it builds fine though.

Error: DATABASE_URL is not set

repro: https://stackblitz.com/edit/sveltejs-kit-template-default-wjfgbmzy?file=src%2Flib%2Fremote-functions%2Fpost.remote.ts

[paoloricciuti]

You should wrap the with if(!building) the statement that can't execute during building...but i actually think there's a bug here: the env is not set during prerendering and that's why it fails

[paoloricciuti]

In the meantime if you want to fix this specific bug and it's possible you can fix this issue by using the static environment instead of the dynamic environment

import { drizzle } from 'drizzle-orm/libsql';
import { createClient } from '@libsql/client';
import * as schema from './schema';
-import { env } from '$env/dynamic/private';
+import { DATABASE_URL } from '$env/static/private';

-if (!env.DATABASE_URL) throw new Error('DATABASE_URL is not set');
+if (!DATABASE_URL) throw new Error('DATABASE_URL is not set');

-const client = createClient({ url: env.DATABASE_URL });
+const client = createClient({ url: DATABASE_URL });

export const db = drizzle(client, { schema });

[paoloricciuti]

#14219

Opened this to fix this

[0xMurage]

Yes, remote functions need to be analyzed at build time.

What is the reasoning behind this, especially when I have pre-render turned off globally?

[Rich-Harris]

SvelteKit needs to know which remote functions exist

[samuba]

Do I understand correctly that only queries have loading, error and current?
Because I'm looking for an elegant way to do this without having to come up with this try block and the corresponding pending and error variables boilerplate every time:

<script> 
  import { deleteItem }

  let pending = $state(false)
  let error = $state("")
  
  async function onDeleteItem() {
    pending = true
    try {
       await deleteItem()
    } catch() {
      error = err.message
    } finally (err) {
      pending = false
    }
  }
</script>

<button onclick={() => onDeleteItem()}>
  {#if !pending}
    Delete
  {:else if}
    Deleting <LoadingSpinner />
  {/if}
 </button>

{#if error}
  <span> Error during deletion: {error}<span>
{/if}

Ideally I want something like this. Where magicThingy returns something like a reference to the command:

<script> 
  import { deleteItem }

  let deleteCmd = magicThingy(deleteItem)
</script>

<button onclick={() => deleteCmd.execute()}>
  {#if !deleteCmd.pending}
    Delete
  {:else if}
    Deleting <LoadingSpinner />
  {/if}
 </button>

{#if deleteCmd.error}
  <span> Error during deletion: {error}<span>
{/if}

[jjones315]

this should work for you, i wrote it before command had pending, and still use it in a few places where i need result/error access like this

class LocalCommand<TInput, TOutput> {
    #command: RemoteCommand<TInput, TOutput>;
    result = $state<Awaited<TOutput>>();
    error = $state<unknown>();
    pending = $state(false);
    constructor(command: RemoteCommand<TInput, TOutput>) {
        this.#command = command;
    }

    async execute(input: TInput): Promise<Awaited<TOutput>> {
        this.pending = true;
        try {
            const result = await this.#command(input);
            this.result = result;
            return result;
        } catch (error) {
            this.error = error;
            throw error;
        } finally {
            this.pending = false;
        }
    }
}

export const createCommand = <TInput, TOutput>(command: RemoteCommand<TInput, TOutput>) => new LocalCommand(command);



//use
const deleteCmd = createCommand(deleteItem)

might need some tweaking for your use case, but should get you most of the way to magicThingy

[skaldebane]

Just created a new Svelte project with sv create, and added Drizzle and Lucia with the demo login page.

It works perfectly out-of-the-box, but when moving login/signup form actions into form remote functions, builds started failing with this message:

1:26:44 PM [vite] (client) error while updating dependencies:
Error: Error during dependency optimization:

✘ [ERROR] Could not resolve "@node-rs/argon2-wasm32-wasi"

    node_modules/.pnpm/@[email protected]/node_modules/@node-rs/argon2/browser.js:1:14:
      1 │ export * from '@node-rs/argon2-wasm32-wasi'
        ╵               ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  You can mark the path "@node-rs/argon2-wasm32-wasi" as external to exclude it from the bundle, which will remove this error and leave the unresolved path in the bundle.


    at failureErrorWithLog (.../memo-demo/node_modules/.pnpm/[email protected]/node_modules/esbuild/lib/main.js:1467:15)
    at .../memo-demo/node_modules/.pnpm/[email protected]/node_modules/esbuild/lib/main.js:926:25
    at .../memo-demo/node_modules/.pnpm/[email protected]/node_modules/esbuild/lib/main.js:1345:9
    at process.processTicksAndRejections (node:internal/process/task_queues:105:5)

Which is weird, not sure what's really happening here. Normally both form actions and remote functions run fully server-side, while it seems like esbuild is trying to resolve an import for the browser? I have no clue tbh.

Note that I use node-adapter, so this is not like #13061 which was a Cloudflare issue.

[dummdidumm]

Please open an issue with a proper reproduction

[tehnrd]

I am struggling to understand how to maintain a high-performance app, something SvelteKit excels in, when queries depend on each other.

I have an application that allows you to switch between workspaces, similar to Slack. The activeWorkspaceId is stored on the server. Other queries require this small piece of data. It must be copied to the client on page load and then sent in each query, as a user could have multiple windows open, and we can't always assume the value on the server is the app they currently have open and are looking at. The main point here is that there is a piece of data that all other queries depend on.

In the +page.server.ts approach, all of these queries happen in one request, and all of the data is sent to the client in one response for rendering (bonus, this also has pre-loading on link hover! Will remote functions ever get pre-loading?) Pre-loading and one HTTP request for data have the pages loading very quickly.

With the Remote Functions, we have to first fetch the activeWorkspaceId and then pass that value to all queries. This introduces a noticeable delay and introduces a waterfall.

<script lang="ts">
	import { getWorkspaceId, getWorkspaceData } from './data.remote';

	let workspaceId = $derived(await getWorkspaceId());
  
  // this has to wait for workspaceId first, delayed loading
  let workspaceData = $derived(await(getWorkspaceData(workspaceId));
</script>

<!-- also has to wait for workspaceId -->
{await getWorkspaceData(workspaceId)}

This feels like a step backwards in app performance. Is there a better way to do this? One thought was having a single remote function called something like getAllPageData() to get everything needed in a single HTTP request on first load, but then it feels like I might as well keep using page action loaders.

This is a simple example, but you could have many different pieces of data that need to be fetched before other queries can run for page rendering such as: application settings, user info, user permissions, and more.....then the main page content can render.

I feel like I am missing something obvious, and perhaps this is a documentation issue?

[paoloricciuti]

With page load actions, you get everything you need in one request

I don't understand how this works in your setup...if the workspace I'd needs to be from the client you still need to pass it to the server in some way no? Why can't you do the same with RPC?

[tehnrd]

There was/is a bug in my app with regard to getWorkspaceId. Thank you all for your patience and feedback, it is very much appreciated. I had an app context that already had workspaceId and should have been using this, and never calling getWorkspaceId

I think my original question still stands, but it is more of an architectural guidance and/or documentation question.

If queryB() (dynamic data that will be re-queried) depends on data from queryA() (static-ish data that likely won't be re-queried), what is the recommended architecture? Waterfall them? Parallel with promise.all? Create a query that returns all data like queryAandB(). The last, being one clean call, but then no way to independently refresh only queryB data.

They all appear to have pros/cons. Is it a case-by-case decision, or is there a SvelteKit blessed approach?

[Rich-Harris]

It really is case-by-case — it depends on how frequently the two things are changing relative to each other, and so on. Most of the time I would probably opt for queryAandB()...

With page load actions, you get everything you need in one request that can be pre-loaded

...which is equivalent to how things work in load functions today, except that with load you're forced to couple everything together instead of having the flexibility

[dummdidumm]

And even if you do have a waterfall where you need to call A on the client and then B, there's no difference in how long it takes between remote functions and load functions: with load functions you would have to use a universal load function, and do two serial requests (A then B) inside.
So in the end it all depends on how you architecture/organize your concrete data requests and not about whether you use load functions or remote functions.

[tehnrd]

@dummdidumm I was referring to server-side load functions, I should have clarified. The two queries server side would be serial but very fast, versus on the client side they would be serial, but have the http latency overhead.

With link hover pre-loading, these server-side queries usually finish before the user even clicks the link or very shortly after.

[NickClark]

Is there a hook for RPC errors in the client? I need to catch any 401 error and log the user out. The handleError hook doesn't seem to do the trick... and even if it was used, throwing an error(401, ... wouldn't catch it.

[Rich-Harris]

So does the cookie include a refresh token? Because if so could you log them back in at the start of handle?

If not then for queries you really have two choices — either redirect(307, '/login') or have a <svelte:boundary> that tells the user they need to log in. For commands then it wouldn't make sense to have a global handler, as you need to catch it either way

[jjones315]

so if a command 401s it just has to be manually handled at every call site? That seems less than ideal.

previously using orpc for commands (and queries) i would catch unauthorized errors globally and do
goto(`/login?returnTo=${currentRoute}`)

It seems like this will get super unwieldy on a large app, especially coordinating across a team ensuring unauthorized errors are handled everywhere.

[Rich-Harris]

I mean... how would this work, concretely? Consider a case like this:

try {
  const result = await my_command();
  console.log(`command ran successfully: ${result.message}`);
} catch (e) {
  // TODO
}

If the implementation of my_command throws an error, it gets sent to the client and rethrown, so you end up in the catch block. Clearly it can't not throw, because then you'd run the console.log below it, which would fail because result would be undefined (and your types would be wrong, of course).

So we need to turn the error(401, ...) into a redirect(307, '/login'). If we had a hook for you to do that...

export function handleCommandError({ error }) {
  if (error.status === 401) {
    redirect(307, '/login');
  }

  // presumably if we get to the end of the function we just rethrow the error?
}

...then my_command is still going to throw, just with a redirect instead of the 401. But you need to handle errors that aren't redirects! So every callsite is going to need something like this:

try {
  const result = await my_command();
  console.log(`command ran successfully: ${result.message}`);
} catch (error) {
  if (isRedirect(error)) {
    // now what?
  } else {
    showErrorUI(error);
  }
}

In the 'now what?' section: do I now need to call goto? Or do I just have to... not do anything? It feels weird that, having 'caught' the redirect, I then don't have a choice as to what happens with it. But it also feels weird to let people opt out of redirects.

(If the redirect isn't caught, then it bubbles up to window.onerror, which will likely have unintended consequences like triggering Sentry logs and whatnot.)

Either way: you haven't actually saved yourself any work. It's no more code to just do this:

try {
  const result = await my_command();
  console.log(`command ran successfully: ${result.message}`);
} catch (error) {
  if (isHttpError(error, 401)) {
    goto('/login');
  } else {
    showErrorUI(error);
  }
}

And of course you can use function composition so that you don't need to have that logic everywhere, if you prefer.

So I'm just not sure how you'd design suck a hook in a way that was actually helpful. Open to ideas though.

[NickClark]

So does the cookie include a refresh token? Because if so could you log them back in at the start of handle?

If not then for queries you really have two choices — either redirect(307, '/login') or have a <svelte:boundary> that tells the user they need to log in. For commands then it wouldn't make sense to have a global handler, as you need to catch it either way

I'm using Better Auth, I think I can renew by just fetching the session more often... I'll check.

Using redirect is something I hadn't thought of... that may work for me.

I can't use <svelte:boundary> consistently due to #14113 , but even if I did, I'd have to repeate the logic every time I made a boundary right?

Anyways, I think I have a direction now. I just kind of wish there was a hook that would allow us to monitor general network status/health. But I see that I may be able to address this problem in other, more indirect ways.

[jjones315]

ultimately what i would want here is client middleware.

export const handleCommand: HandleCommand = async ({ event, resolve }) => {
    ///... pre request logic if needed

    try {
      return resolve(event);
    } catch (error) {
      if (isAuthError(error)){
        await goto('/login');
         
        // for my app i'm fine with this throwing since on a auth error i am navigating away and for unknown error i can handle it later.
        throw error;
        
        // but you could just as easily return a result type here if needed.
        return { ok: false, message: "Unauthorized" }

      }

      if (isRedirect(error)){
         await goto(error.location);
      }
      
      throw error;
    }
};

or just allow these to be caught in handleError hook in hooks.client.ts.

Right now <svelte:boundary> doesnt catch these errors, it sounds like that may be unintentional based on your previous comments, but even if they did having to duplicate this at every boundary still seems less than ideal.

And of course you can use function composition so that you don't need to have that logic everywhere, if you prefer.

this is what i have now

export function handleCommand<TInput, TOutput>(command: RemoteCommand<TInput, TOutput>) {
  return async (input: TInput): Promise<Awaited<TOutput>> => {
    try {
      const result = await command(input);
      return result;
    } catch (error) {
      if (isHttpError(error) && error.status === 401) {
        await unauthorizedClientError();
      }
      throw error;
    }
  };
}

my complaint about this is the developer still have to remember to use this everywhere, and if they it fails in a way that is almost uncatchable during testing.

doing myCommand({ input }) and handleCommand(myCommand)({ input }) behave the exact same unless the user is logged out, so unless you happen so comeback to an active window between the recheck interval and test you arent going to catch this, and you are relying on code review.

you'll also notice if my handleCommand function was global its impact would be the exact same, but i wouldn't have to declare it everywhere.

[0xMurage]

I have a simple form remote function that returns error(404, "some errors here").

Then I progressively enhanced my object on the .svelte side.

However, when I check the returned http error, the status has changed to 500.

Is this expected behavior?

async function enhancer({ form, submit }: EnhanceCallbackOptions) {
    try {
      await submit();
      form.reset();
    } catch (err) {
 console.log( 'is 400 http error:',isHttpError(err, 400) , 'original error:',err); //the error status is 500 and not 400
    }
  }

I can see that the XHR response includes the correct status (404).

[0xMurage]

I have created a demo to reproduce this issue

https://stackblitz.com/edit/sveltejs-kit-template-default-veewterb?file=src%2Froutes%2F%2Bpage.svelte

[Torres1080]

It would be really nice to have the ability to retrieve the Schema passed to the remote function. Validators are extremely useful in client-side code, and exporting them from a separate file rather than directly from where they are used (the remote file) is not very convenient.

[Sendouc]

Agree this would be quite useful. I don't believe the example above works since all exports from .remote file need to be remote functions. Or at least I could not get it to work :)

[0xMurage]

@Sendouc I see now, since all exports from remote.{js,ts} file must be remote functions above example won't work.

[jycouet]

Your listPost.schema can be linked with postSchema something. If every remote things re-export schemas I would say that it could become noisy as well.

You can have your defined schemas in a shared place and reuse everywhere 👍

[Torres1080]

My point is that exporting them from a separate file is quite annoying when you try to place all the form related code close to the remote function. There's also some cases where the schema is pretty small and create a file only for it seems wasteful.

[Rich-Harris]

It's not possible. The client doesn't import the remote functions, it imports a transformed module full of fetch wrappers. The actual code isn't running in the client - which is the whole point of remote functions - and so there's no way for the client to access the schema. Importing it from a shared location is the only way

[ivands]

For the cache feature.
It would be nice if it had cache-and-network support built in.
Example

<script>
  import { myQuery } from './my-query.remote'
  const query = await myQuery(..., { policy: "cache-and-network" })
</script>
<p>{query.loading}</p>
<p>{query.error}</p>
<p>{query.data}</p>

The main idea is that the data is coming from a client-side cache when available.
But we still do a fetch call in the background to repopulate the cache & the reactive data property.
This way, the component will feel instant while showing the latest data when available.

[aster-void]

that's called Stale-While-Revalidate :)

[ivands]

@aster-void The stale-while-revalidate part inside the cache-control header will not update your reactive state when fetching the latest data from the server. In my example, you can show cached data that actually changes as soon as the new data comes in. The cache-control header sadly can't give you this ability.

[JonathonRP]

I really like the idea of form returning a form prop that is a svelte component.
The spreading is fine and great for experimenting, but would love if login.form was just a svelte component would improve dx I think.