Mental Model

pyRPC treats your backend as a library of typed functions. It eliminates the need for heavy build steps by leveraging different strategies for each ecosystem:

• Python: Uses dynamic runtime introspection. Procedures are discovered as you call them. No build step required.
• TypeScript: Uses static contract synchronization. Since TypeScript needs types at development-time for autocompletion, a one-step codegen is used to sync the contract.

Dynamic vs. Static

The core of pyRPC is its ability to introspect itself.

When you use the Python client, it asks the server "what can you do?" and builds the client on the fly. When you use TypeScript, we use that same introspection power during development to generate a Types interface. This gives you the best of both worlds: zero-boilerplate Python and rock-solid TypeScript autocompletion.

Every RPC procedure is a Python function decorated with @rpc:

@rpc
def add(a: int, b: int) -> int:
    return a + b

The client calls it the same way:

client.add(a=10, b=5)  # 15

No OpenAPI Middle Layer

Unlike REST or OpenAPI-based tools, pyRPC does not:

• Generate schemas
• Require you to maintain .yaml or .json spec files
• Force a separate client codegen step for Python

Instead of generating "SDKs", pyRPC synchronizes typed contracts. Types flow directly from your procedures; the protocol carries the data, and the client infers the rest.

End-to-End Typing

When you add a procedure, the client can call it with full awareness of parameters and return type. Errors are structured and typed too — see Error Handling.

Next

• Architecture — Deep dive into the Registry, Introspection, and Contract tiers
• Protocol Design — How requests and responses are structured
• Error Handling — How errors are represented and propagated