DEV Community: Tobias Lundin

SvelteKit RPC with Hono

Tobias Lundin — Sun, 05 Oct 2025 20:36:22 +0000

Original article published at tolu.se/blog/sveltekit-rpc-hono/

Working example codebase for article can be found here github.com/tolu/sveltekit-hono-rpc

What we're working with

SvelteKit in Brief

SvelteKit is the official full-stack framework for Svelte. It handles routing, server-side rendering, and API endpoints through a file-based convention. Think of it as Svelte's version of Next.js (React), Nuxt (Vue) or SolidStart (SolidJS).

Hono in Brief

Hono is a lightweight web framework built on Web Standards, meaning it runs anywhere: Node.js, Deno, Bun, Cloudflare Workers, you name it. It's fast, provides excellent TypeScript support, and comes with middleware for everything from CORS to JWT authentication. Think Express.js, but modern and runtime-agnostic.

What is RPC and Why Should You Care?

Remote Procedure Call (RPC) is a pattern where you call server-side functions from your client code as if they were local functions. No manual endpoint construction, no maintaining separate client/server type definitions—just function calls that happen to execute on the server.

A bit of history: RPC isn't new. We've had XML-RPC (1998), JSON-RPC, gRPC, and countless other implementations. What's changed is that modern JavaScript frameworks have rediscovered how pleasant this pattern can be when paired with TypeScript's type inference. Instead of maintaining OpenAPI specs and generating client code, your types just... work.

The problem RPC solves: In traditional REST APIs, you maintain parallel universes—server endpoints and client code that calls them—with no guaranteed synchronization. Change a route? Update the client. Modify response shape? Hope you caught all the call sites. RPC collapses this duplication: one function definition serves both client and server, with the type system ensuring they stay in sync.
Modern frameworks like tRPC, Remix actions, Next.js server functions, and SvelteKit's remote functions all embrace this pattern. The differences lie in how much control you retain over the HTTP layer underneath.

Why I'm Writing This

I've recently done some more work with SvelteKit, the first time since after runes (and more) were introduced to Svelte. Every time I return to Svelte (from React) I get blown away about how fun Svelte components are to work with; because of the component model, scoped styling and the built in transitions and animations. The library supports my goals better, letting me easily work directly with DOM APIs instead of fighting the runtime to avoid unnecessary re-renders with refs and caching.

What bothers me most about modern frameworks is their reliance on folder-structure routing and magic file names for data loading and compiler instructions (hello "use server").
While these might be great in a lot of cases I really miss the option for code-based routing.

This is especially true when it comes to API-routes, and here SvelteKit is no different.

Type-safe client data loading

Type-safety is important to me and has been since I fell in love with TypeScript before 1.0. When it comes to type-safety across network and serialization boundaries in full-stack frameworks it's even more important since validation is essential to trust the data being transmitted. For regular function-to-function calls in the client sphere this is not an issue. Server endpoints however can be reverse-engineered and called by anyone, not just your own client code.

For loading data from the client SvelteKit offers 2 solutions

API-routes
Remote Function (experimental)

API-routes

Component	Example
File:	`/src/routes/api/search/[term]/+server.ts`
Endpoint:	`/api/search/:term`

API-routes provide regular endpoints through folder hierarchy, giving you full control over request-response objects and middleware. You can use any HTTP client library—mine is ky.

The +server.ts file registers handlers by exporting HTTP-verb-named functions like GET and POST.

Example

/** File: /src/routes/api/search/[term]/+server.ts */
import { json } from '@sveltejs/kit';
import type { RequestHandler } from './$types';

export const GET: RequestHandler = async ({ request, url }) => {
  const term = url.searchParams.get('term');
  const data = await getSearchResults(term);
  return json(data, { headers: { 'Cache-Control': 'public' } });
};

/** File: page.svelte */
<script lang="ts">
  let results = $state();
  let term = $state('foo');
  onMount(() => {
    // should ofc do this when some input changes...
    fetch(`/api/search/${term}`).then(res => res.json()).then(data => {
      results = data;
    });
  })
