pyRPC
← Back to Blog

One api object: Provider, prefetch, and hooks in the same place

·9 min read

The easiest RPC clients are the ones you barely configure. For pyRPC’s TanStack adapters, that means a single exported value — call it api, client, or pyrpc — that carries procedures, the provider, and (on Next) prefetch/hydration.

The shape

export const api = createNextClient<Types>({
  baseUrl: process.env.PYRPC_URL!,
})

// layout
<api.Provider>{children}</api.Provider>

// server
await api.prefetch.greet("Ada")
<api.HydrationBoundary state={api.dehydrate()}>…</api.HydrationBoundary>

// client
api.greet.useQuery("Ada")

No destructuring. No second “hooks client” import. The factory name is create*Client; the variable name is yours.

Why this beats returning four exports

Early drafts returned { api, prefetch, dehydrate, HydrationBoundary }. Correct, but noisy — every file re-imported a different subset. Collapsing onto one object matches how people already think about “the client,” and keeps App Router helpers discoverable via autocomplete on the same value.

Reserved helper names

Top-level helpers (Provider, prefetch, dehydrate, …) win if they collide with a procedure name. Don’t name an RPC procedure prefetch. Same class of constraint as other typed RPC clients.

React and Vue

React: api.Provider + api.greet.useQuery. Vue: createPyrpcVue returns the same idea with api.plugin for TanStack’s Vue Query plugin.

Next: RSC prefetch & hydration · Docs