@thednp/rpc 0.0.1 → 0.0.4

package/wiki/best-practices.md

@@ -2,12 +2,14 @@
 
 ## @thednp/rpc is a Transport Pipe
 
-`@thednp/rpc` handles serialization and **transport only**. It does not provide:
+The best thing to do **first** is to understand `@thednp/rpc` is that it only handles **transport** and **serialization**.
 
+It does not provide:
 - Caching
 - Authentication
 - Validation
 - State management
+- Request limits
 - Retry logic
 
 Use dedicated tools for these concerns.
@@ -85,23 +87,107 @@ export const updateProfile = createServerFunction(
 );
 ```
 
-Return validation errors as structured data — the client's `handleResponse` will surface them as an `Error`.
+Return validation errors as structured data — the client's `handleResponse` will surface them as an `Error`. Check [Server Functions Guide](./server-functions.md) for more detailed examples.
 
 ## Authentication
 
-Use middleware before `createRPCMiddleware()`:
+> Never add auth hooks inside server functions.
+
+Use authentication middleware **before** `createRPCMiddleware()`.
 
 ```ts
-// Express
 app.use(authMiddleware);
 app.use(createRPCMiddleware());
 ```
 
-> Never add auth hooks inside the plugin.
+
+### Basic Authorization
+
+A typical auth middleware reads credentials from the request, validates them, and sets `req.user`:
+
+```ts
+// Express
+const authMiddleware = (req, res, next) => {
+  const token = req.headers.authorization?.replace("Bearer ", "");
+  if (!token) {
+    res.status(401).json({ error: "Unauthorized" });
+    return;
+  }
+  try {
+    req.user = verifyToken(token); // { id, role, ... }
+    next();
+  } catch {
+    res.status(401).json({ error: "Unauthorized" });
+  }
+};
+```
+
+> In your production apps, **use best solutions** provided by server of your choice. The above code is only to showcase how to wire pieces together.
+
+### Per-Function Authorization
+
+When some server functions should be public and others require authentication, use `createMiddleware` with a handler that inspects the function name:
+
+```ts
+import type { Request } from "express";
+import { createMiddleware } from "@thednp/rpc/express";
+import { loadRPCConfig } from "@thednp/rpc";
+
+const publicFns = new Set(["login", "register", "publicData"]);
+const config = await loadRPCConfig();
+
+// use a type to better describe your requests
+type UserRequest = Request & {
+  user: YourUserType
+}
+
+const rpcAuthz = createMiddleware({
+  rpcPrefix: config.rpcPrefix,
+  handler: async (req: UserRequest, res, next) => {
+    const url = new URL(req.url, "http://localhost").pathname;
+    const fnName = url.replace(config.rpcPrefix, "");
+    const user = req.user; // set by earlier auth middleware
+
+    // Allow public functions through
+    if (publicFns.has(fnName)) return next();
+
+    // Reject unauthenticated
+    if (!user) {
+      res.statusCode = 401;
+      res.setHeader("Content-Type", "application/json");
+      res.end(JSON.stringify({ error: "Unauthorized" }));
+      return;
+    }
+
+    next();
+  },
+});
+```
+
+Wire it between auth and the RPC handler:
+
+```ts
+app.use(authMiddleware);      // sets req.user
+app.use(rpcAuthz);            // per-function guard
+app.use(createRPCMiddleware());
+```
+
+For role-based access, extend with a map:
+
+```ts
+const roleAccess: Record<string, string[]> = {
+  deleteUser: ["admin"],
+  updateProfile: ["user", "admin"],
+};
+
+if (!user || !roleAccess[fnName]?.includes(user.role)) {
+  // 401 or 403
+}
+```
 
 ## Body Limits
 
-In most cases you can rely on your framework's body-parser middleware:
+In most cases you should rely on your framework's body-parser middleware:
 
 ```ts
 // Express
@@ -136,8 +222,9 @@ const app = new Koa();
 app.use(koaBody({ jsonLimit: 1024 * 1024 })); // 1MB
 ```
 
+In other cases, your custom [server app](../examples/ssr/http-express.ts) can use something like this:
 ```ts
-// SSR (custom http server with Vite middleware mode)
+// SSR (custom node:http server with Vite middleware mode)
 import { createMiddleware, readBody } from "@thednp/rpc/express";
 import { loadRPCConfig } from "@thednp/rpc";
 
