DEV Community: Justin

Calling Services Over Azure Service Bus Without Writing a Client Layer

Justin — Mon, 19 Oct 2026 11:38:58 +0000

TL;DR

Azure Service Bus guarantees delivery between services, but it never writes the code that turns a delivered message into a typed method call with a result, and that layer is where request and reply calls go wrong under load. A missed session filter or a mismatched correlation field doesn't throw an error, it just looks like a slow caller. This piece covers what a correct Service Bus call requires by hand, where that work gets expensive, and how a transport plugin removes the client layer without changing anything about Service Bus itself.

Getting Started: What Azure Service Bus Handles and What It Leaves to You

Azure Service Bus is a managed message broker that sits between services, accepting a message from a producer and delivering it to a consumer without either side needing to be online at the same moment. It supports two core patterns: queues, where each message goes to exactly one consumer, and topics with subscriptions, where each message can go to several independent consumers at once.

Teams reach for Service Bus for the same reason they reach for any managed broker, reliable delivery, durability, and platform-handled ordering without running that infrastructure themselves. What Service Bus doesn't hand you is the code that turns a delivered message into an actual method call with a typed result. That part stays with whichever team is consuming the message, and it's easy to underestimate until a reply routes to the wrong caller or a failure disappears into a timeout with no clear cause.

The running example for this piece is a service that runs a physics calculation and returns a result. Several callers across a system need to invoke it, and each one needs its own reply to come back correctly, even when three or four calls are in flight on the same reply queue at once. Getting that right by hand is where most of this piece's complexity lives.

What Building a Correct Service Bus Call Requires

Getting a request and reply call working correctly over Service Bus means solving three separate problems, and it's easy to get the first two working in a demo and only discover the third one is broken once two callers hit the service at the same time. A request has to reach the right queue. A reply has to find its way back to the specific client that asked for it, not just whichever client happens to be listening on the reply queue. And a server-side failure has to reach the caller as something recognizable as a failure, not as a message that quietly never shows up.

That middle problem is where teams go wrong. Without a session strategy, two clients sharing a reply queue can end up reading each other's responses, or one client blocks while waiting for a reply that has already been delivered elsewhere. Solving it by hand looks roughly like this:

# Everything below exists only to get a reply back to the right caller; none of it is business logic
from azure.servicebus import ServiceBusClient, ServiceBusMessage
import uuid

def call_physics_calculator(payload: bytes) -> bytes:
    session_id = str(uuid.uuid4())
    with ServiceBusClient.from_connection_string(CONN_STR) as client:
        sender = client.get_queue_sender(queue_name="myqueue")
        receiver = client.get_queue_receiver(
            queue_name="myqueue.reply", session_id=session_id
        )
        message = ServiceBusMessage(payload)
        message.reply_to_session_id = session_id
        sender.send_messages(message)

        reply = receiver.receive_messages(max_wait_time=30)
        if not reply:
            raise TimeoutError("no response within timeout")
        return b"".join(reply[0].body)

None of this describes what the physics calculation actually does. It's session setup, a reply filter, and a timeout, three things a team has to get right before any real logic runs, and get wrong silently if they don't.

Where the Integration Work Piles Up as Patterns Change

The shape of this work changes depending on how a service consumes Service Bus, but it doesn't get smaller:

A simple queue consumer needs SDK setup and message deserialization written by hand before any downstream call happens, and the consumer's expected schema can drift from what the producer actually sends with no build-time warning.
Request and reply over queues needs everything a simple consumer needs, plus session generation, a session-filtered receiver, and correlation matching. A missed session filter or a mismatched correlation field means a reply lands with the wrong caller, or never arrives at all.
Topics and subscriptions need SDK setup and deserialization repeated per subscription, so every subscription reimplements the same consumer logic even when the message shape is identical across all of them.

Request and reply is the expensive one of the three. Sessions exist so a reply queue can be shared safely across many callers at once, but that safety only holds if the session filter, the reply-to field, and the correlation match are all correct, and a mistake in any one of them doesn't throw an error. It just looks like latency.

The Cost of Writing This Layer by Hand

Backend teams commonly lose 30 to 40 percent of engineering time to integration code in general, HTTP clients, DTO drift, SDK versioning, and Service Bus consumers carry that same tax plus a few costs specific to the broker:

Session plumbing per caller: every service that needs request and reply correlation reimplements session generation and session-filtered receivers on its own, even when three other teams are calling the same downstream service.
Silent correlation bugs: a session or correlation mismatch doesn't throw an error, it just means a caller times out waiting for a reply that already went somewhere else.
Manual timeout and retry logic: every hand-written client ends up with its own version of this, rarely consistent with how any other caller of the same service handles it.
Schema drift above the broker: nothing enforces that a consumer's expected message shape still matches what the producer sends, the same problem REST has, just moved to sit above Service Bus instead of behind an endpoint.

None of this shows up on an architecture diagram. It shows up in how long it takes to debug a caller that's timing out for no visible reason, and in how many times different teams rewrite the same session-handling code for the same dependency.

A Transport Plugin That Handles Sessions and Correlation for You

Graftcode is a runtime-level integration platform, and its Azure Service Bus plugin lets a service call route through Service Bus without writing any session or correlation code by hand. The architecture underneath is the same three pieces Graftcode uses everywhere: a Graft, a strongly typed interface installed via a package manager that mirrors the provider's public methods, GraftConfig, an internal setting of each Graft that decides whether a call runs in process or through a configured transport, and the Graftcode Gateway, which runs and hosts the provider service itself.

On top of that, the plugin offers two modes, set purely by configuration, request and reply over queues for methods that return something, and one-way over a topic for methods that don't. Configuring the client side of a request and reply call looks like this in C#, the only language this configuration pattern is currently confirmed for:

graft.nuget.PhysicsCalculator.GraftConfig.SetConfig("""
{
  "configurations": {
    "graft.nuget.PhysicsCalculator": {
      "runtime": "netcore",
      "stateless": true,
      "plugin": {
        "name": "ServiceBusPlugin",
        "connectionString": "Endpoint=sb://<namespace>.servicebus.windows.net/;SharedAccessKeyName=<keyName>;SharedAccessKey=<key>",
        "queue": "myqueue",
        "replyQueue": "myqueue.reply",
        "rpcTimeoutMs": 30000
      }
    }
  }
}
""");

Everything the earlier hand-written snippet did now happens inside the plugin. Session generation reuses the request's own correlation ID, and the reply receiver attaches a session filter scoped to that session, the same filter mechanism the official .NET and Java SDKs use. Matching is a little more forgiving than a single rigid field too, either the correlation ID or the message ID is accepted. A server-side failure reaches the caller the same way a local exception would, the response's first byte doubles as a sentinel, where a specific value means everything after it is an error message, thrown client-side as a native exception, and any other value means a normal response.

The one-way mode skips sessions and correlation entirely, since there's no reply expected. A client publishes to a topic and returns immediately, and the server consumes from a topic subscription without sending anything back. Multiple subscriptions on the same topic each receive their own independent copy of the message, this is native Service Bus pub and sub, not something built on top of the plugin.

How This Extends Your Existing Service Bus Setup

