# graftcode: calling a hosted service like a local package

> graftcode turns public methods on a module hosted by the Graftcode Gateway into generated, strongly typed clients that you install with npm, pip or dotnet. The idea removes hand-written integration layers, but the engine lives in separate repositories and the licence is not stated.

**grft-dev/graftcode** — Connect any code. Call as dependency. The official repository for Graftcode: the integration-free development layer that lets you call methods across languages and runtimes on remote services as if they were local. Eliminate integration layer code entirely.

- Repository: https://github.com/grft-dev/graftcode
- Website: https://graftcode.com
- Stars: 972 · Forks: 9
- Language: PowerShell
- License: not declared
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/grft-dev-graftcode

## Public methods become an installable package

graftcode is presented as an integration-free development layer. The README describes it as a framework that lets you call methods across any language and runtime as if they were local, without writing integration code, SDKs or client layers, and its summary line is that you can call remote code like local dependencies and let package managers keep them fresh.

The workflow has three moves. You write public methods in the language you prefer. You run them on Graftcode Gateway, described as a multi-runtime host that runs on your cloud instances, bare metal, containers or your local machine. Then you install auto-generated, strongly typed Grafts into any other project through npm, dotnet, pip and similar package managers, and call the remote code as if it were local.

The README states it plainly in one line: no controllers, no OpenAPI, no client code, no IDL. That list matters, because each of those is a thing teams currently maintain by hand and each of them goes stale when the service changes.

The supported language set is wide: .NET, Java, Python, Node.js, Go, PHP, C++ and Ruby, across Windows, Linux, macOS and Android, with Azure, AWS, GCP and Docker named as deployment targets. The audience is therefore a team running several stacks at once, where the cost of an integration layer is paid per consumer per language.

## The Gateway is the part you actually deploy

The mechanics start with a build artefact rather than a schema. The quick start has three commented steps: build or package your library, navigate to the output folder, and download the Graftcode Gateway. The download is a one-liner per platform, and the gateway is then run against your module:

```bash
# Windows
iwr https://grft.dev/get | iex

# Linux / macOS
curl -fsSL https://grft.dev/get | sh

# Run the Gateway with your module:
# Example with .NET
gg --modules ./MyService.dll
```

The gg command takes the compiled module as an argument, so the deployment unit is your existing library file rather than a wrapper project you write around it.

The other side of the contract is errors. The README says you write public methods, communicate errors through exceptions, and call them like local code. Exceptions travel across the boundary instead of error codes, which removes a large class of per-language error mapping code.

One behaviour worth noting is the version handshake. Whenever the API evolves, graftcode informs your package manager that a new version of the dependency is available. That turns an API change into a dependency bump, which is a workflow teams already know how to review and roll back.

## Grafts install from a project scoped registry

Consumption works through the normal package manager, pointed at a registry URL that carries the project id:

```bash
npm install --registry https://grft.dev/YOUR_PROJECT_ID @graft/your-service-name
```

The npm flag is the interesting part. The graft is not fetched from the public npm registry; it is fetched from the Graftcode registry scoped to your project, and installed under the @graft scope. From the consumer's point of view it is an ordinary dependency, so it lands in package.json, it can be version pinned, and it flows through the same lockfile review as anything else.

The generated client mirrors the remote API. The README example imports a class and calls a method on it:

```typescript
import { EnergyPriceCalculator } from '@graft/...';

const price = await EnergyPriceCalculator.GetPrice();
```

The install command itself is obtained by navigating to the service hosted on Graftcode Gateway, which is at http://localhost when the Gateway is run locally. That is how the registry path and the package name are discovered: the running Gateway serves the command you paste.

For a monorepo or a team with several services, this means the consumer project gains a dependency entry rather than a folder of hand-written fetch calls, and the generated client is regenerated by the platform rather than maintained by a person.

## The runtime lives in separate repositories

This repository is not the engine. The top level entries are .github/, CONTRIBUTING.md, README.md, cli/, docs/, examples/ and rules/, and the only example file is examples/README.md. There is no src tree, no test suite and no build script for the runtime here.

The core repositories table spells out where the pieces are. graftcode-gateway is the core multi-runtime host described as the engine. graftcode-demos holds live demos and performance comparisons. graftcode-quick-start-guide holds the hands-on tutorials. graftcode-documentation holds the full documentation. graftcode-docker-images holds the official images, and graftcode-plugins holds official open source plugins for any communication channel, with ServiceBus, RabbitMQ and Kafka named.

