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* 👀

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

[garth]

FWIW my use case for steaming is primarily Yjs updates. Since SSE is limited to text (due to the text/event-stream mime type), binary data would probably require base64ing which would be an unacceptable overhead. Ideally we would need a transport that can efficiently handle binary (eg Uint8Array).

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

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

[kirso]

Yep, would be great to have this in the documentation for best practices!

[Rich-Harris]

Once async SSR lands, and we take off the 'experimental' label, the recommendation will be to use remote functions exclusively, though load will continue to be supported for a long time.

[andreasbhansen]

Attempted to search for it, but is there a separate issue/discussion/PR to follow along for async SSR?

[Rich-Harris]

No discussion, because there's not a lot to discuss design-wise - it's just something we need to implement. @elliott-with-the-longest-name-on-github has been working on it and we'll likely get a PR soon

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

[danboyle8637]

There's a lot in this thread. I want to slowly add this to a live app I have (event though it's in experimental)... or at least add it to a dev version of my app.

Is the ultimate goal to get rid of the load functions?

Or is there guidance on when a load would be more appropriate?

[Rich-Harris]

There's an open question about whether query should default to batching, i.e. simultaneous queries result in a single HTTP request that streams responses as they become available. There are a few reasons not to do this...

• given HTTP/2, having a bunch of requests doesn't actually matter that much
• you can't use HTTP caching
• it adds implementation complexity

...but it's an option we're keeping open. Note that query.batch largely solves the 'more database reads' thing

[cofl]

I think it's fair to say that there's really no situation where it would be preferable to use load functions.

Having a single function for "maybe get stuff and fail out or redirect on these conditions" can be convenient for mental modeling of a page's rendering, but I suppose that could be replaced with a "load" remote function if bundling like that is truly desired.

One use case that remote functions don't cleanly cover, though, is unconditional redirects on routes with no content.

// /collections/+page.js
import { redirect } from "@sveltejs/kit"
import { resolve } from "$app/paths"
export function load(){
   redirect(308, resolve("/collections/[page]", { page: "1" }))
}

This can't be turned directly into a page script, since there's no handling for redirect in those blocks -- you would have to use goto, which does not serve the same semantic purpose.

You can achieve a similar effect with

// /collections/load.remote.js
import { query } from "$app/server"
import { resolve } from "$app/paths"
import { redirect } from "@sveltejs/kit"
export const load = query(() => redirect(308, resolve("/collections/[page]", { page: "1" })))

// /collections/+page.svelte
<script>
    import { load } from "./load.remote.js"
    load()
</script>

but this does not have the same semantics -- it's a fetch call returning 200 with instructions for a client-side redirect rather than a server-or-client-side redirect returning 308.

At the same time, a +server.js also would not cover this use case exactly, since it incurs an extra server request where client-only navigation would be possible.

[jsudelko]

I use this +page.js redirect pattern A LOT. It's easy to write and understand for humans and robots.

I also use +page.js if I migrate a path and need to collect analytics. Which referrers are still pointing to this deprecated route?

Remote Functions the way I see them are good for data coming to or from the DOM. For other *things* (client and sever) that aren't meant to be displayed, load functions are preferrable.

[hugo-hsi-dev]

Totally agree, I don’t think remote functions had this kind of use case in mind.

Have you thought of doing the logic in hooks? I get how keeping the logic close to the routes can be quite ergonomic, but with sveltekit steering away from having everything dependent on routes and having load functions inevitably removed, hooks might be the better option here.

I also wanted to share this here. I understand it’s not quite the same as what you’re trying to achieve, but at least shows how sveltekit encourages users to manipulate/handle route related logic from hooks.

[jsudelko]

I'm well aware of hooks and chose to generally never use them. Interestingly, my main reason is Claude Sonnet and friends. The mere existence of a hooks.js makes them stupid. They want to put things there instead of a +server.js/+page.js or do expensive things that run for every single request (especially when there's an obviously better way). If a hooks.js is simply not there the bots behave.

As you mentioned, there's issues of ergonomics too: manual path matching vs file router; soup of unrelated logic for different paths etc.

[rubenbriones]

Hi, I've implemented a workaround to get hover preloading while keeping remote functions' reactive features:

// +page.server.ts
import { getPost } from '$lib/remote/posts.remote';

export const load = async ({ params }) => {
  const post = await getPost(params.id);
  return { post };
};

