-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Description
Describe the problem
Remote functions query
, form
, and command
are only available when shipping SvelteKit with a server, such as with serverless or Node.js adapters. Anyone shipping desktop applications cannot leverage Remote Functions today.
Describe the proposed solution
Provide an opt-in configuration that allows static builds to consume query
, form
, and command
functions client-side so long as they point to remote functions deployed elsewhere. As an idea, we could add a config option such as kit.remoteFunctions.origin
for developers to set their remote server, such as https://api.example.com
or an environment variable. Absence of this configuration should fail the build for any prerendered or static pages consuming the above remote function types.
This unlocks being able to maintain a single codebase that can use Remote Functions and conditionally deploy as a native (Capacitor, Electron, Tauri, Wails, etc) app with adapter-static
, or a website using any server-like adapter such as adapter-node
.
The challenge with ensuring compatibility between the native builds and their corresponding remote site is avoiding drift between breaking changes in remote function; it's very possible for the remote application to ship before users update their local/native apps. Some mitigation strategies could be:
- Check for
version
when remote functions return a 'not found' error and provide a signal. That way in userland we can show a notice to the end user to refresh or update their application. - Application maintainers could version their remote functions, either in the directory structure such as shipping a
v1
andv2
file to coexist until all consumers upgrade (src/lib/v1/todos.remote.ts
,src/lib/v2/todos.remote.ts
) - Function exports can be versioned in their name (
const getTodos = query(/* ... */)
,const getTodos_v2 = query(/* ... */)
).
Alternatives considered
Adopt a third-party querying library.
Importance
nice to have
Additional Information
Related comment: #13897 (reply in thread)