Adopting this plugin doesn't ask a team to change how it already uses Service Bus. Whatever namespace, session, and dead-lettering configuration already exists stays exactly as it is, and the plugin gets adopted per service pair, usually starting with whichever one currently has the most hand-written session and correlation code sitting on top of it.

It also doesn't touch anything Service Bus already does well, durability, ordering, and dead-lettering are unaffected. What it removes is the layer above that, client setup, session handling, correlation matching, and the deserialization a consumer would otherwise write by hand.

Local development splits into two genuinely separate options worth keeping apart:

Pointing at the official Service Bus emulator, which still runs something locally but removes the dependency on a live Azure namespace during testing.
Setting GraftConfig to in-process mode, which skips the broker entirely so the call never leaves the process, useful for fast logic iteration without needing an emulator or a namespace at all.

Here's what changes in practice between writing this layer by hand and letting a plugin handle it:

Session handling: manual session generation and a session-filtered receiver written per caller, versus session handling that lives inside the plugin.
Correlation: manual matching between request and reply, versus automatic matching with a documented fallback field.
Failure visibility: a dropped or mismatched reply that just looks like a timeout, versus an error that crosses the wire as a defined signal and throws as a native exception.
Multiple subscriptions: separate consumer code written per subscription even for identical message shapes, versus one configured plugin path regardless of subscription count.
Local testing: a real namespace or a manually configured emulator client, versus GraftConfig's in-process mode or the plugin's own emulator support.

This isn't a claim that the plugin removes coupling between services, that depends on how boundaries are drawn, not on what sits underneath a call. What it removes is the session, correlation, and client code that adds overhead on top of a service boundary that's already reasonably drawn.

Where Should You Start

Service Bus solves delivery well, durability, ordering, and dead-lettering are the broker's job, not the consuming service's. What it never solved was the code a team writes to turn a delivered message into a typed method call, and that code carries real session and correlation risk regardless of how reliable the underlying broker is. The pattern that keeps causing production incidents isn't a Service Bus limitation, it's a missing session filter or a mismatched correlation field that nobody notices until two callers collide on the same reply queue.

If your team is currently maintaining hand-written session and correlation code for a request and reply call over Service Bus, that's the specific place to start looking at whether a transport plugin would help, not a wholesale migration. Explore Graftcode to see how the Service Bus plugin fits your setup, or go to the Graftcode Academy for the full configuration reference and the other broker plugins currently available.

FAQs

Does the plugin change any of Service Bus's own delivery guarantees?

No. Durability, ordering, dead-lettering, and session-based delivery are all Service Bus features and stay exactly as configured. The plugin only removes the hand-written client, session, and correlation code that would otherwise sit above those guarantees.

How does a server-side exception actually reach the calling code?

The response payload carries a one-byte sentinel. A specific first-byte value means everything after it is read as an error message and thrown client-side as a native runtime exception. Any other first byte means a normal successful response, so error handling on the calling side looks the same as it would for a local method call.

Can a service use both request and reply and one-way calls at the same time?

Yes. The mode is chosen per configuration, not system-wide. One service call can be configured for request and reply over queues while another is configured for one-way over a topic, depending on whether each method returns a value.

Is there a message size limit to plan around?

Yes. Azure Service Bus caps standard-tier messages at 256 KB and premium-tier messages considerably higher, and the plugin enforces its own ceiling around 1 MB in its current source. A method returning a large object can hit this in a way it wouldn't over a direct connection, so a large payload either needs a higher tier or should stay on a direct-connection transport instead.

What's the practical difference between a Service Bus queue and a topic?

A queue delivers each message to exactly one consumer, which is what request-and-reply calls use. A topic delivers each message to every subscription attached to it, so multiple independent consumers can each get their own copy of the same message. That's why one-way, fire-and-forget calls use a topic and request and reply calls use a queue.

Does adopting a transport plugin mean migrating everything onto Service Bus?

No. It's built to extend an existing setup incrementally. A team can configure it for a single service pair where session and correlation overhead is highest, while every other service pair keeps running however it already does. You don't need to migrate an entire system to adopt it for one call.

Backend for Frontend Pattern: When and Why to Use It

Justin — Thu, 15 Oct 2026 10:45:48 +0000

TL;DR

A Backend for Frontend gives each client type, web, iOS, Android, its own dedicated backend shaped around what that interface actually needs to render, instead of forcing every client to filter down one shared, general-purpose API response. The pattern solves a real client-shaping problem, but it comes with a cost: duplicated integration logic across services, more deployments to operate, and an added network hop in every request path. This piece covers what a BFF actually does, how it differs from an API gateway, what running several of them costs, and where the integration layer inside each one can be trimmed down.

Getting Started: What a Backend for Frontend Pattern Solves

A Backend for Frontend, usually shortened to BFF, is a server-side service built and owned by the team responsible for one specific client, web, iOS, Android, or a third-party integration, and positioned between that client and the backend services it depends on. Instead of one general-purpose API shaped to satisfy every consumer at once, each frontend gets a backend shaped around what that interface actually needs: the fields it renders, the requests it can afford to make, and the aggregation it would otherwise have to do on-device.

The pattern traces back to engineering teams at REA and SoundCloud, who ran into the same problem from different directions: a shared backend serving a growing set of very different clients kept accumulating logic for all of them at once. Phil Calçado's original write-up on the pattern, later catalogued by Sam Newman as a named architectural pattern, put the fix plainly: build one backend per user experience rather than one general-purpose backend for everyone. A mobile client and a desktop client don't just render the same data differently, they operate under different constraints entirely, screen space, battery, and network reliability among them, and a shared backend has no clean way to represent that difference in a single schema.

Ownership is the part of the definition worth noting early. A BFF isn't an API split by client type at the routing level. It's typically built and deployed by the same team that owns the frontend it serves, using whatever language and release cadence fits that team, independent of how the core backend services are versioned or shipped.

Every product that ships more than one client eventually runs into the same argument: should all of them talk to the same backend, or should each one get something closer to what it actually needs. For years the default answer was one shared backend, reused across every client because building a new API per interface felt like duplicated infrastructure. That default holds up fine with one client and a handful of endpoints. It stops holding up once a mobile app on a metered connection and a desktop dashboard with a dozen open panels are both hitting the same general-purpose response, and someone has to decide whose needs the next schema change should serve.

Why a Single Shared Backend Strains Across Multiple Clients

A shared backend degrades in a specific, predictable way as the number of client types grows. It doesn't fail outright, it accumulates conditional logic, optional fields nobody wants to remove because some client still depends on them, and query parameters that exist only to let one interface ask for less than everyone else gets by default.

The practical symptoms show up as three separate but related pressures:

Growing functionality. The backend's feature surface keeps expanding to cover every platform it serves, which makes it harder to reason about and slower to change safely.
Team bottlenecks. Frontend teams have to coordinate with a separate backend team before shipping anything that needs a new field or a different shape, turning a frontend release into a cross-team negotiation.
Forced aggregation. Combining data from several downstream services into one response becomes the shared backend's job for every client at once, rather than something each client can shape around its own needs.

None of these problems are really about scale in the infrastructure sense, they're about ownership and shape. A backend that has to satisfy a phone app and a desktop dashboard at the same time is optimizing for neither, and the team that owns it ends up mediating a conflict of interest between two frontends that don't need to agree on anything.

How a Backend for Frontend Differs From an API Gateway

