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.

[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.

[tehnrd]

I have a question about security authorization with remote functions.

For the sake of this discussion, assume a route structure as follows:

src
|--routes
   |--[orgId]
      |--home
         |--+page.svelte
         |--+page.server.ts

The orgId slug is dynamic and represents a unique org ID. If a user attempts to access the following URL we need to make sure they have permission to access it:

https://app.mysite.com/33efqef/home

Load Functions and Form Actions

Currently, we can use hook.server.ts to look at the orgId param value for all requests with page load and form actions. In hooks.server.ts, we can check if the user has access to the org and grant or deny.

import { Security } from '$lib/security';

export const handle: Handle = async ({ event, resolve }) => {
	Security.checkUserAuth(event); // event inlcudes params.orgId slug

	const response = await resolve(event);
	return response;
};

I love this as it creates one centralized place to implement access controls.

With this approach, we can continue to create many more pages and form actions without having to think about security, as it is built into every request with hook.server.ts.

Remote Functions

With remote functions, the hooks.server.ts function is run but it does not contain param/slug values, which make sense, but auth can no longer be done here. Now every single remote function will be responsible for implementing security:

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

const GetDataRequestSchema = z.object({
	orgId: z.string(),
	otherParams: z.string()
});

export const getData = query(GetDataRequestSchema, async (args) => {
	Security.checkUserAuth(args.orgId);

	// ... get the data

	return data;
});

I'm not saying this is bad, but is there a better way? It is far too easy for a developer to forget to add this to every function, whereas with the hooks.server.ts approach, it "just worked" without additional cognitive load.

If there is no better way to centralize auth, I'm thinking I will need to create a custom ESLint rule to ensure all remote functions have Security.checkAuth in them. Maybe this could be built into svelte.config.js and checked during the build process.

[Rich-Harris]

Security cannot rely on a developer remembering to do something.

I do agree with this part! It sounds like bypassing the ORM wrapper would require eslint-disable-next-line which feels like a decent safeguard — you can't accidentally or forgetfully bypass the ORM wrapper, only with intent.

Just for completeness, let's imagine the auditor is grilling you about the version of this where remote functions are aware of the current route parameters:

Auditor: Could you tell us how you prevent customers in one organization from seeing data in another organization?

Me: The queries are made from functions that live inside an [orgId] directory. Because of the nature of the framework, this means we can add a centralized check that the current user has access to the current org.

Auditor: What if a developer refactored the code to deduplicate stuff, and in the process moved it, for example to src/lib?

Me: Hopefully, this is caught in our code review process.

Auditor: Hopefully? (auditor looks down to write something)

Making the argument available on RequestEvent is an interesting idea. It would guard against changes to how the payload is encoded from wrecking your app.

[tehnrd]

I liked the convo with the auditor 😅

Joke a side, from the outside, I feel that all this looks fragile ! Ok, you are trying to make sure orgId is passed... But it can be passed and not used in all what you described. It feels odd, maybe I didn't grasp everything. To me, remote functions can know who is connected, so your backend code should limit data to this user (it's not really a remote concern).

Lol...others out there that know these auditor conversations are all too real! 😅

I think of it as two different issues. Step 1: Make sure orgId is always passed. Step 2: Ensure it is actually used. We can't even start to make Step 2 less fragile if we can't enforce its requirement. Definitely open to ideas to make this more robust!

@Rich-Harris, alternative conversation is totally valid! Passing the arguments/payload to RequestEvent would provide a mechanism to do enforcement for a variety of use cases in addition to your observation about encoding wrecking the app. You could even move the function anywhere with a refactor, but the "signature/params" of the request remains consistent on the RequestEvent regardless of the location of the source file in the project directory.

Below is just a proposal of an idea I have been tossing around, which is pretty much simply adding a new property on RequestEvent called remoteFunctionArgs with the decoded payload.

Let's say I want to implement some coding standardization around how remote functions should be called. Maybe it has a schema like the following:

{
  orgId: "abc"
  applicationId: "134",
  someClientSettingWeWantToTrack: true,
  someOtherSystemOrAppProperty: 33244,
  metadata:{
    "optionalProperyy1":"hello",
    "optionalProperty2":"world"
  },
  remoteArgs: {
    "remoteArg1": "adfa",
    "remoteArg2": "afaf"
  }
}

