pyRPC
← Back to Blog

Backward compatibility: how @rpc stayed working through v0.9.0

·8 min read

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.

Procedures docs · Why procedure kinds exist