What is Graftcode?

Graftcode makes public methods callable across languages, processes, and machines — as if they lived in the same codebase. You write plain business code on one side; the other side installs a generated package and calls those methods like local functions. No hand-written REST clients, controllers, or DTOs for the integration.

Two roles matter: the Receiver exposes the public methods, and the Caller consumes them through a generated Graft. Transport and hosting (including when execution is remote) are configuration, not code you write by hand. For how Graft, Gateway, Hypertube, Vision, and Graftcode Engine fit together, see How Graftcode works.

What Graftcode is for

Graftcode's main goal is to unify how software communicates and integrates — regardless of the technologies involved or the integration scenario. It is not only for service-to-service calls. The same model covers:

• Frontend to backend — a web or mobile frontend calls backend methods directly.
• Backend to backend — service-to-service calls across languages.
• Expose a public API — expose selected methods to controlled callers.
• Mix modules in memory — run modules from different technologies in one process.
• Expose methods for AI — every exposed method is also callable as an MCP tool.

It applies the same way to stateless, stateful, streaming, bi-directional (duplex), and unary interactions. In every case the model is the same:

• On the Receiver (server) side, integration code is reduced to plain public methods — no controllers, routes, DTOs, or transport clients.
• On the Caller (client) side, you install a self-updating, strongly typed Graft through your normal package manager and call those methods like local code. When the Receiver's contract changes, you regenerate and reinstall the Graft, so the client stays in sync with the server through a versioned package.

Because the integration method is selected by configuration rather than written into your code, you can swap the communication channel (in-memory, WebSocket, and other transports) without touching business logic — see Execution modes.

Every exposed method is also an MCP tool

Methods you expose through Graftcode are automatically callable over MCP as well, so the same public surface serves both application callers and AI clients without extra integration code. See Expose Receiver methods for MCP.

Example: calling a billing method across services

The problem: a Node.js application needs calculateMonthlyBill(unitPrice, units), which lives in a .NET service owned by another team.

Without Graftcode: controller with routes + hand-written client

Server side — the capability is wrapped in an HTTP controller with routes, attributes, and request/response DTOs:

// Illustrative REST controller — not Graftcode
[ApiController]
[Route("api/v1/billing")]
public class BillingController : ControllerBase
{
    private readonly BillingService _billing;

    [HttpPost("monthly-bill")]
    public ActionResult<MonthlyBillResponse> CalculateMonthlyBill([FromBody] MonthlyBillRequest request)
    {
        var total = _billing.CalculateMonthlyBill(request.UnitPrice, request.Units);
        return Ok(new MonthlyBillResponse { Total = total });
    }
}

public class MonthlyBillRequest { public decimal UnitPrice { get; set; } public int Units { get; set; } }
public class MonthlyBillResponse { public decimal Total { get; set; } }

// Illustrative REST client — not Graftcode
using var http = new HttpClient();
http.DefaultRequestHeaders.Authorization = new("Bearer", token);
var res = await http.PostAsJsonAsync(
    "https://billing.example/api/v1/billing/monthly-bill",
    new { unitPrice = 10, units = 5 });
res.EnsureSuccessStatusCode();
var total = (await res.Content.ReadFromJsonAsync<MonthlyBillResponse>()).Total;

Server side (Receiver) — a plain public method. No controller, route, or DTO plumbing:

public class BillingService
{
    public decimal CalculateMonthlyBill(decimal unitPrice, int units) => unitPrice * units;
}

// Install the Graft; copy package name and host from Vision
GraftConfig.Host = "ws://billing.example/ws"; // before the first call
var billing = new BillingService();
var total = billing.CalculateMonthlyBill(10, 5);

No hand-written HTTP client, route map, or JSON DTO layer for this internal call—the public method signature is the contract, and the installed Graft is the client. You still operate a distributed system (hosts, auth, failures, observability); Graftcode removes the repetitive protocol glue for callers that can install generated packages.