Having this on RequestEvent would be super useful. hooks.server.ts could use a validation library to ensure all requests conform to the company coding structure. It could ensure the required properties are always sent to the app.

It would also be very helpful for analytics and logging, as we could enforce a standard structure for reporting, analytics, and monitoring. With URL-based pages, we have the URL to log, which essentially includes all the arguments to the Application Performance Monitoring platforms. We lose this with Remote Functions. Remote function args are the equivalent of a traditional URL like /app/page/[orgId]/detail/[id]?queryparam=3 so it would make sense to include them.

Happy to spin up a dedicated Issue if you think this is worthy of a more focused discussion.

[jycouet]

Lol...others out there that know these auditor conversations are all too real! 😅

It reminded me of a time few years back! :)

I think of it as two different issues. Step 1: Make sure orgId is always passed. Step 2: Ensure it is actually used. We can't even start to make Step 2 less fragile if we can't enforce its requirement. Definitely open to ideas to make this more robust!

To me, the 2 steps are fragile. And you are adding extra things on top (more code, more tooling) to go around. And more and more, is more complexity, more bugs, more...

Imagine A, if your ORM would have the possibility to enforce the need of orgId.
-> Your step 2 is enforced, because dev, need to pass this arg to ORM
-> Your step 1 is enforced, because dev, need to pass this arg to backend

Imagine B, if your ORM, when knowing your user CAN'T access forbidden data. You can't forget a where in step 2 because it's not needed at dev level, it's enforce in backend definition. So also not needed in step 1.
If a user is part of 2 orgs, you can have a fallback enforced by the "rule", and have options to change org with an arg... Here dev can do mistakes, can forget things... But no data will be leaked! It's always data that the user has access to.
Traditional ORMs doesn't have this layer (half normal to me), Framework also doesn't have this layer (fully normal to me), it's usually "Business Logic" that needs to be "well done" at app level. To me, remult shine at this "App Business Logic" level as it's an ORM++.

[tehnrd]

@jycouet I'm thinking about it from the perspective of transitioning from URL-based load resources to Remote Functions and having data parity. With URLs and load functions, the "signature" of the request is the URL (and body on non-GET); with Remote Functions, it is the arguments.

Let's throw the security conversation out the window for now.

If you have a route like: https://myapp.com/app/[orgId]/[appId]/account/[recordId]/[relaltedTable]?orderBy=Name this might look like: https://myapp.com/app/Oasf33r23/A3r3fsdfsd/account/Rer3qafsrfes/contacts?orderBy=Name

With every single request to this URL, you are always going to receive the following properties: orgId, appId, recordId, relatedTable, and orderBy. Up to the dev to decide how to use these for retrieval, access control, monitoring, analytics, and more.

Now let's say a dev creates a new route at https://myapp.com/app/[orgId]/[appId]/mycustompage/somethingelse. The app server will always receive the orgId and appId, and the dev didn't even need to think about it; it's just something you get for free with URLs and the file-based routing.

Now I want to convert the first example to Remote Functions. I still want to retrieve all of these data points for logging and analytics purposes, and nothing to do with security. I'd like the server to reject the request if they are not provided, in hooks.server.ts.

The dev could easily migrate this URL to two new query() remote actions and fire over these payloads:
getAccount()

{
  recordId: "Rer3qafsrfes",
}

getRelated():

{
  parentId: "Rer3qafsrfes",
  related: "contacts",
  orderBy: "name"
}

I love how easy Remote Functions make it to separate this logic cleanly and load in parallel. However, I still would like the server to reject requests that do not include other required "global" properties like orgId, and ideally, I don't have to enforce this at every single remote function; hooks.server.ts could handle it.

Ignore the security perspective; there are many other valid reasons you may want to require specific properties for all requests.

The more I think about it, the more I really like adding the Remote Function arguments to RequestEvent. This would help a ton with logging, monitoring, transaction tracing, performance debugging, and more.

[jycouet]

Yes, I see your point.
Maybe a good fit for you would be a small vite plugin adding a wrapper function to query automatically?
Or just checking that you have a function destructuring params as first line ?

