Hey folks, curious about the subgraph architecture in your company. Do you use the subgraph as a standalone proxy service, or is it colocated with the actual backend service so that the resolver calls the underlying function directly?
Proxy service: client → router → subgraph → (network call) → backend
Service colocation: client → router → subgraph →(direct function binding)→ backend
What are the pros and cons?
In my experience with **subgraph architecture**, both patterns have pros and cons, but it usually comes down to **team boundaries vs. latency**.
If you run the subgraph as a “proxy,” it’s easier to enforce strict API contracts and keep teams separate. Frontends don’t care how the backend works, you can version them separately, and caching is easier. It’s clear that the downside is that every resolver adds a network hop, which means that latency builds up if you’re combining a lot of data. Debugging distributed calls can also be hard.
If you put the subgraph next to the service, you get very little latency because resolvers call functions directly. You can also use in-process data access patterns. The problem is that you start to tightly couple the schema to the lifecycle of that service. When you deploy one, it affects the other, which can make it less flexible for client-driven evolution. It gets harder to version.
So I usually use both colocate and proxy. I colocate for high-performance, critical services where latency matters, and I proxy for composed or cross-team services where stability and decoupling are more important. The choice of subgraph should be based on the **team structure, SLA needs, and expected traffic patterns**.