The BFF pattern gets confused with an API gateway often enough that it's worth stating the distinction directly, since the two solve different problems and most systems that use one still need the other.

Client awareness. An API gateway is client-agnostic, applying the same routing and policy layer to every caller. A BFF is client-aware, built specifically for one frontend's needs.
Typical owner. A platform or infrastructure team usually owns the gateway. The frontend team the BFF serves owns the BFF.
Core job. A gateway handles routing, authentication, rate limiting, and other cross-cutting concerns across services. A BFF handles aggregating and reshaping data into what one specific UI needs.
What triggers a change. A gateway changes on platform-wide policy updates. A BFF changes on that frontend's own release cycle.

The structural difference comes down to what each layer is centered on. An API gateway is infrastructure-centric, applying the same routing and security policy to every request regardless of who's calling. A BFF is application-centric, built around one frontend's specific needs and evolving on that frontend's own schedule. A system commonly runs both together: an API gateway handling routing, authentication, and rate limiting for every service, with one or more BFFs sitting behind it, each shaping a response for its own client.

Where a BFF Sits Inside a Microservices Call Path

In a typical microservices system, a single screen rarely maps to a single downstream service. A dashboard home screen might need workspace metadata from one service, usage figures from a second, and recent alerts from a third. Without a BFF, the client itself has to make three separate calls and stitch the results together on-device.

A BFF moves that aggregation off the client and onto a service the frontend team controls. The client makes one call to its BFF, the BFF fans out to each downstream service it needs, combines the results into the shape that screen actually renders, and returns a single response. The downstream services stay unaware a BFF exists between them and the client, they're just handling requests from another internal caller.

This is also where the pattern's real engineering cost lives. Every BFF that aggregates from multiple services needs a client for each of those services, something to deserialize each response, and error handling for when one of those calls fails while the others succeed. That code has nothing to do with what the BFF is actually for, shaping a response for one frontend, and it's the same category of integration work a shared backend already had to do, just now duplicated across however many BFFs a system ends up running.

The Real Operational Cost of Running Several BFFs

Adopting the pattern is rarely a question of whether it solves the client-shaping problem, it does. The harder question is whether a team can absorb the ongoing cost of running several BFFs. The most commonly cited costs fall into a few consistent categories:

Code duplication. If a web BFF and a mobile BFF both aggregate from the same three downstream services, the integration logic, the HTTP clients, the response parsing, the retry handling, tends to get written twice, once per BFF, with no natural place for it to live once.
Operational overhead. Each BFF is its own deployable, with its own release pipeline, its own secrets, and its own service-level objectives to track, so a system with three BFFs has three times the operational surface area of a single shared backend.
Added latency. A BFF sits between the client and the services it aggregates from, so every request pays for one additional network hop a direct client-to-service call wouldn't have, which matters more for latency-sensitive interfaces than for ones with looser response-time budgets.

There's a structural dimension to this too. A BFF's boundaries tend to track team boundaries rather than pure technical ones, since the pattern exists specifically to give a frontend team a backend it can change without waiting on anyone else. That's a genuine advantage while team structure is stable, but a reorganization that merges or splits frontend teams usually forces a corresponding restructuring of the BFFs those teams own, a maintenance cost that has nothing to do with the underlying services at all.

Deciding Whether the BFF Pattern Is Worth Adopting

The pattern earns its cost when a shared backend is genuinely straining to serve conflicting client needs, when different frontends would benefit from different languages or release cadences, or when a frontend team is regularly blocked waiting on a separate backend team to ship a change only that frontend needs.

It's a weaker fit when every client makes roughly the same requests and expects roughly the same shape back, since a BFF built for that case adds an extra hop and a second service without shaping anything meaningfully differently. GraphQL with frontend-specific resolvers already lets each client ask for exactly the fields it needs from a single schema, addressing much of the same over-fetching problem without a separate service per client. And if only one interface actually talks to the backend today, there's no shaping conflict yet to resolve.

The practical test is whether the client-shaping problem is real and recurring, not hypothetical. A team debating the pattern for a single web client with no mobile app on the roadmap is usually better served by fixing the shared backend's worst over-fetching cases directly than by introducing a second service to maintain.

How Graftcode Reduces the Integration Code Inside Each BFF

None of the BFF pattern's actual job, deciding what a client needs and shaping a response around it, changes with Graftcode in the picture. What changes is the code each BFF writes to reach the services it aggregates from, the hand-written integration layer, HTTP clients, DTO mapping, response parsing, that shows up duplicated across every BFF a team runs, sitting alongside whatever REST, gRPC, or broker setup already connects those services.

A BFF calling three downstream services today typically means three hand-rolled clients, three sets of response types to keep in sync with whatever each service actually returns, and error handling written separately for each one. Graftcode reduces that layer with a Graft per service: a strongly-typed interface generated directly from that service's public methods and installed through a package manager, the same way a dependency gets installed today. The BFF calls a method directly instead of constructing a request, and gets a strongly-typed object back with no manual deserialization required.

# Install a Graft for each downstream service (per-service pip index, per docs.graftcode.com)
python -m pip install --extra-index-url https://grft.dev/simple/<project-id>__free graft-nuget-workspaceservice==1.0.0


# The mobile BFF's dashboard endpoint, aggregating three services through Grafts
from graft_nuget_workspaceservice.graft.nuget.WorkspaceService import GraftConfig as WorkspaceConfig
from graft_nuget_workspaceservice.workspaceservice import WorkspaceService

from graft_nuget_usageservice.graft.nuget.UsageService import GraftConfig as UsageConfig
from graft_nuget_usageservice.usageservice import UsageService

from graft_nuget_notificationservice.graft.nuget.NotificationService import GraftConfig as NotificationConfig
from graft_nuget_notificationservice.notificationservice import NotificationService

WorkspaceConfig.host = "wss://workspace-service-host/ws"
UsageConfig.host = "wss://usage-service-host/ws"
NotificationConfig.host = "wss://notification-service-host/ws"

@app.get("/mobile/dashboard/{workspace_id}")
async def mobile_dashboard(workspace_id: str):
    workspace = WorkspaceService.get_summary(workspace_id=workspace_id)
    usage = UsageService.get_current_period(workspace_id=workspace_id)
    alerts = NotificationService.get_unread(workspace_id=workspace_id)
    return {
        "workspace": workspace,
        "usage": usage,
        "unread_alerts": alerts,
    }

Every object returned above, workspace, usage, alerts, arrives as the same strongly-typed object the provider service defined, with no manual JSON parsing or DTO mapping on the BFF's side. Locally, each GraftConfig can point in-memory instead of at a remote host, so a developer can iterate on the aggregation logic without three downstream services actually running. In staging or production, switching each Graft to its remote host is a configuration change, not a rewrite.

This doesn't remove the extra network hop a BFF adds, and it doesn't touch what makes the pattern work in the first place, one team owning a service shaped around its own frontend. What it reduces is the integration code sitting inside that service that has nothing to do with shaping a response, and it cuts into the exact duplication problem that shows up whenever more than one BFF calls the same downstream service.