export const getData = query(xyz, async (args) => {
	const { orgId } = mustArgs(args)
	
	return data;
});

[KTibow]

Anyone else excited for the upcoming speed improvements? With async SSR, forking, and resources, I'd expect a small speedup for the initial load but a large speedup for page to page navigation (preloading & connecting directly to the database goes a long way).

[calasanmarko]

What happens if I want to submit a remote form without refreshing any remote queries?

Currently if I call submit inside a remote form's enhance handler, and I don't pass any args to updates, every single remote query is refreshed.

A more concrete use-case is a chat app. I have a remote query that fetches the last N messages in a conversation, and a remote form that sends a message (and returns the whole message object). I'd like to just append this message to my local message state, not trigger a refresh of my getMessages query which will get all the messages in the conversation.

Furthermore, is there any built-in way to change the local state of a remote query independently of any form submissions? Let's say I have a setup like this:

<script lang="ts">
    import { remoteGetChatMessages } from "$lib/remotes/chat.remote";

    const messages = remoteGetChatMessages({ chatId: "XXX" });
</script>

{#if messages.loading}
    <p>Loading...</p>
{:else if messages.error}
    <p>Error: {messages.error.message}</p>
{:else}
    <div>
        {#each messages.current ?? [] as message}
            <div>{message.content}</div>
        {/each}
    </div>
{/if}

How am I meant to add new messages as they arrive from an e.g. WS/SSE stream?

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

Furthermore, is there any built-in way to change the local state of a remote query independently of any form submissions?

queries have a .set method!

[calasanmarko]

Thanks, that appears to work, although as far as I can tell there are no types for it. How about the refresh bit? There needs to be a way to submit a form without triggering query re-reruns.

[Nickersoft]

Love this and super excited for it to stabilize!! Important question I can't help but have though – what does this mean for +page/+layout.ts functions, and when do you know when to use a remote function over a .ts file? Similar to the question that was raised when state was introduced on top of stores, I could see it becoming quite confusing and ambiguous as to what the recommended approach for loading data will be going forward. Would be great if everything could just rely solely on remote functions instead of having to use both approaches. Feels more intuitive.

[tehnrd]

I saw the PR about query.batch and I have some questions/thoughts. I was surprised to see this as a new property of query() and not handled automatically by query(). Maybe with an espace hatch like the following to disable batching, query(schema,(args)=>{},{batch:false}); or inverse like query.noBatch(), or controlled from the await call in the component (example at bottom).

It appears to be trying to solve the n+1 problem in the client to reduce the number of HTTP requests to the server, and at the same time, on the server, reduce the n+1 problem by trying to reduce the number of database calls. It may not be possible to solve both of these at the same time, and it may require the discretion of the developer to determine implementation specifics.

Individual calls to the same query.batch function are put into an array, and the remote function is invoked with the collected calls that happened within one macrotask. You must return an array of the same length, with each output entry being at the same array position as its corresponding input. SvelteKit will then split this array back up and resolve the individual calls with their results.

In the PR docs there is the following example:

<script>
	import { getPost } from './batch.remote.js';

	let { posts } = $props();
</script>

<h1>All my posts</h1>

<ul>
	{#each posts as post}
		<li>{await getPost(post.id).summary}</li>
	{/each}
</ul>

Combining these on the client side is great, one HTTP request.

Combining these on the server and invoking the Remote Function once will be problematic. For the example above, you could easily split this into an array for the proper response structure:

export const getPost = query.batch(v.string(), async (postIds: string[]) => {
	const posts = await db.sql`
		SELECT id, * FROM post
		WHERE slug = ANY(${postIds})
	`;

  // Create a map for quick lookup
  const postMap = new Map(posts.map(post => [post.id, post]));

	// Return posts in the same order as postIds
  return postIds.map(id => postMap.get(id));
});

Formatting the response data to make sure it aligns with the args array is doable in this simple example. This single method invocation approach breaks down quickly and does not work with more complex queries.

Here is an example to show how this will not work for even marginally complex queries:

Table Name: Account

Name	Country	Revenue	Number of Employees
TechCorp Solutions	US	15200000	150
Smart Innovations	US	8750000	85
Aussie Digital Partners	AU	22100000	320

.svelte file:

{await getAccounts({country: us, minRev: 400000})
{await getAccounts({country: au, minRev: 12000000})

.remotes.ts:

const accountFilterSchema = z.object({
	country: z.string(),
	minRev: z.number()
});

export const getAccounts = query.batch(accountFilterSchema, async (requests: z.infer<typeof accountFilterSchema>[]) => {
	const posts = await db.sql`
		SELECT * FROM account
		WHERE (reqest1sql) OR (reqest2sql) OR (reqest3sql)
	`;

	// Uhh....this will return every row in the table, there is no way to know
	// what rows returned in the query align to the requests.
});

The answer could be, just do a database query for each request in the array in the remote function....and exactly! This could be the default? For every request that is batched on the client, it should call the Remote Function once (in parallel) and automatically construct the response to the client in the correct order. query() could automatically handle this. The dev wouldn't need to think about using query() or query.batch()

The answer could also be: just use query...but then would I lose the client-side batching of combining calls into one http request? And I'm back to an app with a bunch of ajax spinners and SPA flashes as data loads on the client at different times?

"But this will then cause the n+1 problem on the server" Yup, it will and there isn't a great way to solve this. With that said, select queries in a for loop, whether in a svelte file or on the server are an anti-pattern. If you are seeing this happen, the svelte component and code should probably be refactored in a way that can request all the data at once or paging with single queries as necessary.

Fwiw, batch on the client, but not on the server, and instead invoke functions one at a time with arguments in parallel is the way Salesforce built their Remote Actions and they have been used at massive scale for the last 13 years.

Could also control batching client side if you don't want a load of a particular query slowed down server side and want it to execute on its own as fast as possible:

{await getAccounts({country: us, minRev: 400000},{batch:false})
{await getAccounts({country: au, minRev: 12000000})
{await getAccounts({country: au, minRev: 0})

[tehnrd]

In this example from the PR docs:

{#each cities.slice(0, limit) as city}
	<h3>{city.name}</h3>
	<CityWeather weather={await getWeather(city.id)} />
{/each}

I'm not super familiar with the inner workings of Svelte rendering, but if the limit is increased from 3 to 5, it would not re-render the first 3 items, and it would only call the query.batch() for the incremental items, items 4 and 5?

[Rich-Harris]

yes

[hugo-hsi-dev]

I’ve read through the new documentation and looked through this discussion for more information on batching but still don’t fully understand how using this could be better than getting the full set of data in an array and mapping over it on the client.

The part that confuses me is that you would need an array of ids or something of that sorts to use batch anyways. To my understanding, that would mean one query to get a list of ids and then batch querying the rest of the data for each id in the list.

Maybe I just need a concrete practical example to wrap my head around it. When would you use regular query vs query.batch?

[Rich-Harris]

#14272 (comment)

[hugo-hsi-dev]

Got it. Thank you!

[huseeiin]

for SEO purposes we need a way to tell sveltekit to wait for a single resource before flushing the stream or have a "async" mode which will enable that for all remote functions (disables streaming). even better we should have a way to set the mode to "stream" or "async" based on whether the user-agent is a bot, solid start allows this:

// @refresh reload
import { createHandler, StartServer } from "@solidjs/start/server";
import { isbot } from "isbot";

export default createHandler(
  () => (
    <StartServer
      document={({ assets, children, scripts }) => (
        <html lang="en">{/* html... */}</html>
      )}
    />
  ),
  (e) => ({
    mode: isbot(e.request.headers.get("user-agent")) ? "async" : "stream",
  })
);

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

This is just async SSR, which we're currently working on. Right?

[huseeiin]

This is just async SSR, which we're currently working on. Right?

async means non-streaming. its not good except for SEO. currently sveltekit remote functions can only be streamed, so no "async" mode. if that's what's you're working on, that's awesome

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

I'm not sure I follow. "async" and "streaming" are two completely different things. Async SSR will have both a blocking implementation (where promises must fully resolve on the server, which outputs fully-rendered content, which is sent to the client) and a nonblocking implementation where pending content like a loading spinner or skeleton can be sent to the client while the work continues on the server and is then streamed to the client as it finishes. You'll be able to use both in your app.