Hono RPCTyped on both sides
A typed request surface that refreshes without leaving the route.
The initial response comes through the route loader, then the same endpoint can be revalidated on the client through the Hono RPC client.
The response is live and re-fetchable.
The same typed endpoint powers the initial route load and the in-page refresh action.
01
RPC response
Values returned from `GET /api/rpc/hello`, rendered first by the loader and then refreshed on demand.
- Message
- Hello, World!
- Server
- Hono RPC
- Timestamp
- 2026-04-05T19:23:21.974Z
02
Endpoint contract
The route and API stay connected through the generated Hono client instead of manual fetch strings.
- Endpoint
- GET /api/rpc/hello
- Implementation
- app/apis/mod.ts
- Initial source
- Route loader / shared API response factory
- Refresh path
- Action button → Hono RPC client
03
What this demonstrates
The page is built to show where SSG, hydration, revalidation, and typed API calls intersect.
- Prerendered shell
- The route can ship static structure at build time.
- Hydrated data
- The initial server-rendered response stays visible while the client can fetch fresh data on demand.
- Client refresh
- The button fetches fresh RPC data without reloading the page.
- Typed boundary
- The `hc()` client keeps route code aligned with the API contract.