The duplication problem doesn't fully disappear just because each BFF's calls to a shared downstream service get cleaner. If a web BFF and a mobile BFF both call WorkspaceService, they're still two separate consumers of the same interface, each free to call different methods or handle a response differently. What changes is where that duplication lives. Instead of two hand-written HTTP clients drifting apart as each BFF's team makes its own small adjustments, both BFFs install the same Graft and call the same typed methods, so an interface change on WorkspaceService's side surfaces as a package update to both, rather than a schema mismatch one team discovers in production.

Where Should You Start

The Backend for Frontend pattern solves a specific, well-understood problem: a shared backend can't shape itself around conflicting client needs without becoming unwieldy for everyone it serves. Splitting that backend by client gives each frontend team a service it can shape and ship on its own terms, at the cost of duplicated integration logic, more services to operate, and an added network hop that has to fit inside each client's latency budget. Whether that trade is worth making depends on how real the shaping conflict actually is today, not on how many client types a roadmap might eventually include.

For a team that's already decided the pattern fits, the next question is usually how much of each BFF's code ends up being aggregation logic instead of business logic, and whether that ratio is sustainable across however many BFFs the system runs. Explore how a Graft-based approach fits an existing BFF at graftcode.com, or go to the Graftcode Academy for the full setup and configuration reference.

Frequently Asked Questions

Does the BFF pattern replace the need for an API gateway?

No. An API gateway handles cross-cutting concerns, routing, authentication, rate limiting, uniformly across every client and service. A BFF handles client-specific shaping for one frontend. Most systems that use the BFF pattern still run an API gateway in front of it for the concerns a BFF isn't designed to solve.

How does the BFF pattern compare to using GraphQL with per-client resolvers?

Both address over-fetching and under-fetching, but differently. GraphQL lets each client query a single schema for exactly the fields it needs, while a BFF gives each client a dedicated service instead. A team already running GraphQL with resolvers tuned per client may not need a separate BFF layer on top of it.

When should a team avoid adopting the BFF pattern?

When every client makes similar requests and expects a similar response shape, when only one interface currently consumes the backend, or when an API gateway plus the existing shared backend already handles the system's needs without conflict. Adding a BFF in these cases adds operational cost without solving a shaping problem that actually exists.

Does Graftcode replace the Backend for Frontend pattern?

No. Graftcode doesn't decide how a client's response should be shaped, that's the BFF's job, owned by the frontend team. Graftcode reduces the hand-written integration code a BFF writes to reach the downstream services it aggregates from, without changing what the BFF exposes to its own client.

Does using Graftcode inside a BFF require migrating the services it calls?

No. A downstream service adopts Graftcode by running a Graftcode Gateway that hosts it and exposes its public methods, nothing about how that service is written has to change. A BFF can then install a Graft for that service one dependency at a time, without requiring every downstream service to adopt it at once.

How much duplicated code should a team expect across several BFFs before it becomes a real problem?

There's no fixed threshold, it tracks how many downstream services multiple BFFs share and how often those services' interfaces change. A useful signal is whether engineers are regularly fixing the same integration bug in more than one BFF, that's usually the point where centralizing or typing that layer starts paying for itself.

Is the BFF pattern only useful for mobile versus web, or does it apply to other client types too?

It applies to any consumer with meaningfully different needs from the rest, which includes third-party API integrations, internal admin tools, and partner-facing clients, not just mobile versus web. The deciding factor is whether that client's shape or request pattern is different enough to justify its own service, not what kind of client it is.

Legacy Modernization Without a Full Rewrite: A Practical Guide

Justin — Tue, 29 Sep 2026 13:51:01 +0000

TL;DR

Legacy modernization is the process of updating systems that have become hard to change or scale, without losing the business logic built into them over years. Most modernization projects don't stall because teams pick the wrong pattern. They stall because teams underestimate the integration cost, the work of bridging what's been extracted back to what remains. This guide covers the Strangler Fig pattern, how to pick a first extraction candidate that won't stall, three supporting patterns for different extraction problems, and where the real cost of modernization actually hides.

Getting Started: What Legacy Modernization Actually Means

Legacy modernization is the process of updating or replacing software systems that have become difficult to change, scale, or maintain, without losing the business logic and institutional knowledge built into them. Most legacy systems weren't built badly. They were built for the constraints of their time, a smaller team, a different scale, a deployment model that made sense a decade ago. The problem isn't the original decisions. It's what compounds on top of them: new features bolted on, abstractions that leak, a codebase that gets harder to reason about with every change.

Modernization covers a spectrum of approaches:

Replatforming: moving the system to new infrastructure without changing the code. Lowest risk, lowest reward.
Refactoring: restructuring internal code without changing external behavior. Improves maintainability but doesn't touch architectural constraints.
Re-architecting: changing the system's structure, typically monolith to services, while preserving business logic. Higher risk, higher reward.
Replacing: rewriting from scratch. Justified only when the existing system is fundamentally unsalvageable.

This guide covers the space between re-architecting and replacing, moving toward a more flexible architecture while keeping the system live and delivering value throughout.

Why Modernization Projects Actually Stall

Legacy systems are hard to modernize not because the code is bad, but because the coupling is invisible until you move something. A module that looks self-contained can have tendrils reaching into shared databases, shared utility libraries, and runtime contracts nobody documented.

Three failure patterns repeat across modernization projects regardless of team size or stack. The first is the big-bang rewrite: a team estimates 12 months, delivers in 24, and ships a system that no longer matches what users need because requirements shifted mid-rewrite. A Rails monolith being rewritten in Go is a common shape for this. By the time the Go version ships, the original Rails app has absorbed 40 new feature commits the rewrite never accounted for.

The second is the partial migration that freezes. A team extracts auth and the product catalog cleanly, then hits order management, a module that writes directly to 11 tables shared with inventory, billing, and fulfillment. No clean extraction path exists without touching all four services at once. The migration stalls, and the organization ends up running two systems indefinitely, carrying the complexity of both and the benefit of neither.

The third is integration cost exceeding extraction value, and it's the most common and least discussed of the three. A Python data service extracted from a Java monolith is clean on its own. Bridging it back to the monolith requires a Java HTTP client, a DTO mapping layer, a versioning strategy, and error handling the original in-process call never needed. The extracted service takes two weeks to build. The bridge takes three. Multiply that across five more extractions in three languages, and the integration work consumes every hour the extraction was supposed to save.

The Strangler Fig Pattern Explained in Plain Terms

The Strangler Fig pattern is the foundational approach to incremental modernization. Named after a vine that grows around a host tree and gradually replaces it, the pattern extracts functionality from a legacy system piece by piece while keeping the system live throughout.

The core mechanism is a routing layer, an API gateway, a reverse proxy, or an application facade, placed in front of the legacy system. As new services get built, the routing layer progressively shifts traffic from legacy code to the new services. To users and downstream systems, it looks like one system the whole time. Internally, it's a controlled handover in three phases: deploy a routing layer that initially passes everything through unchanged; extract bounded contexts one at a time as independent services, shifting traffic for each; then retire the legacy system once it handles less and becomes a thin shell.

One distinction worth being precise about: this routing layer is not the same thing as a Graftcode Gateway, which comes up later in this piece. The Strangler Fig routing layer sits in front of the legacy system and directs traffic to it. A Graftcode Gateway isn't a proxy or a traffic router. It's the runtime that hosts a service and exposes its methods to callers. The two solve different problems at different points in the architecture, and conflating them is a common source of confusion when teams start combining the pattern with typed interface tooling.