</script>

Downsides

Request validation, sharing types with client and endpoint paths are your own problem to solve.

While folder hierarchy helps with organization, it doesn't tell the full story. Requests involve more than just paths and dynamic variables—they include headers, query parameters, and other metadata.

Folder structure sometimes scatters related concepts across multiple files that should be grouped together.

Remote Functions

Component	Example
File:	`/src/routes/api/search/data.remote.ts`
Endpoint:	`<auto-generated>`

Remote functions always run on the server but can be called from client code, using build time glue-generation and magic file-names (<name>.remote.ts). The awaited response is not a Response object but rather the data itself.

Declaring input parameters for remote functions require Standard Schema for validation purposes, which encourages developers to validate their data.

The functions can then be imported by client code and called as regular functions. Easy peasy.

Example

/** file: src/routes/search/data.remote.ts */
import { query } from '$app/server';
import { fetchSearchResults } from '$lib/api/search';
import * as v from 'valibot';

export const getSearchResults = query(v.string(), async (term) => {
    return await fetchSearchResults(term);
});

/** file: src/routes/search/+page.svelte */
<script lang="ts">
    import { getSearchResults } from './data.remote';
  let results = $state();
  let term = $state('foo');
  onMount(() => {
    // should ofc be called when some input value change in real life
    getSearchResults(term).then(data => {
      results = data;
    })
  })
</script>

Downsides

No control over the response headers, so impossible (or hard) to set Cache-Control or add Server-Timing.

All dynamic behavior in the function must be encoded as validated input parameters instead of request-properties.

Take away

Neither approach gives me the full control I want over routing and request-response handling while maintaining type-safe communication. They are very nice tools to have but I'd like more control, be closer to the HTTP and maintain control over types and validation, all in one package.

Also, can I have an OpenAPI spec and Swagger UI on the side? I'm not sure how I would solve that with these primitives.

Enter 🔥 Hono RPC (docs)

First of all Hono is a fantastic web application framework built on web standards and supports any runtime. It has many built-in middlewares for caching, authentication, CORS, JWT, logging etc

Here's how we'll combine the best of both approaches and add more functionality:

replace API-routes entirely with Hono for full control of routing and gives us free reigns over code structure and folder hierarchy
use @hono/openapi and valibot for endpoint schema- and response validation and type safety
replace remote functions on the client by leveraging the Hono Client for endpoint discovery
generate a Swagger UI from the OpenAPI specification

1. Replacing API-routes with Hono

We can pass all traffic on /api/* to Hono by leveraging rest-parameters in folder names and creating an API-route file like so:

/** File: /src/routes/api/[...rest]/+server.ts */

import { honoApiApp } from '$lib/api/hono-api';
import type { RequestHandler } from './$types';

// This handler will respond to all HTTP verbs (GET, POST, PUT, PATCH, DELETE, etc.)
// Pass all requests along to the honoApiApp, that we'll create next
export const fallback: RequestHandler = ({ request }) => honoApiApp.fetch(request);

Now we need to configure and mount our Hono app on the correct path, and handle the search result query.

For fun we'll add a global middleware for logging and setting the x-served-by response header.

/** File: /src/lib/api/hono-api.ts */

import { Hono } from 'hono';

const app = new Hono()
  // Here we moved the search term from a query parameter to a path parameter
  .get(
    '/search/:term',
    (c) => {
      const term = c.req.param('term');
      const results = await internalApi.getSearchResults();
      return c.json(results, { headers: { 'Cache-Control': 'public, max-age=3600' } });
   }
  );

const honoApiApp = new Hono()
  // Add global middleware for logging
  .use(async (c, next) => {
    console.log(`(🔥) - [${c.req.method}] ${new URL(c.req.url).pathname}`);
    await next();
    c.res.headers.set('x-served-by', 'hono');
  })
  // Mount the app on the /api-route
  .route('/api', app);


