Remote Functions: deterministic paths

[theetrain]

Describe the problem

Sometimes I want to write some internal-use APIs without building a full REST architecture. That way, I can send some cross-origin requests between the applications I own.

The use case that came up is managing logout logic between two applications:

On app.example.com there is a logout form:

<form method="POST" action="accounts.example.com/?/logout">
  <button>Log out</button>
</form>

And on accounts.example.com I can write a traditional SvelteKit Form Action to receive the cross-origin POST request in src/routes/+page.server.ts.

If a remote form named logout exists on accounts.example.com, it's not possible to rely on their path since it may change in between builds. Example generated path: ?/remote=q5s0im%2Flogout.

Describe the proposed solution

Some way to provide deterministic paths for remote form methods ahead of build time; especially if current workarounds may not be made available long-term.

Brainstorming some ways this can be exposed to SvelteKit developers:

1. Remote functions defined anywhere in src/routes/**/*.remote.{ts|js} would generate a path the same way named Form Actions do today; and if there's a conflict with a same-named form action then there would be a build error.
   Example:

   // file: src/routes/auth.remote.ts
   
   import { form } from '$app/server'
   
   // exposed as `accounts.example.com/?/logout`
   export const logout = form(() => { /* do stuff */ }

2. A third options parameter is provided for remote functions to set things like { url: '/api/logout' }
3. A config option to make paths determined based on location in the project's file structure and method name, rather than a (seemingly) random hash being generated.
   Example: src/lib/auth.remote.ts#logout -> /_remote/lib/logout
4. (cool, but understandably complex) A generated SDK for all remote functions in a given application. There may need to be considerations for 'private' functions (see Guarded / private prerender remote functions #15712)

It would be nice to have deterministic paths for query or command as well.

I understand the intent of Remote Functions and RPC in general is to not care too much about endpoint paths and to instead generate an SDK; which in SvelteKit's case is a build-time detail. At least, we could provide a simple escape hatch for these infrequent needs like a single method.

Alternatives considered

• A named Form Action
• A +server.ts POST endpoint

Importance

would make my life easier

Additional Information

This relates to another feature request that would also require deterministic paths:

• Allow static builds to use Remote Functions #14336

Especially if the 'generated SDK' idea is pursued.

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

I know the existing discussions we've had around this have basically all come down to "remote functions' transport layer is an implementation detail", so I'm not sure that any solution that says "let me control the transport layer" is going to fly -- it would make the transport layer part of the public API which means we could no longer change it in any breaking way.

[lettucebowler]

It's a little annoying but my solution to this has been to make a +server.ts file wrapping the functionality from the remote function

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

That is the currently-intended solution to this problem! We might come up with something better, though.

[Rich-Harris]

Option 1 is interesting, though I would make it src/routes/auth/+page.remote.ts. Not sure what the corresponding endpoints would be — /auth.login or something? This would be a breaking change, so if we were to consider something like this we would need to do it before version 3.

As @elliott-with-the-longest-name-on-github says though, the endpoint is only part of the problem. Remote functions can accept and return things like dates, sets, maps, objects with cyclical/repeated references, etc. I guess we would just have to throw at runtime if the function returned things that couldn't reliably be serialized as JSON.

In the meantime +server.ts is the way to go:

import { getThing } from './stuff.remote.ts';

export function GET({ url }) {
  const arg = JSON.parse(url.searchParams.get('arg'));
  return Response.json(await getThing(arg));
}

It would be trivial to make a helper for this:

export const GET = expose(getThing);

[Rich-Harris]

Or maybe +server.remote.ts would make more sense than +page.remote.ts. Either way, making it clear that this is a route file

[Rich-Harris]

One caveat: we massage FormData quite a bit to get things like nested objects and arrays, boolean/number conversion etc. Really not sure we want to be exposing those guts to the world. So it's possible this would need to be restricted to queries and commands

[theetrain]

I just remembered remote functions encode results with devalue. That shouldn't have a huge impact though; in cases where a.example.com were to make a form submission to b.example.com, then a.example.com would not need to decode results since it will handle the request and either render a page or redirect back. My main use case is cross-site requests, so having form and the others somehow maintain a deterministic path in between builds may still be useful even if a form response cannot be made useful at this time (I say not-very-confidently).

Keeping in mind #14336 since native applications would need backwards-compatible API changes until all clients have fully upgraded. I'm not sure if Remote Functions could fully replace a versioned REST API. Imagining that it can, then there may need to be some kind of file structure-informed (or config-informed) manner for the generated Remote Function endpoints to remain the same in between builds.

[dummdidumm]

I think there's two variants to this:

1. your backend is elsewhere than your client but they go as one / deploy together -> you want some kind of trusted origins config to not reject these requests to your backend
2. you want to make a remote function accessible as some kind of public API

I think what you have here is variant 1. As long as your remote file doesn't change its location/filename the path is stable. So you want to configure trusted origins.

For variant 2, I don't think that anyone wants to concern themselves with devalue, and providing this somewhat esotheric format. They likely want to get JSON in/out. For this I think a SvelteKit-provided wrapper function that turns a remote function into a public endpoint which you can expose through +server.js is better.

[theetrain]

For variant 2, I don't think that anyone wants to concern themselves with devalue, and providing this somewhat esotheric format. They likely want to get JSON in/out.

I agree.

For this I think a SvelteKit-provided wrapper function that turns a remote function into a public endpoint which you can expose through +server.js is better.

I think that's a sensible approach.

At this time, I don't think SvelteKit needs to implement a fully safe API since tools like https://orpc.dev/ solve that well enough; and maybe such a solution could be needed for #14336 as well. Exposing remote functions via +server.js is simple enough for simple cases.