The mechanic itself is well understood by now. What separates teams that keep momentum from teams that stall is the decisions around it, which module to extract first, and which supporting pattern to reach for when Strangler Fig alone isn't enough.

Picking a First Extraction Candidate That Will Not Stall

The first extraction sets the tone for every one that follows. A hard first candidate teaches the team that extraction is expensive and slow. A good one builds the muscle memory and tooling that make the next four extractions faster.

A strong first candidate has all five of these properties:

No shared database tables. If a module reads and writes tables other modules also touch, extraction requires resolving data ownership first, which is a separate project on its own.
Synchronous-only callers. Modules called only synchronously with a direct response are simpler to route behind a facade. Async producers or consumers add broker configuration to the scope.
Stateless or externally managed state. A module holding no in-process state, or storing state in Redis or a dedicated database, can scale independently without session affinity concerns.
A narrow interface. A module with three or four public methods can be extracted in days. One with 40 endpoints called from across the codebase needs interface auditing first.
Existing test coverage. Without tests, running legacy and extracted versions in parallel to compare outputs has no baseline to validate against.

Strangler Fig handles the extraction mechanism. It doesn't automatically solve the integration problem, the work of making the extracted service and the legacy system talk to each other cleanly. That's where the choice of supporting pattern comes in.

Three Supporting Patterns Solve Three Different Problems

Strangler Fig rarely works alone in a complex migration. Three supporting patterns each solve a distinct problem that surfaces during extraction. The decision isn't which one is best. It's which problem you actually have.

Branch by Abstraction fits when a module has many internal callers. It introduces an interface layer inside the monolith before extraction begins, so callers talk to an interface rather than a concrete implementation. You can then swap the concrete implementation from legacy code to the extracted service without touching any call sites. This matters most when a module is called from dozens of places within the monolith, where updating every call site individually would be disruptive on its own, independent of the extraction itself.

Parallel Run fits when you need to validate behavioral correctness under real traffic before anyone trusts the new path. Requests get sent to both the legacy system and the new service simultaneously, and outputs get compared before committing. Discrepancies are logged but never affect users, since the legacy response is always what gets returned until the new service proves itself. This pattern earns its cost when a silent regression is expensive: payment processing, order fulfillment, anywhere correctness outweighs speed of rollout. Its usual downside is the extra client needed purely for comparison, a second integration surface that exists only to validate, not to serve production traffic.

Anti-Corruption Layer fits when the legacy domain model shouldn't leak into the new service. It's a translation layer sitting between the legacy system and the new service, converting legacy domain concepts into the new service's domain model. Without it, the new service inherits the legacy system's field names, data shapes, and quirks, and quietly becomes a second legacy system in a new codebase. This matters when the legacy and target domain models genuinely differ: different field semantics, different status representations, different ways of modeling the same concept. When deployed as its own translation service, it typically becomes a cross-language boundary, which is often what makes teams skip building it under timeline pressure.

Common Mistakes That Quietly Compound Integration Cost

Teams that understand the patterns still hit these repeatedly.

Shared database between monolith and extracted service. Teams move the code first and defer data migration to reduce risk, but "later" rarely arrives, and the shared table becomes permanent coupling. A network hop gets added without achieving actual isolation. Use dual-write or change data capture during the transition, then cut over once the new service's data is validated.
Migrating too many modules at once. Org pressure to show progress across teams leads to parallel extraction, and the integration surface multiplies faster than any one team can track. Every active extraction is a partially bridged system that needs maintenance. Extract sequentially instead, completing one before starting the next.
Treating migration bridges as permanent temporary fixes. The team that builds the bridge knows it's meant to be replaced. Six months later, a different team owns it, the "temporary" label is long gone from the commit history, and it's carrying production traffic with no test coverage.

Where Graftcode Changes the Cost of Each Pattern

The three failure patterns above all trace back to the same root cause: the integration layer between what's extracted and what remains. That's where Graftcode changes the calculation: not by changing which pattern is right for a given situation, but by lowering the cost of executing whichever one you pick.

Consider a Python ML inference service being extracted from a Java monolith, the same cross-language scenario that makes the third failure pattern above so common. Without a typed communication layer, the Java side needs a hand-written HTTP client, DTO definitions matching the Python service's schema exactly, and error handling the original in-process call never needed. If the Python team renames a field, that mismatch doesn't fail at compile time. It shows up as a validation error or a silent divergence under real production traffic, with no signal until it happens.

With Graftcode, the calling code looks different:

package orders;

import com.graft.maven.inferenceservice.GraftConfig;
import com.graft.maven.inferenceservice.InferenceService;

public class InferenceCaller {
    static {
        GraftConfig.setConfig(System.getenv("GRAFT_CONFIG"));
    }

    public InferenceResult runInference(String modelId, float[] inputVector) throws Exception {
        // Strongly typed: if Python renames a field, this fails at compile time
        return InferenceService.infer(modelId, inputVector);
    }
}

GraftConfig reads a single GRAFT_CONFIG environment variable at startup, a structured string specifying the Graft's name, target host, runtime, and module path. Local development points to host=inMemory and runs the call in-process with no network hop. Production points to the deployed service's Gateway. The calling code in InferenceCaller never changes between these two states; only the GRAFT_CONFIG value does.

That same mechanism applies across the supporting patterns covered earlier. In Branch by Abstraction, the interface stays exactly what it was; what changes is what sits behind it: a Graft instead of a hand-written client, with the monolith-to-service cutover controlled by GraftConfig rather than a code change. In Parallel Run, the shadow client used purely for comparison becomes a Graft too, so a response shape change during validation surfaces as a reviewable package update instead of a silent mismatch buried in logs. In Anti-Corruption Layer, when the translation layer is deployed as its own service, both integration hops, monolith to ACL, and ACL to new service, become Grafts instead of hand-rolled HTTP clients, removing the doubled integration cost that usually makes teams skip building a standalone ACL under deadline pressure.

None of this changes which pattern fits a given extraction. It changes whether the pattern that fits is actually affordable to execute.

When the Strangler Fig Pattern Is Not the Right Choice

Incremental extraction isn't universally applicable, and it fails or becomes counterproductive in a few specific situations:

Tightly coupled UIs. Server-side-rendered monoliths where the frontend and backend are inseparable are significantly harder to extract with this approach. A micro-frontend decomposition layer is usually the better first move.
Batch-first systems. Systems built around nightly batch processing rather than request-and-response flows don't benefit from facade-based routing, since the pattern assumes real-time traffic that can be progressively redirected.
Broken domain models. If the legacy domain model is conceptually wrong rather than just poorly implemented, incremental extraction perpetuates the bad model. Design the target model first, before any extraction begins.
Small, isolated systems. When a careful rewrite takes weeks, introducing a facade and incremental routing adds overhead the risk reduction doesn't justify.

Where to Start With Your Own Modernization Effort

Legacy modernization rarely fails because a team picked the wrong pattern. Strangler Fig, Branch by Abstraction, Parallel Run, and Anti-Corruption Layer are all well understood and genuinely effective on their own terms. What derails modernization projects is the integration work between what's been extracted and what remains, work that compounds quietly until it consumes more time than the extraction itself was meant to save.