export { honoApiApp };

2. Adding validation and type-safety

While you can add validators to Hono routes without OpenAPI, I chose this approach for several benefits: free Swagger UI, visual API representation, and advanced client response types that handle all defined HTTP status codes.

So let's extend our endpoint from before with validation and OpenAPI specification.

+ import { describeRoute, resolver, validator } from 'hono-openapi';
+ import * as v from 'valibot';

const app = new Hono()
  .get(
    '/search/:term',
+    describeRoute({
+      description: 'Provides search results for a given term',
+      responses: {
+        200: {
+          description: 'Search results',
+          content: { 'application/json': {
+            schema: resolver(v.any()) // add actual schema for response here
+          }}, 
+        },
+      },
+    }),
+    validator(
+      'param',
+      v.object({
+        term: v.string(),
+      }),
+    ),
    (c) => {
      const term = c.req.param('term');
      const results = await internalApi.getSearchResults();
      return c.json(results, { headers: { 'Cache-Control': 'public, max-age=3600' } });
   }
  );

/** honoApiApp is unchanged... */

+ export type HonoApiType = typeof honoApiApp;

This gives us endpoint validation and as a benefit a type we can use to create an api client for the browser. We'll get back to the OpenAPI when adding Swagger UI later.

3. Replace remote function with Hono client

First we need to create a new file for our API-client, instantiate it using our new HonoApiType and export it for use.

/** File: /src/lib/rpc-client.ts */

import { hc } from 'hono/client';
import type { HonoApiType } from '$lib/api/hono-api';
import { browser } from '$app/environment';

// Since this file might be imported by server code, on the SSR pass of a page,
// let's ensure we're in the browser before accessing "location"
export const apiClient = hc<HonoApiType>( browser ? location.origin : '' );

This typed Hono client gives us an object with full IntelliSense and type support for the endpoints paths and response types.

We can now replace our remote function in our svelte component with the apiClient like so:

/** file: src/routes/search/+page.svelte */
<script lang="ts">
-  import { getSearchResults } from './data.remote';
+  import { apiClient } from '$lib/rpc-client';
  let results = $state();
  let term = $state('foo');
  onMount(() => {
    // should ofc be called when some input value change in real life
-    apiClient(term).then(data => {
-      results = data;
-    })
+    apiClient.api.search[':term']
+     .$get({ param: { term: term } }).then(res => res.json())
+     .then(data => {
+       results = data;
+     });
  })
</script>

It's not all I want in an API-client, but at least we now have intellisense and type safety all the way down. 🙌

And we have full control over API routes, middleware and response headers.

I would love to extend this client with niceties from ky so that it has automatic retries and syntax-sugar like .json().

But that's for another time.

4. Swagger UI from the OpenAPI specification

Now that our endpoint has OpenAPI configuration, we can expose the schema and add Swagger UI for interactive API documentation.

We'll expose the schema and swagger directly on the honoApiApp like this:

/** File: /src/lib/api/hono-api.ts */

import { openAPIRouteHandler } from 'hono-openapi';
import { swaggerUI } from '@hono/swagger-ui';

// this is right below the code we've already written

const openApiPath = '/api/openapi';

honoApiApp.get(
  openApiPath,
  openAPIRouteHandler(honoApiApp, {
    documentation: {
      info: {
        title: 'My Very Own API',
        version: '1.0.0',
        description: 'API documentation for the My Own API, by way of Hono 🔥',
      },
    },
  })
);

honoApiApp.get('/api/docs', swaggerUI({ url: openApiPath }));

That's it

By adding validation and minimal documentation, we gained response schema types, a type-safe apiClient, and visual API documentation — all working together seamlessly. In many ways we gained an embedded BFF (Backend-For-Frontend) that required minimal boilerplate code and that can leverege the full power and flexibility of Hono.