For a public HTTP API aimed at arbitrary third parties, REST or GraphQL may remain the better boundary—see Use Graftcode alongside REST.

Why this matters

Reducing integration to public methods on the server and a generated Graft on the client changes how the whole codebase reads and evolves:

• Readability — call sites are ordinary method calls, so code expresses intent instead of transport plumbing.
• Direct model mapping — public methods map directly to UML class, interaction, and sequence diagrams, because there is no protocol layer in between.
• Simpler PRs and code review — changes appear as business-logic diffs, not controller, DTO, and client boilerplate.
• Maintainability — fewer artifacts to keep in sync; a changed public method flows to callers as a regenerated package.
• Channel independence — business code is fully isolated from the integration method, so you can change transport or execution mode by configuration rather than by rewriting code.

AI-assisted code engineering

The same reduction in code and indirection makes a codebase far friendlier to AI-assisted development. With no separate protocol layer and much less integration boilerplate, an AI assistant ingests less code to understand a feature, follows the call graph more directly, and needs fewer iterations and less context to make a correct change. In practice that means lower token usage, faster refactoring, cheaper generation and maintenance, and fewer integration mistakes.

How this differs from REST, GraphQL, gRPC, and tRPC

Most integration stacks start with a protocol contract you design and maintain separately from your business code — OpenAPI routes, GraphQL schemas, .proto files, or shared TypeScript router types. Graftcode starts from public methods you already write on a Receiver module. The Graft is the client; callers install it and invoke those methods like local code.

For teams connecting services that can install a package, Graftcode is significantly better to use than protocol-first stacks in day-to-day work. You write and call methods—not routes, GraphQL documents, .proto definitions, or tRPC router wiring. The generated Graft carries transport and serialization; the same call site works in-memory or remotely when you change GraftConfig. Less boilerplate, fewer artifacts to keep in sync, and a shorter path from a changed public method to a working cross-language call.

Protocol-first vs method-first

REST, GraphQL, gRPC, and tRPC are strong choices for public boundaries and ecosystems where those tools are already standard. Graftcode fits frontend-to-backend, service-to-service, and controlled internal callers that should not maintain a hand-written integration layer.

At a glance

You can keep REST or GraphQL for external clients and add Graftcode for internal integration — see Use Graftcode alongside REST.

A Graft call is still distributed: auth, failures, timeouts, and observability still matter.

How they compare

For developer experience and integration speed, Graftcode is the stronger default when Callers can install generated packages: you skip the protocol layer that REST, GraphQL, gRPC, and tRPC require you to design, version, and maintain alongside your business code.

REST and gRPC keep a protocol contract (URLs/operations, schemas, and a client) separate from your business code. With Graftcode the supported public method surface is the contract and the installed Graft is the client. For raw throughput, neither approach is universally faster; the right choice still depends on who owns the contract, who the Callers are, and your interoperability, streaming, and browser needs. For how much code you write and how fast you ship internal integration, Graftcode is typically the better fit.

Graftcode removes application-authored controllers, DTO mapping, transport clients, and serialization code for controlled Callers. Its runtime still represents and transfers invocation data, so the resulting performance depends on the runtime pair, execution mode, payload, transport, topology, and workload. This documentation does not publish comparative performance numbers without a documented, reproducible benchmark.

Where teams use Graftcode

• Frontend to backend — call backend methods from a web or mobile frontend.
• Backend to backend — service-to-service calls across languages, without hand-written HTTP clients.
• Expose a public API — share a Receiver's selected methods with controlled Callers.
• Mix modules in memory — run modules from different technologies in one process, then flip to remote execution by configuration.
• Expose methods for AI — make the same methods callable as MCP tools.

Pick your goal and runtime in Choose a scenario, and review current status and limitations before production.

Next steps

1. Quick start — first working call for your stack.
2. How Graftcode works — the How it works diagram and mental model.
3. Choose a scenario — pick your goal, then your runtime.
4. Quick reference — keep open while coding.