@@ -145,7 +232,7 @@ const config = await loadRPCConfig();
 const MAX_BODY_SIZE = 1024 * 1024;
 
 app.use(createMiddleware({
-  rpcPreffix: config.rpcPreffix,
+  rpcPrefix: config.rpcPrefix,
   handler: async (req, res, next) => {
     const { data } = await readBody(req);
     if (Buffer.byteLength(typeof data === "string" ? data : JSON.stringify(data)) > MAX_BODY_SIZE) {
@@ -159,6 +246,7 @@ app.use(createMiddleware({
 }));
 ```
 
+For SPA you can make use of the vite runtime [proxy](../examples/spa/vite.config.ts)
 ```ts
 // SPA (dedicated RPC proxy server)
 import { readBody } from "@thednp/rpc/express";
@@ -177,10 +265,85 @@ const bodyLimit = async (req, res, next) => {
 };
 ```
 
+## Rate Limiting
+
+Throttle RPC endpoints like any other route — rate limiting is the host's responsibility:
+
+```ts
+// Express
+import { rateLimit } from 'express-rate-limit';
+
+app.use('/__rpc', rateLimit({
+  windowMs: 60 * 1000, // 1 minute
+  limit: 60, // 60 requests per window
+  standardHeaders: 'draft-8',
+  legacyHeaders: false,
+}));
+app.use(createRPCMiddleware());
+```
+
+```ts
+// Fastify
+import rateLimit from '@fastify/rate-limit';
+
+await app.register(rateLimit, { max: 60, timeWindow: '1 minute' });
+```
+
+```ts
+// Hono
+import { rateLimiter } from 'hono-rate-limiter';
+
+app.use('/__rpc/*', rateLimiter({ windowMs: 60_000, limit: 60 }));
+```
+
+```ts
+// Koa
+import { rateLimit } from 'koa2-ratelimit';
+
+app.use(rateLimit.middleware({ interval: { min: 1 }, max: 60 }));
+```
+
+## Origin / CSRF Protection
+
+`@thednp/rpc` performs **no origin validation by default** — like authentication, it is opt-in so the host decides.
+
+### Option A: `origin` middleware option
+
+When your RPC endpoints sit behind a reverse proxy with multiple public origins (e.g. a sibling subdomain), pass the allowed origin to `createRPCMiddleware()`:
+
+```ts
+app.use(createRPCMiddleware({
+  origin: 'https://app.example.com',
+}));
+```
+
+Requests carrying an `Origin` header that does not match are rejected with `403 Forbidden`. Requests without an `Origin` header (curl, native apps) pass through unchecked.
+
+> `SameSite=Lax` cookies already block cross-site `POST` from HTML forms; the `origin` option closes the remaining "sibling subdomain" case.
+
+### Option B: custom middleware
+
+Check `Sec-Fetch-Site` (Fetch Metadata) or `Origin` yourself before the RPC middleware:
+
+```ts
+// Express
+app.use((req, res, next) => {
+  const site = req.headers['sec-fetch-site'];
+  if (site && site !== 'same-origin' && site !== 'none') {
+    res.status(403).json({ error: 'Forbidden' });
+    return;
+  }
+  next();
+});
+app.use(createRPCMiddleware());
+```
+
+Note that strict checks rejecting requests *without* these headers (TanStack Start style) will break curl and native clients — only enforce when the header is present, or provide an opt-out.
+
 ## SSR Guidance
 
 - On the **server**, `createServerFunction` runs directly (not Vite-transformed).
-- On the **client**, the plugin replaces server function calls with `fetch`-based client modules.
+- On the **client**, the plugin replaces server function calls with `fetch` based client modules.
 - Keep `src/entry-client.ts` and `src/entry-server.ts` separate for proper hydration.
 
 ## File Naming

package/wiki/client-usage.md

@@ -1,5 +1,9 @@
 # Client Usage
 
+Server functions, despite their name, work in both server and client side (transformed into `fetch` based modules by our plugin), a perfect fit for isomorphic rendering.
+
+In most apps you will be working with client focused apps.
+
 ## Auto-Generated Client Modules
 
 When you import from `./api` in your client code, the plugin intercepts the import and generates a client module for each server function.
@@ -15,7 +19,7 @@ Each imported function returns:
 ```
 
 - **`data`** — A promise that resolves to the server function's return value.
-- **`cancel(reason)`** — Aborts the underlying fetch request, causing `signal.aborted` to be set in the server function.
+- **`cancel(reason: string)`** — Aborts the underlying fetch request, causing `signal.aborted` to be set in the server function.
 
 ### Example
 
@@ -31,11 +35,11 @@ cancel('user cancelled'); // triggers AbortController on the client side
 
 - **Fetch errors** (network failure, CORS) — thrown from `await data`
 - **HTTP 4xx/5xx responses** — thrown from `await data`
-- **Cancellation** — returns `"Request cancelled by user"` from `await data`
+- **Cancellation** — aborts the fetch and warns `"Request was cancelled"` in the console
 
 ## @tanstack/react-query Integration
 
-`@thednp/rpc` is a dumb pipe — it handles serialization and transport only. For client-side caching, invalidation, and stale-while-revalidate patterns, use `@tanstack/react-query`:
+`@thednp/rpc` is a transport pipe — it handles serialization and transport only. For client-side caching, data invalidation, and stale-while-revalidate patterns, use `@tanstack/react-query`:
 
 ```ts
 import { useQuery, useMutation, useQueryClient } from '@tanstack/react-query';

package/wiki/configuration.md

@@ -8,7 +8,7 @@ Create `rpc.config.ts` in your project root for system-wide configuration:
 import { defineConfig } from '@thednp/rpc';
 
 export default defineConfig({
-  rpcPreffix: '__rpc',
+  rpcPrefix: '__rpc',
   adapter: 'express',
 });
 ```
@@ -17,7 +17,6 @@ export default defineConfig({
 
 Update your `vite.config.ts` in your project root and set additional development options:
 
-
 ```ts
 import { defineConfig } from 'vite';
 import rpc from '@thednp/rpc';
@@ -34,12 +33,12 @@ export default defineConfig({
 
 | Option       | Type     | Default     | Description                                                  |
 | --------------| ----------| -------------| --------------------------------------------------------------|
-| `rpcPreffix` | `string` | `'__rpc'`   | RPC endpoint prefix used in URL routing                      |
+| `rpcPrefix` | `string` | `'__rpc'`   | RPC endpoint prefix used in URL routing                      |
 | `adapter`    | `string` | `'express'` | Target adapter (`'express'`, `'fastify'`, `'hono'`, `'koa'`) |
 
 ## Config File Discovery
 
-When `configFile` is not specified, the plugin searches for config files in this order:
+The plugin searches for config files in this order:
 
 1. `rpc.config.ts`
 2. `rpc.config.js`
@@ -60,7 +59,7 @@ Type-safe helper for creating the config object. Provides autocomplete and type
 import { defineConfig } from '@thednp/rpc';
 
 export default defineConfig({
-  rpcPreffix: '__rpc',
+  rpcPrefix: '__rpc',
 });
 ```
 
@@ -72,6 +71,6 @@ Programmatically load the RPC config, useful in custom server setups:
 import { loadRPCConfig } from '@thednp/rpc';
 
 const config = await loadRPCConfig();
-console.log(config.rpcPreffix); // '__rpc'
+console.log(config.rpcPrefix); // '__rpc'
 console.log(config.adapter);    // 'express'
 ```

package/wiki/getting-started.md

@@ -3,35 +3,52 @@
 ## Installation
 
 ```bash
-pnpm add @thednp/rpc@latest
+// pnpm + jsr registry
+pnpm add jsr:@thednp/rpc
 ```
 
 ```bash
-npm install @thednp/rpc@latest
+// pnpm + npmjs registry
+pnpm add @thednp/rpc
 ```
 
 ```bash
-bun add @thednp/rpc@latest
+// npm + npmjs registry
+npm install @thednp/rpc
 ```
 
 ```bash
-deno add npm:@thednp/rpc@latest
+// bun + npmjs registry
+bun add @thednp/rpc
+```
+
+```bash
+// deno + npmjs registry
+deno add npm:@thednp/rpc
+```
+
+```bash
+// deno + jsr registry
+deno add jsr:@thednp/rpc
 ```
 
 ## Quick Start
 
+For a quick understanding of a project setup check the [dedicated wiki section](./setup.md).
+
 ### 1. Configure system wide configuration `rpc.config.ts`
 
 ```ts
 import { defineConfig } from "@thednp/rpc";
 
 export default defineConfig({
-  rpcPreffix: "__server",
+  rpcPrefix: "__rpc",
   adapter: "express",
 });
 ```
 
 Currently `@thednp/rpc` supports `'express'`, `'fastify'`, `'hono'` and `'koa'`. Check [adapters](./adapters.md) for more guides.
+
 Also check [configuration](./configuration.md) for more guides.
 
 
@@ -63,7 +80,15 @@ export const sayHi = createServerFunction(
 );
 ```
 
-### 4. Use it on the client
+Expose it in `src/api/index.ts`
+
+```ts
+export * from "./server"
+```
+
+Check the [server functions guide](./server-functions.md) for details.
+
+### 4. Use it in your code
 
 ```ts
 import { sayHi } from './api';
@@ -74,3 +99,7 @@ cancel('user cancelled');
 ```
 
 That's it — the plugin auto-scans `src/api/server.ts`, maps exports to client functions, and replaces `./api` imports with fetch-based client modules during the Vite transform.
+
+For a more detailed guide on client-side usage, check the [dedicated wiki section](./client-usage.md).
+
+Next you need to [connect the adapter](./adapters.md) with your server of choice.

package/wiki/index.md

@@ -2,25 +2,13 @@
 
 A Vite plugin for creating server functions with automatic Remote Procedure Calls (RPC) generation. Server functions are defined in a dedicated file, auto-scanned, and transformed into client-side fetch modules — no manual API route setup required.
 
-## Features
-
-- File-level server code isolation without directives like `'use server'`
-- System-wide configuration via `rpc.config.ts`
-- Automatic RPC generation for server functions
-- `AbortController` support for request cancellation
-- Adapters for Express, Fastify, Hono, and Koa with unified API
-- Framework-agnostic core
-- TypeScript support
-- Path-segment prefix matching prevents URL boundary bypass
-- @tanstack/react-query integration for client-side caching and invalidation
-
 ## Table of Contents
 
-- [Getting Started](getting-started.md) — Installation and quick start
-- [Setup Guide](setup.md) — Project structure and configuration
-- [Configuration](configuration.md) — Configuration reference
-- [Server Functions](server-functions.md) — Creating server functions
-- [Client Usage](client-usage.md) — Client-side usage
-- [Adapters](adapters.md) — Framework adapters
-- [Security](security.md) — Security hardening
-- [Best Practices](best-practices.md) — Tips and best practices
+- [Getting Started](./getting-started.md) — Installation and quick start
+- [Setup Guide](./setup.md) — Project structure and configuration
+- [Configuration](./configuration.md) — Configuration reference
+- [Server Functions](./server-functions.md) — Creating server functions
+- [Client Usage](./client-usage.md) — Client-side usage
+- [Adapters](./adapters.md) — Framework adapters
+- [Security](./security.md) — Security hardening
+- [Best Practices](./best-practices.md) — Tips and best practices

package/wiki/security.md

@@ -2,10 +2,10 @@
 
 ## Prefix Boundary Check
 
-All adapters use `new RegExp(\`^/${rpcPreffix}/\`)` instead of `startsWith` to match the RPC endpoint path. This prevents path-segment bypass attacks:
+All adapters use `new RegExp(\`^/${escapeRegExp(rpcPrefix)}/\`)` instead of `startsWith` to match the RPC endpoint path. The prefix is escaped with `escapeRegExp()` before being embedded in the boundary regex, preventing ReDoS or unintended matching from metacharacters in the prefix. This prevents path-segment bypass attacks:
 
 ```
-rpcPreffix = '__rpc'
+rpcPrefix = '__rpc'
 
 # Safe: matches /__rpc/foo
 // __rpc/foo  →  /__rpc/
@@ -28,6 +28,27 @@ const pathname = url.pathname; // clean, no query string
 
 Error responses do not echo the requested function name. This prevents function enumeration — an attacker cannot discover available RPC functions by probing for non-existent endpoints.
 
+## HTTP Method Enforcement
+
+Server functions default to `POST`, and the middleware rejects any request whose HTTP method does not match the function's configured method with `405 Method Not Allowed`:
+
+```
+GET  /__rpc/do-stuff  →  405  (function defaults to POST)
+POST /__rpc/do-stuff  →  200
+```
+
+This blocks the simplest CSRF vector: an attacker page embedding `<img src="/__rpc/do-stuff">` or a form `GET` that would otherwise trigger side effects. Functions that opt into `method: "GET"` (via `createServerFunction(name, handler, { method: 'GET' })`) receive their arguments as an `?args=` JSON query parameter. Reserve `GET` for side-effect-free functions only. See [Server Functions Guide](./server-functions.md) for details.
+
+## Origin Validation
+
+`@thednp/rpc` performs no origin validation by default, but `createRPCMiddleware()` accepts an `origin` option:
+
+```ts
+app.use(createRPCMiddleware({ origin: 'https://app.example.com' }));
+```
+
+When set, any request carrying an `Origin` header that does not match the configured origin is rejected with `403 Forbidden`. Requests **without** an `Origin` header (curl, native clients) pass through — the check only rejects when the browser-provided header disagrees. This closes the "sibling subdomain" CSRF gap that `SameSite=Lax` cookies alone cannot cover. See [Best Practices Guide](./best-practices.md) for custom middleware alternatives.
+
 ## Authentication via Middleware
 
 Authentication is handled by middleware registered **before** `createRPCMiddleware()`. The middleware chain composes naturally:
@@ -38,7 +59,7 @@ app.use(authMiddleware);             // auth first
 app.use(createRPCMiddleware());      // RPC second
 ```
 
-Do not add auth hooks inside the plugin. Use your framework's standard middleware pattern.
+Do not add auth hooks inside the plugin. Use your framework's standard middleware pattern. Check [Best Practices Guide](./best-practices.md) for more detailed examples.
 
 ## Body Size Limits
 
@@ -49,6 +70,7 @@ JSON body size limits are handled by your framework's body-parser middleware:
 - **Koa**: `koa-body({ formLimit: '1mb' })`
 - **Hono**: Built-in body size limiting
 
-Since the RPC framework's `readBody` also accepts `text/plain` requests (not parsed by the JSON body parser), the raw stream path in the Express and Koa adapters has a built-in safety net — a `maxBodySize` parameter that defaults to **1 MiB**. Pass a custom value to `readBody(req, signal, myLimit)` to override.
+The `readBody` utility of each adapter reads the raw request stream and does **not** impose a built-in size limit — always register your framework's body-parser middleware (or a custom limit handler) before `createRPCMiddleware()`. Check [Best Practices Guide](./best-practices.md) for body-limit examples.
 
-Register body parsing middleware before `createRPCMiddleware()`.
+## Input Validation
+Server functions receive raw, untrusted client data. Always validate before use. Check [Server Functions Guide](./server-functions.md) for more detailed examples.

package/wiki/server-functions.md

@@ -1,5 +1,15 @@
 # Server Functions
 
+## Overview
+
+Server functions run exclusively on the server. They have access to server-only resources (databases, file system, environment variables, private APIs) and **never execute on the client**.
+
+The `@thednp/rpc` Vite plugin transforms imports of server functions into client-side stubs that call the real implementation over HTTP. This isomorphic bridge means you write your functions once and call them from either server-rendered pages or client-side code — the RPC middleware handles routing on the server while the generated client modules handle serialization, transport, and cancellation.
+
+All examples except the SPA use SSR to demonstrate this: the same server functions are imported directly during server-side rendering (in `entry-server.ts`) and also called from client-side JavaScript (via the auto-generated fetch module).
+
+The [SPA example](../examples/spa) uses a thin `node:http` based proxy that executes the server functions.
+
 ## `createServerFunction(name, handler, options?)`
 
 The core API for defining server-side functions.
@@ -10,15 +20,49 @@ The core API for defining server-side functions.
 function createServerFunction<T>(
   name: string,
   handler: (signal: AbortSignal, ...args: JsonArray) => Promise<T>,
-  options?: { contentType: 'application/json' | 'text/plain'}
+  options?: {
+    contentType?: 'application/json' | 'text/plain',
+    credentials?: "same-origin" | "include" | "omit",
+    method?: "GET" | "POST",
+  }
 ): ServerFunction<T>;
 ```
 
 ### Parameters
 
-- **`name`** (`string`) — The registered name used in RPC routing. Must match the name used when calling the function on the client.
+- **`name`** (`string`) — The registered name used in RPC routing.
 - **`handler`** (`(signal: AbortSignal, ...args: JsonArray) => Promise<T>`) — The actual implementation. The first argument is always an `AbortSignal`; remaining arguments come from the client. The return value must be JSON-serializable.
-- **`options`** (`{ contentType?: 'application/json' | 'text/plain' }`) — Optional serialization strategy. Defaults to `'application/json'`.
+- **`options`** — Optional credentials, serialization strategy, and HTTP method
+  * `contentType?: 'application/json' | 'text/plain'` - Defaults to `'application/json'`.
+  * `credentials?: "include" | "same-origin" | "omit"` - Defaults to `'same-origin'`.
+  * `method?: "GET" | "POST"` - Defaults to `'POST'`.
+
+### HTTP Method
+
+By default every server function is invoked via `POST`. Functions that are safe to call from a browser URL bar, a `<script>` tag, or a CDN can opt into `GET` — arguments then travel as an `?args=` JSON query parameter:
+
+```ts
+export const publicData = createServerFunction(
+  'public-data',
+  async (signal, topic: string) => {
+    return await fetchPublicData(topic);
+  },
+  { method: 'GET' },
+);
+```
+
+The generated client module issues a `GET /__rpc/public-data?args=%5B%22news%22%5D` request. The middleware rejects requests whose HTTP method does not match the function's configured method with `405 Method Not Allowed` — so `POST`-only functions are safe from cross-site `GET` requests, and `GET` functions can be linked/bookmarked directly.
+
+> **Security note:** defaulting to `POST` prevents CSRF via `<img>`/`<script>`/form `GET` requests. Only set `method: "GET"` for functions with no side effects.
+
+> **Why only `GET` and `POST`?** This is deliberate, not an oversight:
+>
+> - RPC dispatch is not REST — functions have no resource semantics, so the meanings of `PUT` (idempotent replace), `PATCH` (partial update), or `DELETE` (removal) don't apply to a function call. The only transport distinctions that matter are `POST` (args in the body, any payload) and `GET` (args in the query string, cacheable by browsers and CDNs).
+> - `OPTIONS` is reserved by the HTTP protocol for CORS preflight; browsers send it automatically, and frameworks handle it. Exposing it as a function method would collide with framework CORS handling.
+> - `HEAD` is derived from `GET` at the HTTP layer, so it needs no function-level support.
+> - Every accepted method is another dispatch path to validate. Keeping the surface minimal (and defaulting to `POST`) reduces CSRF and parsing attack surface.
+>
+> If a concrete need arises (e.g. a REST-style wrapper wanting true `PUT` semantics), the `method` union is a one-line extension — adapters already centralize dispatch on it.
 
 ### AbortSignal
 
@@ -44,11 +88,11 @@ When `createServerFunction` is called, it registers the function in a server-sid
 
 ### Return Type
 
-The return value of `handler` is serialized to JSON and sent as the HTTP response body. Ensure your return type is JSON-serializable.
+The return value of `handler` is serialized to JSON and sent as the HTTP response body. **Ensure your return type is JSON-serializable.**
 
 ## Input Validation
 
-Server functions receive raw, untrusted client data. Always validate before use.
+Server functions receive raw, untrusted client data. **Always validate data within your server functions before use.**
 
 **zod:**
 

package/wiki/setup.md

@@ -6,17 +6,21 @@
 project/
 ├── src/
 │   ├── api/
+│   │   └── index.ts         # All server functions exports
 │   │   └── server.ts        # Auto-scanned server functions
 │   ├── entry-client.ts      # Client entry (SSR projects)
 │   └── entry-server.ts      # Server entry (SSR projects)
 ├── vite.config.ts           # Add rpc() plugin here
 ├── rpc.config.ts            # Optional config
-└── package.json
+├── package.json             # The project npm configuration
+└── server.js                # Your Express/Hono/Fastify/Koa server
 ```
 
+> Various frameworks like `@tanstack-start`, `@sveltejs/kit` prefer a more specific structure, so be sure to check their documentation; most frameworks have their own data transport layer.
+
 ## Server Files
 
-The plugin looks in `src/api/` for files matching these names:
+The plugin looks in `src/api/` for files with these **exact** names (matching is case-sensitive and non-partial, so `server.tsx`, `my-server.ts`, or `server.txt` are ignored):
 
 - `server.ts`
 - `server.js`
@@ -36,7 +40,7 @@ Each matched file is loaded with `vite.ssrLoadModule`, and all named exports are
 
 ### SSR Projects
 
-Create both `src/entry-client.ts` and `src/entry-server.ts`. The client bundle imports from `./api`, which gets transformed by the plugin. On the server, `createServerFunction` runs directly (not transformed).
+Create both `src/entry-client.ts` and `src/entry-server.ts`. The client and server bundles both import from `./api`. On the client your server function gets transformed by the plugin. On the server, `createServerFunction` runs directly (not transformed).
 
 ### SPA Projects
 
@@ -74,4 +78,4 @@ await attachRPC(app);  // production
 attachVite(app, vite); // development
 ```
 
-See [Adapters](adapters.md) for full server setup examples.
+See [Adapters](./adapters.md) for full server setup examples.