The best part? In using Hono for this API (and RPC client) we are completely independent of SvelteKit. You're (more) free to rewrite the frontend with another library without porting the entire API to another framework's conventions and standards 🙌

Svelte ❤️🔥 Hono

✌️

ViteJs - replacing create-react-app in a monorepo

Tobias Lundin — Mon, 08 Mar 2021 09:20:26 +0000

Cover photo by Marc Sendra Martorell on Unsplash

Resources

https://github.com/tolu/test-vite-monorepo (example repo)
https://vitejs.dev/ (documentation)
workspaces-run to run same task in all packages from root (might not need after npm 7.7.0)

Premise

The aim is to reduce complexity (nr of deps etc) and increase inner-loop-speed in a monorepo at work using create-react-app (cra), lerna and craco by leveraging npm 7 workspaces and vite.

On weekdays I build a streaming-service webapp

Our original setup

We started out with something like this, a lerna project with 2 cra-apps (App1 & App2), a common-package for shared components/styles with Storybook setup and some general purpose tooling packages.
The (not ejected) cra-apps use craco for editing the webpack config with extended contexts (to be able to require packages from outside of root dir) and setting up require-aliases (for sass imports) etc.

apps/
├──App1/
│  App2/
│  common/
│  tooling/
├───eslint-cfg
│   prettier-cfg
package.json
readme.md

This setup works well enough but we've noticed some pain points:

it's a hassle to update react-scripts and we don't really want to eject since then we have to manage 400 lines of webpack config by ourselves 😅
cra requires configuration to work with monorepo
we don't really publish anything so lerna seems a bit overkill
a cold start (git clean -fdx && npm i && npm start) clocks in at around 3+min (npm start is ~1min)

We can do better! And hopefullly ViteJs is the answer!

Next gen frontend tooling 🙌

Cleaning up 🧹

First things first, let's get rid of everything we shouldn't need.

craco scripts, plugins and inside npm scripts
craco and cra dependencies
lerna deps and configs
node-sass, it's deprecated and we've had issues with node-gyp, we'll replace this with the official sass-package instead

Let's make it new 🔮

Time to see what we can do with new tooling!

Setup `npm@7` workspaces

Configure workspaces in root package.json like so:

{
 "worskpaces": [ "apps/*", "apps/tooling/*" ]
}

A quick npm i in the root and we're done. That was easy!

Add `vite` and configure for react

Add dependencies

vite
@vitejs/plugin-react-refresh
vite-plugin-svgr

vite-plugin-svgr is for importing .svg files as components so that import { ReactComponent as SvgIcon } from 'some.svg' keeps working

to App1 & App2 and create a basic configuration file vite.config.ts in each app-folder.

// vite.config.ts
import { defineConfig } from 'vite'
import reactRefresh from '@vitejs/plugin-react-refresh'
import svgr from 'vite-plugin-svgr'

export default defineConfig({
  plugins: [reactRefresh(), svgr()],
})

Fix svg component import's

Since we're importing svg's as components we now get a type error (for import { ReactComponent as SvgLogo } from '...') that can be fixed by adding this file to the root each app that imports svg's (i.e. where vite-plugin-svgr is used)

// index.d.ts
declare module '*.svg' {
  import * as React from 'react';
  export const ReactComponent: React.FunctionComponent<
    React.SVGProps<SVGSVGElement> & { title?: string }
  >;
}

Add `sass`-package

Basically all we needed was to npm i -D sass in our app's, but for 2 issues in our *.scss-files since the sass-package is stricter on some things:

Remove multiline @warn statements

- @warn 'bla,
-        di bla';
+ @warn 'bla, di bla

Escape return value of some functions

