Server Functions & Isomorphic Fetching

VitNode keeps backend business logic in Hono API routes. The frontend's only job is to call them - and for that, one universal fetcher covers SSR and browser navigation at once.

Decision Matrix

Fetching does not need createIsomorphicFn

TanStack Router loaders run on the server for the first paint and in the browser for every navigation after it. That used to mean writing both halves by hand:

export const fetchDevices = createIsomorphicFn()
  .server(fetchDevicesOnServer)
  .client(fetchDevicesInBrowser)

The universal fetcher already is that boundary, so a feature writes the fetch once - naming the plugin, and letting the route infer:

import { fetcher } from '@vitnode/core/tanstack/fetcher'

export const fetchDevices = async () => {
  const response = await fetcher({
    plugin: '@vitnode/core',
    method: 'get',
    module: 'users',
    path: '/devices',
  })

  return await response.json()
}

import { definePluginRoute } from '@vitnode/core/routing'

export const route = definePluginRoute({
  load: async () => await fetchDevices(), 
})

The initial render forwards the visitor's cookie, user-agent and IP through the request-aware transport; later navigations are a direct same-origin fetch to Hono. See Fetcher for the full contract.

createIsomorphicFn is still the right tool when the two implementations genuinely differ - reading a cookie from the request on the server and from document.cookie in the browser, for instance. It is no longer how you fetch.

When to use createServerFn (host app only)

Use createServerFn when your host application has to touch the response itself - which in practice means cookies:

import { createServerFn } from '@tanstack/react-start'
import { fetcher } from '@vitnode/core/tanstack/fetcher/server'

export const signIn = createServerFn({ method: 'POST' })
  .validator((body: { email: string; password: string }) => body)
  .handler(async ({ data }) => {
    const response = await fetcher({
      plugin: '@vitnode/core',
      allowSaveCookies: true,
      args: { body: data },
      method: 'post',
      module: 'users',
      path: '/sign_in',
    })

    return { ok: response.ok }
  })

The call is the same shape as the universal one - plugin, module, path, method, args - and it is typed from the same registry. What the server fetcher adds is exactly what a browser cannot do:

Two things make this the exception rather than the rule:

• it needs allowSaveCookies, which only the server fetcher offers;
• it costs an extra hop - browser → server function → API. Reads should not pay it, which is exactly why they use the universal fetcher instead.

Keep code that imports @vitnode/core/tanstack/fetcher/server in a *.server.ts file or inside a server function handler. The universal fetcher rejects these three options at compile time, so a call that needs one cannot end up in a shared module by accident.

Learn More