// +page.svelte
import { getPost } from '$lib/remote/posts.remote';

const postStore = $derived(getPost(page.params.id));
const post = $derived(postStore.current ?? data.post);

// Keeps working: refresh, updates.withOverride, etc.
await likePost({ postId }).updates(
  getPost(postId).withOverride((post) => ({
    ...post,
    likes: post.likes + 1
  }))
);

Is this hybrid approach the best we can do right now? Any timeline for official preloading support in remote functions?

Remote functions are fantastic otherwise!

[Rich-Harris]

this is a clever hack! I like it. Timeline-wise: we're focusing on async SSR and nailing the remote functions APIs first (need to figure out things like streaming, caching etc). But since it's a blocker for us recommending that people move from load to remote functions, it's a high priority immediately after that

[jsudelko]

Are there any good references on testing Remote Functions using Vitest?

Alternatively, do you anything interesting for unit/integration tests in your own setup?

[jycouet]

In kit repo, you can have a look at tests directly, they are here: https://github.com/sveltejs/kit/blob/main/packages/kit/test/apps/basics/test/test.js#L1603

It probably can give you some ideas.

//Happy coding

[jsudelko]

Nice! For integration testing this is close to what I'm already doing. Rendering the app in its fullness in Playwright and asserting invariants while interacting with the full app. No particular awareness of Remote Functions per se.

Before sinking too much time into it myself, I was wondering if anyone has had some mileage unit testing Remote Functions (ideally in Nodejs not Playwright) because it's a lot more light weight.

[johnathanludwig]

Unit testing doesn't seem very possible right now. There are ideas on how to enable them in the future: #14249 (comment)

[xactlyblue]

I'm running into a bit of a strange issue where remote function refreshes seem to be a bit "finicky". It seems to be working sometimes and not working others, and I'm not really quite sure why.

After some experimentation, I think I've narrowed it down the cause to these seemingly random occurrences. From what I can tell, in the local environment, commands that update queries appear to break after you make changes to your code and the site updates, with the issue only being fixed after you manually refresh. Strangely, it appears that the first time you run a remote command, it works and updates the query and DOM as you'd expect, but subsequent calls don't work until you refresh the page.

I'm hesitant to open an issue for this since I'm relatively new to web development, so it's probably just a silly oversight on my end. I'll try to make a standalone repro of the bug, but until then, I'm wondering whether anyone has had a similar issue and if they have any solutions.

[tehnrd]

Not a silly oversight! I have seen a similar behavior and have refreshed the app to resolve it.

If you don't see an existing issue submitted, go for it! But make sure to provide a small, reproducible example.

[Rich-Harris]

Seconded — there are certainly bugs that haven't been catalogued, and reproductions are always useful

[xactlyblue]

After some experimentation, I submitted an issue for it with a small reproduction.

Great work on this feature, by the way. It's been a total game changer and I look forward to seeing it become more widely adopted.

[jeffpohlmeyer]

Apologies if this is a stupid question, but does #14447 now make it where remote functions work in no-js environments?

[Rich-Harris]

yes

[Rich-Harris]

(except for command, of course)

[skaldebane]

Hi there! Just noticed that form doesn't accept a FormData in the latest version (not sure when did this change happen), but it's all great, I love the change!

However, the use site seems to be inconsistent now between form functions that take arguments (and have a validator) and the ones that don't when retrieving result at least.

For a form function with arguments and a validator, I can just do e.g. login.result to access the returned data directly, which is consistent with the old behavior.

However, for form functions that take no arguments, result is a Promise that needs to be awaited, leading to code like this:

{#if (await deleteAccount.result)?.error}
    <p class="error">{(await deleteAccount.result)?.error}</p>
{/if}

This feels like a bug to me, unless I'm missing something.

[robert-wettstaedt]

I just tried updating to the newest version but have some issues with the updated enhance function, particularly with the fact that you convert the FormData to a POJO.

That in itself would not be a problem, but I don't understand the point of it because you're not doing anything with the POJO other than passing it to the enhance callback.

kit/packages/kit/src/runtime/client/remote-functions/form.svelte.js

Line 58 in abc9887

const data = convert_formdata(form_data);

And then in the submit function after the callback is done you keep on using the FormData object.

kit/packages/kit/src/runtime/client/remote-functions/form.svelte.js

Line 96 in abc9887

submit: () => submit(form_data)

For some particular forms I need to alter the form fields before submitting, but without access to the FormData object and with my changes to the POJO being completely ignored I cannot update right now. Is that really intended or is this just incomplete?

[Rich-Harris]

Intended. If you're manipulating the form data prior to submission (as opposed to merely inspecting it) then you're not enhancing the default behaviour, you're changing it. Your app will be broken as a result, for anyone for whom the JavaScript hasn't loaded.

What are you trying to do?

[robert-wettstaedt]

@Rich-Harris Well I was looking for any File form data. I don't want to upload them to the remote functions as the files can be quite big (video files). Instead I filter them out and upload them to a separate media server.

The JavaScript problem is not really a problem for my use case as the whole app heavily requires JavaScript anyway.

[wiesson]

Is this pattern

let countryId = $derived(page.url.searchParams.get('countryId'))

let query = $derived(getUsers({ countryId }))
</script>

{#if query.loading}
  <p>Loading</p>
 {:else}
   {JSON.stringify(query.current)}
 {/if}

supposed to run on the client or SSR? I liked the experience for web-apps that we change the page right away, then have a skeleton and like 200-500ms later, the data comes in. It appears that currently this is being "SSR'd" (no loader visible). I'm not sure if it's a bug that I don't see a loader (due to recent SSR changes), or it's expected

[OTheNonE]

I’m trying to figure out how to handle data flow with remote functions when using a separate backend (e.g., FastAPI). From what I can tell, .remote functions are missing some of the capabilities that +page.ts provides with SSR, specifically; There’s no way to access fetch in a context that runs on both server and client (as +page.ts does).

My use-case

I have SvelteKit running on http://localhost:3000 and FastAPI running on http://localhost:8000. The SvelteKit is served behind https://my-app.com and FastAPI behind https://api.my-app.com.

I don’t want to recreate every API endpoint in SvelteKit. Instead, I’d like to directly consume FastAPI’s endpoints:

• On the server, requests should go to http://localhost:8000.
• On the client, requests should go to https://api.my-app.com.

Using load functions

A fetch example:

// routes/+page.ts
export const load = async ({ fetch }) => {
    // SvelteKit’s `fetch` is intercepted by `handleFetch`.
    // On the server: request is rewritten to http://localhost:8000
    // On the client: request goes to https://api.my-app.com
    const result = await fetch("https://api.my-app.com/api/contact")
    const contact = await result.json()

    return { contact }
}

The rewrite is handled in hooks.server.ts:

// hooks.server.ts
export const handleFetch = async ({ event, fetch, request }) => {

    // If i am calling my API from the server, call the API server process directly instead.
    if (request.url.startsWith("https://api.my-app.com")) {
        request = new Request(
            request.url.replace("https://api.my-app.com", 'http://localhost:8000'),
            request
        )
        // ... and do more stuff regarding cookies and more ...
    }

    return fetch(request)
}

with .remote.ts functions

With .remote functions (without load), I can’t find a way to achieve the same behavior. I can’t access SvelteKit’s getRequestEvent().fetch in a universal server/client context. As a result, I can’t transparently swap between the local backend and the public API.

So currently I see two options:

• Always call the public API (https://api.my-app.com) from the client.
• Create a new .remote function in SvelteKit (duplicating the FastAPI endpoint) and fetch data SSR through that.

What is the recommended approach here? Is there a way to use .remote functions while still leveraging the same fetch/handleFetch mechanics as +page.ts?

Or do I need to adjust my approach; is the recommended practice to essentially re-create all of my API endpoints within SvelteKit using .remote functions?

[OTheNonE]

That is true @KTibow, the utility function could look like this:

export const getApiUrl = () => browser ? "https://api.my-app.com" : "http://localhost:8000"

Although now the internal port number gets sent to the client (which probably isn't a problem). A "little" better solution would be that fetch written in client side code could be intercepted when rendered on server side, as is possible with +page.ts.

[KiraPC]

Remote function runs its logic just on server side, so you don't need to rewrite the url, you can just use localhost.

On the client side the remote function is just a fetch wrap to your SvelteKit server.

[OTheNonE]

And that client-side wrap makes a call to the belonging SvelteKit RPC endpoint, serving the same data as the public API already is serving. With that in mind, maybe i should instead ask:

In contrary to using the public endpoints of my API directly, is it recommended that i re-create the endpoints of my public API in my SvelteKit server using Remote Functions?

[KTibow]

Although now the internal port number gets sent to the client

Actually, it isn't! Google tree shaking.

[OTheNonE]

I had not thought about tree shaking, and it works when the urls are hardcoded! Although, i would not store the urls in code, but instead in environment variables:

PUBLIC_API_URL="https://api.my-app.com" 
SERVER_API_URL="http://localhost:8000"

And when i write this code:

import { env as public_env } from "$env/dynamic/public"
import { env as server_env } from "$env/dynamic/private"
import { browser } from "$app/environment";

export const getApiUrl = () => browser 
    ? public_env.PUBLIC_API_URL
    : server_env.SERVER_API_URL

The build fails... Even if it were to work, we surely should not rely on tree-shaking to remove secrets from client code? But then again in this specific case, is it even bad to expose the port number of the server process to the client?

Either way, this discussion could be resolved if only fetch'es written in client-side code could be intercepted by handleFetch when SSR'ed. The only way to access such a fetch is through the load function export const load = async ({ fetch }) => { ... } in +page.ts, and is not accessible in the current feature set of RF.

And then again, is all of this public/internal api url handling even necessary if you are not meant to call your backend api in the way that i describe above, but you should instead just wrap calls to the api in a RF and have the RF make an additional (duplicate) endpoint only for the SvelteKit app?

[sbscan]

Is it possible to get validation error when using command? I couldn't find any doc or implement myself.
How to get validation error on this example. It only returns Bad Request to cleint, no error detail.
export const addLike = command(v.string(), async (id) => {
await db.sqlUPDATE item SET likes = likes + 1 WHERE id = ${id};
});

[dummdidumm]

Use the corresponding hook as described here: https://svelte.dev/docs/kit/remote-functions#Handling-validation-errors

Note that through this you will transform validation errors of all remote functions. If you want to instead specifically make it fail in a certain way on a per-remote-function basis, please let us know the use case so we can think about it.

[sbscan]

Yes, surely per remote function like the old API way, so I can inform the client which input is wrong. Now I have to validate the same on the client.

[OTheNonE]

When comparing load vs .remote, it seems like .remote is a replacement for +page.server.ts, while there is no replacement for +page.ts. My "not-thoroughly-thought-out" idea would be to have a .local.ts file with client side functions. These would not create new endpoints, and would be used for client side handling of data.

• import { query } from "$app/client" : Would basically act as a wrapper around fetch with SvelteKit's power, also so that you have the same interface as when using RF's query.
• import { form } from "$app/client": Used for client side handling of form submittion, especially useful for SPA's.

[KiraPC]

Why do you feel the need for such a feature? What you’re describing can already be done with plain JavaScript on the client side. What extra value would this bring on top of that? Am I missing something here?

[KTibow]

I think "resources" will be the solution to this

[OTheNonE]

Aah yes, resources has been mentioned in the Svelte Async SSR discussion.

I just thought it would be convenient to have the same interface for fetching data on the client-side as on the server, although you're right, it's probably easy to implement yourself, and wrappers already exists for this. The only thing missing is for fetch to be captured by handleFetch when SSR'ed.

[davidbaranek]

I think there could be a use for that. For example, I’m using SvelteKit with an external API server, but I also use SvelteKit load functions for SSR. Right now, I’m using universal +page.ts load functions because there’s nothing secret in them. I like that the data is loaded server side during SSR and then client side when refetching, avoiding an extra step when reaching to my API.

If I understand correctly, remote functions will eventually replace load functions, which means that for SSR to work, I’ll have to use them. However, that would make every request go through the SvelteKit server instead of directly from the client to my API server.

It would be convenient to have “universal” remote functions that run on the server during SSR and on the client for refetching, etc.
Sorry if I’m misunderstanding something, I’m still a bit confused about how remote functions work.

[lettucebowler]

Is there a way either current or planned to cache queries that take no arguments? The documentation says that queries are cached based on their arguments. I have a query that takes no arguments and am seeing it make a second fetch call during hydration. My current workaround is to make the query accept an unused argument of v.object({}), and then call the query with that empty object everywhere.

export const getRankings = query(v.object({}), async () => rankings);

<script lang="ts">
  let rankings = await getRankings({});
</script>

[hugo-hsi-dev]

Is it not currently cached as it should? If not, I’d guess it’s a bug.

[Rich-Harris]

yes, please file an issue

[dummdidumm]

fixed by #14563