v0.9.0 added procedure kinds, four new npm packages, and a new codegen output format. None of it broke existing code. Here is how.
Bare @rpc defaults to query
If you have code like this, it still works exactly as before:
@rpc
def greet(name: str) -> str:
return f"Hello, {name}!"rpc (without .query or .mutation) sets kind="query" by default. The introspection schema now includes kind: "query" on every procedure. Codegen emits ProcedureKinds with all queries. The adapters use that to show useQuery on every procedure.
Without kinds, both hooks appear
If you do not pass kinds: procedureKinds to the adapter, every procedure gets both useQuery and useMutation. That is the backward-compatible path — you can adopt kinds gradually.
// No kinds — both hooks exist on every procedure
const api = createReactClient<Types>({ baseUrl: "..." })
api.greet.useQuery("Ada") // works
api.greet.useMutation() // also works (but wasteful)createClient is unchanged
@pyrpc/client v0.9.0 is a version bump only. The createClient function, the Proxy, PyRPCError, and the transport are identical.
Framework adapters are opt-in
The new packages (@pyrpc/react, next, vue, svelte) are new npm packages. If you use createClient directly, nothing changes. The adapters are an addition, not a replacement.
PyPI extras are additive
pip install pyrpc-core still works. The extras (pyrpc-core[fastapi], etc.) are optional additions. The standalone adapter packages (pyrpc-fastapi, etc.) still exist.
The principle
Every new feature is opt-in. Bare @rpc works. No-kinds adapters work. Existing installs work. The only thing that changes is that the introspection schema now includes a kind field. If your code ignores it, nothing breaks.

pyRPC