@function pagePercentageMargins($percentage) {
-   @return (0.5vw * #{$percentage});
+   @return (#{(0.5 * $percentage)}vw);
}

Other issues to solve

Using and resolving aliases from common-folder

To be able to split configuration between our 2 apps we used aliases (standard webpack resolve aliases) set in each app-config that we could use when resolving @imports from scss-files in the common-folder (different theme colors etc).

Aliases in the webpack-config (via a craco-plugin) are defined like so:

COMMON_COLORS: 'path/to/colors.scss'

, and @imported using sass-loader by prepending a tilde sign:

@import '~COMMON_COLORS';

With vite and sass, the tilde isn't needed and alises can easily be added to the config. Notice the hack for __dirname here since we went for a module-ts-file as config instead of a plain commonJs:

// vite.config.ts
import { defineConfig } from 'vite'
import reactRefresh from '@vitejs/plugin-react-refresh'
import svgr from 'vite-plugin-svgr'

+import { dirname, resolve } from 'path';
+import { fileURLToPath } from 'url';

+const __dirname = dirname(fileURLToPath(import.meta.url));

export default defineConfig({
  plugins: [reactRefresh(), svgr()],
+  resolve: {
+    alias: {
+      'COMMON_COLORS': resolve(__dirname, 'src/styles/colors.scss'),
+    }
+  },
})

To avoid ts-errors when using import.meta the "module"-property in tsconfig.json must be set to esnext, es2020 or system.

Provide `.env` parameters

In our cra/craco-setup some variables were provided via .env files and some set directly in the npm-script (making for long scripts 👀):

{
  "scripts": {
    "start": "cross-env CI=true REACT_APP_VERSION=$npm_package_version craco start"
  }
}

The default in a cra-setup is that all env-variables that begin with REACT_APP get's injected via webpack's define-plugin so you can use them in your scripts like this

const version = process.env.REACT_APP_VERSION;

In vite the default is that you use import.meta.env to get at variables. Only variables that begin with VITE_ are exposed and variables are automatically loaded via dot-env from .env-files.

Personally I dont really like long npm-scripts so I'd rather move the version and name we're using into the configuration.

In order to get that working, let's add a .env-file first:

VITE_CI=true

Then we'll update our config to provide a global pkgJson variable that we can use "as-is" instead of via import.meta.env:

// vite.config.ts
import { defineConfig } from 'vite'
import reactRefresh from '@vitejs/plugin-react-refresh'
import svgr from 'vite-plugin-svgr'
import { dirname, resolve } from 'path';
import { fileURLToPath } from 'url';
+import { name, version } from './package.json';

const __dirname = dirname(fileURLToPath(import.meta.url));

export default defineConfig({
  plugins: [reactRefresh(), svgr()],
  resolve: {
    alias: {
      'SASS_VARIABLES': resolve(__dirname, 'src/styles/common-variables.scss'),
    }
  },
+  define: {
+    pkgJson: { name, version }
+  }
})

Those were (almost) all the steps needed for us to convert from cra to vite, greatly improve install / startup speed and reduce complexity in a world that already has too much of just that 😉

Results

🍰🎉🚀

vite v2.0.5 dev server running at:

> Local:    http://localhost:3000/
> Network:  http://172.25.231.128:3000/

ready in 729ms.

The ~1 minute startup time went down to sub-second 😍🙌

DEV Community: Tobias Lundin

SvelteKit RPC with Hono

What we're working with

SvelteKit in Brief

Hono in Brief

What is RPC and Why Should You Care?

Why I'm Writing This

Type-safe client data loading

API-routes

Example

Downsides

Remote Functions

Example

Downsides

Take away

Enter 🔥 Hono RPC (docs)

1. Replacing API-routes with Hono

2. Adding validation and type-safety

3. Replace remote function with Hono client

4. Swagger UI from the OpenAPI specification

That's it

ViteJs - replacing create-react-app in a monorepo

Premise

Our original setup

Next gen frontend tooling 🙌

Cleaning up 🧹

Setup npm@7 workspaces

Add vite and configure for react

Fix svg component import's

Add sass-package

Other issues to solve

Using and resolving aliases from common-folder

Provide .env parameters

Results

Setup `npm@7` workspaces

Add `vite` and configure for react

Add `sass`-package

Provide `.env` parameters