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

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

Possibly also convex 😉

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.

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

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

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

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

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.

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.

@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?

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

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

Any updates =)

#13957

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.

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.

Svelte components must be capitalized

nope, they must be capitalized or use dot notation

with <svelte:boundary> sveltejs/svelte#15845

Why?

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.

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

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

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

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

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

Both of these problems are better solved with normal functions

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

I have the exact same question, it currently SSRs unless you wrap the component/page where you are doing this with a boundary, which is not what I personally expected

But wrapping on boundary, makes the whole script run only on client (If I put a console log in the script, it only shows on browser console.log, without boundary it appears on vscode and browser)

I think this is not going to be the final design, and when Async SSR comes this will change

If someone from the team could confirm this, would be nice :)

EDIT:

Reading upon other comments in this thread, yes, it will be implemented in the future when Async SSR comes
You can do something like:

#13897 (comment)

For now

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.

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.

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?

Although now the internal port number gets sent to the client

Actually, it isn't! Google tree shaking.

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?

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.

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.

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?

I think "resources" will be the solution to this

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.

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.

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

yes, please file an issue

fixed by #14563

I had hoped this would work:

await getPosts().set([createResult.post!, ...getPosts().current ?? []]);

But it seems not.