That layout has consequences for an evaluator. You cannot read the transport code in this repository, you cannot read the code generation logic, and you cannot read the plugin implementations. Judging the project means reading four other repositories. It also means the plugin set is where the interoperability claims are settled: the README talks about switching communication channels such as WebSocket, HTTP/2, RabbitMQ, Kafka, Service Bus, SQS and Pub/Sub without changing code, and the plugins repository is where you would confirm which of those actually exist today.

The rules/ directory is also unexplained in the README, and the README does not describe it.

## What the README claims, and what it does not show

The pitch is aggressive, and it is worth separating the mechanism from the assertions.

The mechanism is coherent and narrow: a gateway hosts a module, public methods become a generated typed client, the client is installed from a registry, and exceptions propagate instead of error codes. Nothing in that description depends on the more sweeping claims.

Those claims include reducing your codebase by up to 50%, dramatically improving AI-assisted development through lower token usage and simpler code reviews, and making every backend immediately MCP-compatible for AI agents. No measurement is offered for any of them. The graftcode-demos repository is described as holding performance comparisons, so that is where a number would have to come from, not from this README.

The AI agent angle is worth taking seriously on its own terms, since the repository topics include ai-agents and mcp, and the quick start guide lists a tutorial on using with AI agents over MCP. But an agent calling your service through an MCP server and an agent calling it through a generated package are different mechanisms with different trust properties, and the README does not separate them.

The documentation gap is the other honest limit. The README refers to graftcode-documentation for the full documentation and to a Quick Start Guide repository for tutorials on connecting a frontend to a backend, exposing a first service, switching between monolith and microservices, and using with AI agents. What is in this README is the sales summary. The substance is in repositories you have to go and read.

## No licence, no tagged releases, a PowerShell primary language

Three facts about the repository itself deserve attention before any code is written.

The first is the licence. The licence field is empty, GitHub reports the licence as unknown, and there is no LICENSE file among the top level entries, which include CONTRIBUTING.md, README.md, cli/, docs/, examples/ and rules/. For a commercial tool that a team would vendor into a build pipeline, that is a blocking question rather than a footnote. Ask the maintainers what terms apply to graftcode, the Gateway and the generated Grafts separately, because the generator and the runtime are different pieces of code in different repositories.

The second is release history. The repository has no GitHub releases. The repository is not archived, and the last push was on 2026-09-24. There is a roadmap badge pointing at a Featurebase board, and a roadmap link in the README, so planning lives outside the repository rather than in a CHANGELOG. Pinning a commit is the only reproducible option here.

The third is a small oddity: the primary language for the repository is reported as PowerShell, while the visible source is cli/ and rules/. That is consistent with a repository whose scripts target Windows contributors, but it is also a hint about where the code actually lives.

## Conclusion

graftcode suits teams with an existing polyglot estate that keep rewriting REST, gRPC or Thrift clients by hand and want one call surface with generated clients on the consumer side. It does not suit a team that needs to know exactly which licence it is shipping under, because the licence field on the repository is empty and no licence file is listed at the top level, nor a team that wants the runtime itself in one place, since the Gateway, plugins and Docker images live in separate repositories. Before adopting, read the graftcode-documentation repository and the graftcode-gateway repository, confirm the licensing terms directly with the maintainers, and run the Quick Start Guide against a throwaway service before touching a production API.

## FAQ

### What does graftcode do?

graftcode lets you write public methods in your preferred language, run them on the Graftcode Gateway, and install auto-generated, strongly typed Grafts into other projects through npm, dotnet or pip, so remote code can be called as if it were local.

### How do I install a graftcode service?

Build or package your library, download the Graftcode Gateway with iwr https://grft.dev/get | iex on Windows or curl -fsSL https://grft.dev/get | sh on Linux and macOS, then run it against your module with a command such as gg --modules ./MyService.dll.

### How do clients consume a graftcode service?

The generated Graft is installed from the project scoped registry with a command such as npm install --registry https://grft.dev/YOUR_PROJECT_ID @graft/your-service-name, and then imported and called like any other package.

### Which languages and platforms does graftcode support?

The README lists .NET, Java, Python, Node.js, Go, PHP, C++ and Ruby as supported languages, with Windows, Linux, macOS and Android as platforms, and names Azure, AWS, GCP and Docker as deployment targets.

### What licence is graftcode released under?

The licence field on the repository is empty and GitHub reports the licence as unknown, with no licence file listed at the top level of the tree. The terms for graftcode, the Graftcode Gateway and the generated Grafts need to be confirmed with the maintainers before use.

## Sources

- [grft-dev/graftcode on GitHub](https://github.com/grft-dev/graftcode)
- [Issues](https://github.com/grft-dev/graftcode/issues)
- [Project website](https://graftcode.com)
- [README](https://github.com/grft-dev/graftcode/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/grft-dev-graftcode