Start by identifying a first extraction candidate against the five properties covered above: no shared tables, synchronous callers, externally managed state, a narrow interface, and existing test coverage. From there, match the extraction's actual problem to the right supporting pattern rather than defaulting to Strangler Fig alone. To see how Graftcode fits into whichever pattern you choose, explore Graftcode or go directly to the Graftcode Academy to get started.

FAQs

1. What is the difference between the Strangler Fig pattern and a big-bang rewrite?

A big-bang rewrite replaces the entire legacy system in one effort, with no incremental value delivery and risk typically measured in years. The Strangler Fig pattern extracts functionality piece by piece while the legacy system stays live, with each extraction independently deployable and reversible.

2. How do you choose between Branch by Abstraction, Parallel Run, and Anti-Corruption Layer for a given extraction?

The choice depends on the specific problem the extraction has. Branch by Abstraction fits when a module has many internal callers. Parallel Run fits when correctness under real traffic is critical. Anti-Corruption Layer fits when the legacy domain model is different enough from the target model that it shouldn't be allowed to leak in. These aren't mutually exclusive within a single extraction.

3. What makes a module a good candidate for the first extraction in a migration?

No shared database tables with other modules, synchronous-only callers, stateless or externally managed state, a narrow interface, and existing test coverage. A candidate missing several of these properties is likely to stall and set the wrong expectations for the extractions that follow.

4. Why do modernization projects usually stall even when the team understands the available patterns?

The pattern itself is rarely the problem. What stalls projects is underestimating the integration cost, the work of bridging an extracted service back to the system it came from, especially across language boundaries where a hand-written HTTP client and DTO layer has to be built and maintained indefinitely.

5. Is replatforming the same thing as legacy modernization?

Replatforming is one approach within legacy modernization, not the whole category. It means moving an existing system to new infrastructure without changing the code, which is lower risk than re-architecting but doesn't address the underlying architectural constraints that usually caused problems in the first place.

6. How long does an incremental modernization effort typically take compared to a full rewrite?

It depends entirely on the number of extractions and their complexity, but the more relevant difference is value delivery. A full rewrite delivers nothing until it ships, often years later. Incremental extraction under the Strangler Fig pattern delivers value continuously, with each extracted service live and useful as soon as it's cut over.

7. What is an Anti-Corruption Layer and when does a team actually need one?

It's a translation layer between a legacy system and a new service that converts legacy domain concepts into the new service's domain model. A team needs one when the legacy and target domain models genuinely diverge, different field semantics or status representations for the same underlying concept, since skipping it lets legacy constraints leak directly into the new codebase.

gRPC vs REST: A Decision Guide for Backend Teams

Justin — Thu, 24 Sep 2026 11:21:09 +0000

TL;DR

REST runs on HTTP/1.1 with JSON and no enforced schema; it's the default for external-facing APIs and interfaces still taking shape. gRPC runs on HTTP/2 with Protobuf and a required contract, built for high-throughput internal services and latency-sensitive workloads like inference pipelines. The real tradeoff is speed and strictness versus universal compatibility, but neither protocol solves the integration maintenance work that piles up as services multiply, work that can eat 30-40% of backend engineering time. This guide breaks down when each protocol fits and what to do about the cost neither one addresses.

Getting Started: What REST and gRPC Actually Are

Every service in a distributed system needs a way to talk to another one, and for most teams, that decision defaults to REST without much thought. It's familiar, it runs over plain HTTP, and any client- a browser, a script, another team's service- can call it without installing anything special first. gRPC is the alternative most teams reach for once performance or contract strictness becomes a real constraint on the system, not just a theoretical concern raised in a design review.

REST is built on HTTP/1.1, the same protocol your browser uses to load a webpage. A service exposes its data as resources at URLs, callers interact using standard HTTP verbs like GET and POST, and data moves back and forth as JSON, plain readable text. Here's what a typical call looks like:

response = await client.post(
    "http://inference-service/api/v1/inference",
    json={"model": "llama-3", "prompt": prompt, "max_tokens": 512}
)
response.raise_for_status()
return response.json()

Any HTTP client can make that call, no generated code, no special tooling, nothing beyond a standard library. That universality is REST's core strength: a new engineer, a third-party partner, or a browser-based frontend can start calling the API immediately.

The tradeoff shows up on the other side of that convenience. Nothing enforces what shape the response has to take, so nothing stops the provider from renaming max_tokens to max_new_tokens in the next release. The calling service doesn't find out until production, usually as a silent null value where a number should be, or a KeyError that surfaces hours after the actual change shipped.

gRPC starts from the opposite direction: it requires a contract before any code gets written.

The contract is a .proto file, which defines every method, field, and data type the service interface will expose.
A compiler called protoc reads that file and generates typed stubs from it, in whatever language the calling service uses.
Once those stubs exist, the calling code calls a generated method as it would any other function in its own codebase, rather than building a request by hand.
If a provider renames a field in the .proto, the generated stub changes to match, and the calling code fails to compile immediately, catching the break before it reaches production.

That's the core tradeoff in practice: REST gives you universal compatibility with a loose, self-enforced contract; gRPC gives you a strict, compiler-enforced contract in exchange for real setup cost on both sides.

Two other differences are worth knowing before the next section gets more technical:

Transport: gRPC runs over HTTP/2 instead of HTTP/1.1, which brings multiplexing, multiple requests traveling over a single connection at once, instead of REST's one-request-per-connection default.
Payload format: gRPC encodes messages as Protobuf, a compact binary format a computer parses quickly but a human can't read directly, instead of the plain JSON text REST uses, which anyone can open and read without special tooling.

How the Two Protocols Differ at a Technical Level

Section 2 covered what each protocol is. This section covers what that difference actually costs or saves once a system is running in production, across four dimensions that matter most day-to-day.

Transport speed under load. HTTP/2 gives gRPC multiplexing, header compression, and persistent connections, none of which HTTP/1.1 offers by default. In practice, that means fewer TCP handshakes and lower per-request overhead. For a single request, the difference is negligible. For a service handling hundreds of concurrent requests, like an inference endpoint under real traffic, that gap becomes measurable in p99 latency.

Payload size on the wire. JSON is verbose by design; every field name gets repeated in every message. Protobuf, gRPC's binary format, strips that repetition out. A typical Protobuf payload runs 3-10x smaller than the equivalent JSON. At low call volumes, that difference doesn't register. At high throughput, agent orchestration loops, inference pipelines, tool execution chains firing dozens of calls per request, it compounds fast.

Contract enforcement. This is the schema question from Section 2, restated in terms of what breaks and when:

With REST, schema enforcement is optional. Teams that want it add OpenAPI specs or contract testing on top, extra tooling that has to be maintained separately from the API itself.
With gRPC, the .proto file is the enforced contract by default. There's no separate tooling to bolt on, the compiler does the enforcement automatically.
The practical difference: a REST contract break surfaces as a runtime bug someone has to trace back to its source. A gRPC contract break surfaces as a compile error, before the code ever ships.

Browser and client compatibility. REST works natively in every browser and every HTTP client without exception. gRPC doesn't, because gRPC depends on HTTP/2 trailers, and the browser fetch API doesn't support them. Getting gRPC to work from a browser requires a proxy layer called gRPC-Web to translate between the two. That's not a minor inconvenience; it's a hard technical constraint, and it's the main reason gRPC stays scoped to internal service-to-service communication for most teams rather than reaching all the way to the frontend.

