How Graftcode works

A Caller invokes a Receiver through a generated Graft. Hypertube — the communication channel inside the Graft — carries the programmer's intent: the method call, its arguments, and the result. The same call site can run in-memory or remotely; only GraftConfig changes, not your business code. For remote execution, Gateway (gg), a C++ runtime server, hosts the Receiver and mediates the connection — built for substantially lower overhead than typical integration-server stacks in this role.

The diagram, left to right

Caller — Your application. Service business logic runs here.

Graft — The generated package the Caller installs and imports (npm install @graft/... — copy the command from Vision). See What is a Graft?.

Hypertube — The communication channel inside the Graft. It carries the programmer's intent to the Receiver — in-memory when configured, or through Gateway for remote calls. See Hypertube runtime bridge.

Gateway — A C++ runtime server (gg) that hosts the Receiver module and mediates remote connections. Install and run it — see Gateway and hosted modules.

Receiver — The module Gateway hosts. Service business logic runs here.

Vision — Gateway UI for discovery, install commands, and configuration snippets (for Dev and AI workflows). See Graftcode Vision.

Graftcode Engine and public interface — Setup-time path only. Gateway captures each side's public interface; the Engine generates the installable Graft. Normal calls use the installed Graft and Hypertube — they do not regenerate the package.

Five things to remember

1. The module is your code. A Receiver is an ordinary class library or module. Its intentional, supported public methods form the callable surface.
2. The Graft is generated code. It is a package for the Caller's package manager and language. It mirrors the Receiver surface; it is not the Receiver implementation.
3. Host the module or install from the public repository. To expose your own Receiver, run Gateway (gg): it loads the module, serves Vision, and publishes the model used to generate packages — see Gateway and hosted modules. To consume a capability someone else published, install a Graft from the public repository without running your own Gateway.
4. Configuration selects monolith or microservice. The same installed Graft can run in-memory in the Caller process (modular monolith) or remotely against a Gateway host (microservices). Set GraftConfig before the first call — see Configure invocation, Execution modes, and Switch between monolith and microservices.
5. A method call is still distributed. Serialization, routing, failures, compatibility, security, retries, and observability still matter when host points at a remote Gateway.

Build time versus call time

During setup, Gateway analyzes the Receiver and the package system generates a language-specific Graft. During normal runtime invocation, the already-installed Graft sends the call through its resolved execution path. It does not regenerate the package.

The contract

The contract is the supported public surface: declaring types, methods, parameters, return values, and public model members. Public does not automatically mean portable. The whole path—Graftcode Engine generation and runtime execution—must support every exposed type.

Keep transport, database, framework, and implementation types private or internal. For the safest cross-language surface, use simple primitives, strings, and plain models, then test the exact Receiver/Caller pair.

A useful distinction

• Written: Receiver logic, Caller logic, runtime configuration, operational policy.
• Generated: Graft package, language bindings, contract metadata, Vision views.
• Operated: Gateway process, transports, package access, deployment, security, telemetry.

That distinction prevents two common mistakes: treating Gateway as the generated client, or treating the generated client as if it removes remote-system failure modes.

Continue

• Quick start — hands-on tutorials for your stack.
• What is Graftcode? — definition, REST vs Graftcode example, and use cases.
• Caller and receiver
• Invocation lifecycle
• Choose a scenario