REST and Graftcode coexistence

When to use this

You have production REST (or gRPC) APIs and want to add Graftcode incrementally — not replace everything at once.

Prerequisites

• Existing REST service
• Where Graftcode fits (concept)

---

Recommended approach

Graftcode adds a runtime integration layer alongside REST — it does not remove your HTTP endpoints.

---

Steps

1. Extract a public facade for Graftcode

Expose public methods on a facade class; keep REST controllers calling the same core:

// Graftcode surface
public static class OrderFacade
{
    public static OrderDto GetOrder(string id) => OrderServiceCore.GetOrder(id);
}

// REST unchanged
[ApiController]
[Route("api/orders")]
public class OrdersController : ControllerBase
{
    [HttpGet("{id}")]
    public IActionResult Get(string id) => Ok(OrderServiceCore.GetOrder(id));
}

2. Host facade on GG

./gg ./MyService.dll --types MyApp.OrderFacade --port 8888 --httpPort 8889

3. Consume via Graft internally or from edge

Internal microservice:

import { OrderFacade } from "@graft/nuget-MyService";
const order = await OrderFacade.getOrder("42");

External clients can keep using REST while new apps adopt Grafts.

4. MCP alongside REST

GG exposes MCP automatically for configured facades — MCP expose tools. REST endpoints remain for non-AI clients.

---

Migration patterns

No big-bang rewrite required.

---

Verify it works

• REST regression tests pass
• Graft consumers call same business outcomes as REST endpoints
• Vision lists only facade types (not every controller)

---

Common mistakes

---

See also

• Internal business APIs
• Filtering exposed types
• Quick Start README — REST coexistence note