Put together, the pattern across all four dimensions is consistent: gRPC trades setup cost and reduced compatibility for speed and strictness, REST trades speed and strictness for universal reach and zero setup. Neither wins outright, they're suited to different jobs, which is exactly what the next two sections walk through.

Why REST Is Still the Right Call for External-Facing APIs

REST's biggest advantage isn't speed or elegance, it's that it asks nothing of the caller. Any client that speaks plain HTTP can talk to a REST API without installing anything, generating any code, or agreeing to any contract in advance. That low bar is exactly why REST stays the right default in a specific, fairly consistent set of situations.

Public-facing APIs are the clearest case. A browser, a mobile app, a third-party integration, a CLI tool, any of them can call a REST API over plain HTTP with no stubs to generate and no special setup required first. If the API has consumers outside the team that built it, REST remains the default for good reason, nothing else offers that same zero-friction reach.

Rapidly evolving interfaces favor REST for a different reason. Early-stage products, exploratory internal services, APIs that still change weekly, all of these move faster without a .proto maintenance cycle attached to every change. When the schema itself isn't stable yet, the overhead of formally enforcing it is friction the team doesn't need to carry.

Human-readable debugging is easy to undervalue until it's the thing saving an afternoon. A REST call gone wrong is inspectable immediately in curl, Postman, or browser devtools, no extra step required. A Protobuf payload needs a deserializer and the right .proto file just to make sense of it. For a team onboarding a new engineer, or debugging a cross-service issue under pressure, that difference is felt directly.

REST is the right fit when:

The API has external consumers, browsers, third parties, or mobile clients
The interface is still being shaped and changes frequently
Broad tooling compatibility matters more than raw performance
The team needs fast onboarding and easy debugging over strict guarantees

One caveat worth flagging: REST's lack of enforced schema is manageable at small scale, but the manual discipline required to prevent contract drift grows right alongside the number of services and consumers. Teams that start on REST often end up investing in OpenAPI specs, contract testing, and SDK generation anyway, doing by hand what gRPC would have enforced automatically from day one.

When gRPC Is the Right Call for Internal, High-Throughput Services

Adopting gRPC means paying real setup cost before the first call ever goes out, writing the .proto file, generating stubs, and rerunning that generation step every time the interface changes. That investment pays off in a specific kind of system: one with high call volume, close latency tracking, and a team that controls both ends of the connection.

High-throughput internal services are the primary case. An inference service fielding thousands of requests per minute, a tool execution pipeline inside an agent loop, a feature store queried by several downstream services, these are workloads that actually feel the difference between JSON over HTTP/1.1 and Protobuf over HTTP/2. Smaller payloads, persistent connections, and multiplexing don't matter much at low volume, but they compound fast at scale.

Polyglot service meshes benefit from gRPC's code generation model specifically. When a Python orchestrator, a Go inference service, and a Java data pipeline all need to share one interface, the .proto file generates consistent typed stubs in each language from a single source of truth. No language can silently misinterpret a field another language set, because the contract is generated, not hand-written per language.

Latency-sensitive workloads are where gRPC's HTTP/2 transport shows up most visibly, and a multi-tool agent loop is the clearest current example. Picture an orchestrator calling three services per request: a retrieval service, a code execution service, and a summarization service.

With REST, each service call opens its own connection, one after another:

async with httpx.AsyncClient() as client:
    retrieval = await client.post("http://retrieval-service/retrieve", json={...})
    execution = await client.post("http://execution-service/execute", json={...})
    summary = await client.post("http://summary-service/summarize", json={...})

With gRPC, all three calls run in parallel over persistent HTTP/2 channels instead:

with futures.ThreadPoolExecutor(max_workers=3) as executor:
    r = executor.submit(retrieval_stub.Retrieve, RetrieveRequest(...), timeout=10.0)
    e = executor.submit(execution_stub.Execute, ExecuteRequest(...), timeout=10.0)
    s = executor.submit(summary_stub.Summarize, SummarizeRequest(...), timeout=10.0)

At 20 tool calls in a single agent run, even 5ms saved per hop adds up to 100ms off the total response time. That's not a marginal gain, it's the kind of difference that shows up directly in both user-perceived latency and infrastructure cost at scale.

gRPC is the right fit when:

Services are internal, and the team owns both the client and the server
Call volume is high enough that payload size and connection overhead actually matter
Multiple languages need to share one strict, enforced interface contract
Streaming is part of the design, token streaming, live status updates, bidirectional flows
An agent loop is calling several downstream services in parallel per request

The Integration Maintenance Cost That Accumulates Regardless of Protocol

Picking a protocol answers the transport question. It doesn't answer what happens after that: the ongoing work of keeping every service integration in sync as the system grows. Writing HTTP clients, keeping DTO schemas aligned, and managing stub regeneration, together these can consume 30-40% of backend engineering time, and the cost compounds with every service added.

With REST, every integration means writing and maintaining an HTTP client by hand, wrapping request construction, error handling, and response parsing around each service the team calls.

With gRPC, the stub handles transport automatically, but the .proto maintenance cycle becomes the team's responsibility instead:

# Every time the inference service changes its interface:
protoc --python_out=. --grpc_python_out=. inference.proto
# Commit the regenerated stubs
# Update every calling service that imports them

And here's what interface drift looks like when that step gets skipped. A provider renames max_tokens to max_new_tokens in the .proto. Without regenerating stubs, the calling code fails silently in production. After regenerating, it fails loudly at compile time, TypeError: unexpected keyword, caught before it ever ships.

Both paths land on the same underlying problem: keeping a calling service in sync with its provider is manual work, and that work scales with the number of services in the system, not with how complex any individual integration is.

Where Graftcode Fits In

Section 6 reached the same conclusion for both protocols: neither removes the integration work sitting on top of the transport decision. Graftcode is built to address that layer directly, not by replacing REST or gRPC, but by sitting alongside whatever's already running.

Instead of writing an HTTP client or running protoc, a calling service installs a Graft, a strongly-typed interface generated for that specific provider, through its normal package manager:

pip install --index-url https://grft.dev/your-project-id inference-service@1.0.0
pip install --index-url https://grft.dev/your-project-id retrieval-service@1.0.0
pip install --index-url https://grft.dev/your-project-id summary-service@1.0.0

The three-service agent loop from Section 5, the one that needed either sequential REST calls or a manually parallelized gRPC stub setup, becomes a direct function call to each service:

def run_agent_loop(query: str, prompt: str, text: str) -> dict:
    retrieval = RetrievalService.retrieve(query=query)
    inference = InferenceService.run_inference(model="llama-3", prompt=prompt, max_tokens=512)
    summary = SummaryService.summarize(text=text)
    return {"retrieval": retrieval, "inference": inference, "summary": summary}

No HTTP client, no DTO, no stub regeneration step. If a provider changes its interface, the change surfaces as a package update, caught at compile time rather than at runtime, the same protection gRPC offers, without the .proto cycle REST and gRPC both require the team to maintain by hand.

