SvelteKit Remote Functions

This blog post focuses on using form-based remote functions in SvelteKit to handle server-side filtering in a component-based architecture. It explains why this approach was chosen, how data flows between the server and components, and which pitfalls to avoid.
To keep the post concise, it does not include code examples. Instead, a GitHub repository with a fully working form-based remote function and inline comments is provided for reference.
live link

Files in the Repository
The following files and directories are needed for this project:

• Remote functions: src/lib/remote/
• Server data: src/lib/server/
• Reusable components: src/lib/components/
• Filter page - +layout.server.js: src/routes/(form-filter)/form-filter/+layout.server.ts
• Filter page - +page.svelte: src/routes/(form-filter)/form-filter/+page.svelte
• Remote functions configuration: Remote functions are enabled in svelte.config.js

You can change the directory to your preference as long as it is inside lib. I chose this structure because I plan to experiment with additional remote functions here as well

What are Remote Functions?

Remote functions are a tool for type-safe communication between client and server. They can be called anywhere in your app, but always run on the server, meaning they can safely access server-only modules containing things like environment variables and database clients.

Combined with Svelte’s experimental support for await, it allows you to load and manipulate data directly inside your components.

In practice, this means you write server logic once, and components can call that logic directly

Which Type of Remote Function Is Used (and Why)

SvelteKit remote functions come in four official flavours: query, form, command, and prerender. Each one is designed for a different kind of client–server interaction.
This blog is about using the form.

Remote Function - Form

form is the right choice when you want to submit data from an HTML <form>.

What it’s good at

• Handling <form> submissions
• Validating submitted FormData on the server
• Writing your own JavaScript logic to process the form request
• Returning results back to a component

In this project, I initially got the filtering working without remote functions. The checkboxes submitted correctly (the URL got updated with the filter request), but after applying filters I only saw the updated results after a full page reload. I’m not entirely sure why it behaved this way in my setup.

Instead of forcing a manual refresh, I followed my teachers’ advice and explored whether remote functions could solve it in a cleaner way.

That turned out to be a great fit, because the project was structured around components:

• a Filter component (where the user selects options)
• a results component (where the filtered projects are displayed)

With a remote function, I can:

• call the remote function from the Filter component to submit the form and apply the filters server-side, updating the project list on the server
• use the same remote function in the ProjectCardContainer to read the updated filtered list and render it

Because both components use the same remote function, the filtering logic stays remains on the server and does not depend on +page.svelte.
This meansthat when the remote function is called:

• the filtered data is not first returned to the Filter component and does not have to go through +page.svelte to reach the results component.
• Instead, each component communicates directly with the server through the same remote function.
• The Filter component submits the filter values, while the ProjectCardContainer independently requests the filtered project list.

What You Need to Use Remote Functions

To implement this setup, you need:

• SvelteKit with support for remote functions
  Remote functions are experimental and must be explicitly enabled in your svelte.config.js.
• data
  Data that is fetched and will later be used for filtering.
• A remote function file
  This file must follow the naming convention
  your-function.remote.ts or your-function.remote.js.
• Valibot Valibot ensures that only trusted and well-structured data reaches your server and helps protect against malicious input.
• Components that:
• submit data via a form
• showcase the returned result from the remote function

My data structure choice

I placed the data fetching logic in a shared location so it can be used by both layout.server.js and the remote function
While writing this, I realized I could also have written a separate fetch directly inside the remote function, but this makes the fetch reusable.

• In src/lib/server/projectData.js, I defined a function that fetches the full projects dataset.
• When the page loads, this function is called from layout.server.js. From there, the complete project list is passed down to the result component as initial data.
• after the page is loaded the fetch inside the layout.server.js is not called again
• In the remote function, I call the same data-fetching function again to retrieve projects.
• This fetch is executed on every filter submit so the filtering logic always works with the most up-to-date data.

What I did wrong

At the time I was working on this, there were very few practical examples available onlinefor my specific case.
There were, however, many examples of login implementations

Reading the documentation was difficult for me, and the lack of concrete examples made it hard to understand the concepts at first. I read the Svelte documentation multiple times, but I still did not fully understand how remote functions were meant to work.

These are the things I did not understand at first or did incorrectly:

• I initially tried to write remote function logic inside page.server.js and layout.server.js.
• This does not work: remote functions must be defined in a separate file named *.remote.ts.
• I tried to directly adapt the filtering code I already had into a remote function.
• I eventually had to take a step back and start from scratch in a clean project.
• After many attempts, I still could not get it working.
• I then copied the example from the Svelte documentation, and that version did work.
• I had previously removed imports I thought I did not need (such as import { form } from '$app/server';).
• While some imports were indeed unnecessary for my case, removing others caused the example to break.
• From there, I started making small changes, removing or modifying one line at a time to understand what each part did.
• I initially tried to access data fetched in +layout.server.js, but later realized that this data is sent to the client, so remote functions cannot access it
• I later realized that the HTML structure of the form must be written in a specific way for form based remote functions.
• You need to let SvelteKit generate the attributes on the <form> and <input> elements.
• I initially assumed that a standard action attribute on the form would be sufficient, but this does not work with form based remote functions. You need something like this
• Lastly, I skipped a lot of SvelteKit concepts I actually needed, such as runes. Even after my remote function worked, I still had to figure out how to display the updated results in the browser.
• For this, I needed runes ($effect, $state, and $derived) to ensure the results reactively update whenever the remote function is called.

Final Notes

While the learning curve was steeper than expected, once I understood the missing pieces, the purpose of remote functions became much clearer. At first, I did not see how they were helpful or better than other approaches.

That changed after discussing it with a teacher, who pointed out that remote functions can be called directly from components, allowing those components to work independently from each other.

In my first working version, I called the remote function from the Filter component and then passed the filtered list through +page.svelte to the results component. Using a shared remote function instead removed that dependency and resulted in a cleaner, more component-focused architecture.