The routing itself is controlled by GraftConfig, which lives inside the calling service, not in a separate gateway or sidecar. It decides whether a given call runs in-process, never leaving the calling service at all, or as a remote call to the deployed provider, and that choice is set through an environment variable, a config file, or directly on the Graft itself. Switching a service from local development to a remote deployed dependency doesn't require touching application code.

On performance, Graftcode's own Performance Lab ran a large-payload test, 5,000 data points per call, all three approaches on the same .NET runtime over HTTP/2, network latency excluded. Graftcode completed in 22ms, gRPC unary calls in 53ms, and REST in 1,245ms, putting Graftcode 98.2% faster than REST on that workload with a fraction of the CPU overhead. According to Graftcode, removing the HTTP client and stub layer entirely also reduces token usage for AI coding assistants by 30-60% on integration-heavy services, since there's no protocol boilerplate left for the assistant to parse and hold in context.

Worth being direct about the constraint: Graftcode is still in Alpha, and primitive wrapper types like Date, Guid, and TimeSpan aren't supported yet, they need to be passed as string or int instead. That's the kind of limitation worth checking against current documentation before it factors into an adoption decision.

A Practical Decision Framework for Backend Teams

Protocol decisions rarely happen in isolation. They depend on who's calling the API, how much the interface is still changing, and what the team can realistically keep maintained. Three scenarios cover most real cases:

A SaaS platform with a public API and third-party integrations should default to REST. Browsers and third-party clients need zero setup to start consuming it, and that reach outweighs whatever performance gain switching protocols might offer.

An ML inference service called by several internal services fits gRPC well. The interface is stable, call volume is high, latency is tracked closely, and the team controls both ends of the connection, which is exactly the profile Section 5 laid out. The .proto maintenance cost is worth paying for the strict contract and Protobuf's performance at scale.

A microservices team with a steadily growing number of internal services is often looking at the wrong variable. If meaningful sprint time is going to integration code, HTTP clients, DTO sync, stub regeneration, the protocol choice isn't the actual bottleneck. This is the scenario Sections 6 and 7 speak to directly: the Performance Lab benchmark from Section 7 puts real numbers behind it, Graftcode at 22ms against gRPC's 53ms and REST's 1,245ms on the same workload. At 200k RPS on Azure Standard_D16s_v5, Graftcode's own estimate puts that gap at roughly \$1.64B in annual compute savings, a figure worth verifying against current published data before repeating it as settled fact.

The signals that point toward each option, side by side:

Consumers: external and browser-facing points to REST, internal-only points to gRPC or Graftcode
Schema stability: still evolving points to REST, stable and enforced points to gRPC or Graftcode
Call volume: moderate points to REST, high-throughput points to gRPC, very high with minimal CPU overhead points to Graftcode
Languages involved: single language or standard HTTP clients points to REST, polyglot with generated stubs points to gRPC, polyglot with no stubs needed points to Graftcode
Integration overhead: manageable points to REST, growing with service count points to gRPC, already consuming real team time points to Graftcode

Where Should You Start

Choosing between REST and gRPC comes down to who's calling the API and how much performance and contract strictness actually matter for that specific service, REST for external-facing APIs and evolving interfaces, gRPC for internal, high-throughput systems where the team controls both ends. But that choice only answers the transport question. The integration maintenance work sitting on top of it, hand-written HTTP clients, DTO sync, stub regeneration, accumulates regardless of which protocol a team picks, and it's the cost that keeps growing quietly while the protocol debate gets all the attention.

For teams where that integration overhead is already visible in sprint velocity, Graftcode addresses that layer directly without requiring a rip-and-replace of what's already running. It installs alongside existing REST or gRPC services, one service boundary at a time, with compile-time contract enforcement and routing controlled through GraftConfig rather than hand-maintained client code. Full technical detail and the Performance Lab benchmarks are at graftcode.com, and the monolith-to-microservices use case is worth a look for teams currently mid-migration.

FAQs

1. Can gRPC and REST coexist in the same microservices architecture?

Yes, and most production systems already do this. External-facing APIs stay on REST for broad client compatibility, while internal service-to-service communication moves to gRPC for performance and contract enforcement. An API gateway at the edge typically handles the translation between the two.

2. What's the actual performance difference between REST and gRPC at high call volumes?

At low volumes, the gap is small enough to ignore. At high throughput, thousands of requests per second, Protobuf's binary encoding and HTTP/2's multiplexing produce measurable latency and CPU differences, with gRPC benchmarks consistently showing lower p99 latency under load, particularly for the small, frequent payloads typical of internal service calls.

3. Is gRPC a realistic option for browser-based frontend applications?

Not natively. Browsers don't support the HTTP/2 trailers gRPC depends on, so reaching a browser requires a proxy layer called gRPC-Web to translate between the two. For most teams, that added infrastructure makes REST the practical default for anything browser-facing, with gRPC scoped to internal communication.

4. How does Graftcode handle routing compared to gRPC's service discovery?

GraftConfig, which lives inside the calling service, controls where a remote call goes and points to the Graftcode Gateway running for that provider service. Load balancing itself still sits at the infrastructure layer, the same Kubernetes service or load balancer a gRPC or REST deployment would use, since Graftcode replaces the integration code layer, not the infrastructure underneath it.

5. Can Graftcode be adopted alongside an existing REST or gRPC service during a migration?

Yes, this is one of the more common ways teams bring it in. A team can extract one service, run its Graftcode Gateway for that service, and set the calling code to run in-process locally while routing remotely in staging and production, without changing the application code. Existing REST or gRPC services keep running unchanged elsewhere in the system.

Agencies that market to software engineers and developers

Justin — Mon, 16 Mar 2026 10:07:10 +0000

Sure you must have heard how marketing to developers is notoriously difficult. Not because developers are impossible to reach — but because they ignore most marketing.

Engineers care about:

solving problems
learning new tools
seeing working examples

This means developer marketing looks very different from typical SaaS marketing.

Instead of ads and slogans, you usually need:

tutorials
documentation
architecture guides
open-source examples
deep technical blogs

Over the past few years, a handful of agencies have emerged that specialize in this space.

Here are a few worth knowing.

Infrasity

Infrasity focuses on developer infrastructure companies and SaaS platforms.

Their work tends to revolve around:

developer tutorials
technical blogs
integration guides
DevOps and infrastructure topics

What makes them interesting is that much of the content is written by engineers, which helps avoid the “marketing fluff” problem that developers hate.

Draft.dev

Draft.dev connects companies with developer writers.

They produce technical articles covering topics like:

programming languages
APIs
cloud infrastructure
security

Many devtool startups use them to scale technical blog production.

Animalz

Animalz is well known in the SaaS world for high-quality long-form content.

They’re not specifically developer-focused, but they’ve worked with many technical companies and understand complex SaaS products.

Omniscient Digital

Omniscient focuses heavily on SEO-driven content strategy.

For developer products targeting search traffic around tutorials or comparisons, this approach can work well.

Developer relations consultancies

Some companies also partner with DevRel-focused agencies, which handle:

community engagement
developer programs
conferences
technical advocacy

This can complement content-focused marketing efforts.

Final thoughts

The best developer marketing rarely feels like marketing. It looks more like:

documentation
tutorials
engineering blog posts
open-source examples

Agencies that understand this difference tend to produce the content developers actually trust.