Hybrid API Strategy: REST Public, GraphQL Internal - The 2026 Pattern

General
1

The “GraphQL vs REST” debate has been going strong for years, but here’s what I’ve learned as a CTO: the question itself was wrong. The real question isn’t which one to use - it’s where to use each one.

At my company, we spent 18 months evolving our API strategy, and we landed on what I’m calling the “hybrid pattern” - and we’re not alone. According to recent industry data, 55% of teams using a mixed approach report faster time-to-value, and 62% report easier long-term maintenance than single-paradigm shops.

Our Architecture Today

External APIs (REST):

  • Partner integrations
  • Third-party developer platform
  • B2B data feeds
  • Webhook endpoints

Internal APIs (GraphQL):

  • Mobile app BFF (Backend-for-Frontend) layer
  • Internal dashboard
  • Cross-team data aggregation
  • Complex UI data requirements

Why REST for External?

When we opened our API to partners, we had a choice. GraphQL offers flexibility, but REST offered something more valuable for external consumers: familiarity and simplicity.

Our partners are banks, insurance companies, and enterprise software vendors. Their integration teams know REST. They have existing tooling for REST. Asking them to learn GraphQL would add friction to every partnership negotiation.

Plus, REST’s constraints work in our favor externally:

  • Clear versioning: /v1/, /v2/ paths make deprecation explicit
  • HTTP caching: CDNs and proxies just work
  • Documentation: OpenAPI/Swagger is the industry standard
  • Security: Well-understood authentication patterns

Why GraphQL for Internal?

Internally, it’s a different story. Our mobile team was making 5-6 REST calls per screen load. Our web dashboard was over-fetching data everywhere. Our internal tools team was constantly asking backend teams for new endpoints.

GraphQL solved all of this:

  • Mobile gets exactly the data needed in one request
  • Frontend teams iterate without waiting for backend changes
  • The BFF pattern gives each client type its own tailored interface
  • Schema serves as living documentation

Companies like Netflix, Expedia, and Volvo have adopted similar patterns - using GraphQL Federation to create a unified query layer over their REST microservices. This gives internal teams the flexibility they need while maintaining the stability of their underlying services.

The API Gateway: The Glue

The key to making this work is a well-designed API gateway. Ours:

  • Routes external traffic to REST services
  • Handles authentication and rate limiting uniformly
  • Exposes GraphQL to internal clients
  • Provides a single point for observability
  • Manages the translation when GraphQL needs REST backend data

This isn’t just “use both” - it’s intentional architectural separation based on consumer needs.

Results After 18 Months

  • 28-40% faster UI feature delivery (our mobile team’s estimate)
  • Partner integration time cut by 30% (familiar REST patterns)
  • Internal developer satisfaction scores up significantly
  • Reduced coordination overhead between frontend and backend teams

The Trade-offs

Nothing is free. Our hybrid approach means:

  • Two sets of API documentation to maintain
  • Training needed for both paradigms
  • More complex testing infrastructure
  • The gateway becomes a critical dependency

But for a company at our scale (50 to 120 engineers), the benefits have outweighed the costs decisively.

I’m curious how others are thinking about this:

  • Do you run hybrid, or have you standardized on one approach?
  • If hybrid, where do you draw the line between REST and GraphQL?
  • How do you handle the governance and documentation overhead?

The “one API to rule them all” mentality served us poorly. The right tool for the right job has served us well.

2

This resonates deeply with our experience at a Fortune 500 financial services company. We’ve been on a similar journey, and I think the regulated industry perspective adds another dimension to why hybrid makes sense.

The Regulatory Reality

In financial services, our external APIs aren’t just about partner convenience - they’re about compliance and auditability. REST’s explicit structure maps naturally to our regulatory requirements:

  • Every endpoint has documented behavior that auditors can review
  • Request/response patterns are deterministic and testable
  • Versioning is explicit - we can prove which API version was in production at any given time
  • Standard HTTP semantics mean our API Gateway logs tell a complete story

GraphQL’s flexibility is fantastic for internal use, but it would give our compliance team nightmares if exposed to external partners. “The client can query any combination of fields” is the opposite of what regulators want to hear.

Our Federation Journey

We adopted Apollo Federation about two years ago for our internal APIs. The pattern Michelle describes - GraphQL as a query layer over REST microservices - is exactly what we implemented.

Each domain team (payments, accounts, compliance, etc.) maintains their own REST services. The GraphQL layer federates across them, giving our internal tools and dashboards a unified interface. The key insight: the underlying services don’t need to know GraphQL exists. They just expose REST endpoints, and the federation layer handles the composition.

The Governance Question

Michelle asked about governance overhead. Here’s what we learned:

  1. Schema registry is non-negotiable - We use a central schema registry where all GraphQL types are versioned. Breaking changes get flagged before they hit production.

  2. Different documentation tools - REST uses OpenAPI, GraphQL uses its built-in introspection. We accepted that we’d have two systems and invested in making both excellent rather than trying to unify.

  3. Clear ownership boundaries - External REST APIs are owned by the platform team. Internal GraphQL schemas are owned by domain teams but reviewed by a lightweight architecture council.

The overhead is real, but it’s manageable with the right tooling and process.

When Take-Home Tests Applied

@cto_michelle - one thing I’d add: for hiring, we’ve found that candidates who understand when NOT to use GraphQL are often stronger than those who evangelize it for everything. The hybrid pattern requires nuanced thinking, and interview discussions about API architecture reveal that nuance quickly.

3

As a mobile engineering lead, I have to say: mobile teams are the biggest beneficiaries of the hybrid pattern, and we’re often the ones pushing hardest for GraphQL internally.

The Before Picture

Let me paint the picture of what mobile development looked like before we adopted GraphQL internally at Uber. For a typical “driver home screen” in one of our apps:

  • REST call 1: Get driver profile
  • REST call 2: Get current earnings
  • REST call 3: Get upcoming ride requests
  • REST call 4: Get promotions/bonuses
  • REST call 5: Get rating summary
  • REST call 6: Get notification count

That’s 6 round trips just to render one screen. Each with its own latency, each returning data we might not even display (over-fetching), and each requiring the mobile team to coordinate with different backend teams.

For users in emerging markets - Brazil, India, Indonesia - where network conditions are inconsistent, this was brutal on performance and battery life.

The After Picture

With our internal GraphQL BFF layer:

query DriverHomeScreen {
  me {
    name
    photoUrl
    rating { score recentReviews }
  }
  earnings { today thisWeek }
  promotions(active: true) { title bonus }
  notifications { unreadCount }
}

One request. Exactly the data we need. Nothing more.

The results were dramatic:

  • Screen load time reduced by 40% in São Paulo
  • Data transfer cut by 60% (no over-fetching)
  • Battery impact reduced (fewer radio wake-ups)

Why REST Still Makes Sense Externally

But here’s the thing - I totally agree with keeping REST for external partners. Our driver API partners (fleet management companies, third-party apps) need:

  • Predictable response shapes they can build against
  • Standard HTTP caching their infrastructure already supports
  • Documentation their teams can read without learning a new paradigm

When we tried to offer GraphQL to some external partners, the feedback was clear: “Just give us REST endpoints with the specific data we need.” They didn’t want the flexibility - they wanted stability and simplicity.

The BFF Pattern in Practice

At Uber, we run separate BFF services for:

  • Rider iOS/Android - optimized for rider flows
  • Driver iOS/Android - optimized for driver workflows
  • Eats customer app - optimized for restaurant/menu data
  • Web dashboards - optimized for admin operations

Each BFF exposes GraphQL to its specific client type and handles the orchestration of underlying REST services. The clients never talk directly to microservices - they talk to their dedicated BFF.

This separation means the iOS team can evolve their queries without affecting Android, and neither affects the web dashboard. Each frontend team owns their BFF schema.

The Bandwidth Reality

For anyone building for emerging markets: GraphQL’s “ask for exactly what you need” model is not a nice-to-have. It’s essential.

In bandwidth-constrained environments, every kilobyte matters. REST’s over-fetching problem (sending you 50 fields when you display 5) is a real performance tax. GraphQL lets mobile teams be surgically precise about data needs.

The hybrid pattern gives us the best of both worlds - external stability and internal agility.

4

Great discussion so far. Let me add the infrastructure and operations perspective, because the hybrid pattern has some non-obvious implications for the platform team.

The Caching Story

This is where REST has a clear operational advantage, and it’s worth understanding why.

REST caching:

  • HTTP caching just works - CDNs, proxies, browser cache all understand Cache-Control headers
  • Each endpoint has a predictable cache key (URL + method + headers)
  • Cache invalidation is straightforward - you know exactly which resources changed

GraphQL caching:

  • HTTP caching doesn’t apply cleanly - POST requests to a single endpoint
  • You need application-level caching (Apollo Client, Relay, etc.)
  • Server-side caching requires parsing queries to understand what data is being requested
  • Cache invalidation becomes complex when queries span multiple entities

For external APIs where partners might hit the same endpoints millions of times, REST’s HTTP caching can reduce your infrastructure costs dramatically. A well-cached REST API might serve 90% of requests from CDN edge nodes.

Rate Limiting Complexity

With REST:

Rate limit: 1000 requests/minute per endpoint
Cost: Each request = 1 unit

With GraphQL:

Rate limit: ???
Cost: Depends on query complexity, depth, field selection...

We’ve had to implement query cost analysis to fairly rate-limit GraphQL. A simple query might cost 1 unit, but a deeply nested query hitting 10 services might cost 50 units. This is solvable, but it’s additional infrastructure that REST doesn’t require.

Observability Differences

REST observability is mature:

  • Standard access logs show endpoint, method, response time, status code
  • APM tools automatically instrument REST endpoints
  • Error tracking is straightforward - each endpoint has clear success/failure states

GraphQL observability requires more work:

  • A single endpoint handles all queries - you need to instrument at the resolver level
  • Partial failures are common (some fields succeed, others fail)
  • You need specialized tooling (Apollo Studio, etc.) to understand query patterns

Not insurmountable, but teams often underestimate the observability investment required for GraphQL.

The API Gateway as Single Point of Truth

@cto_michelle mentioned the API gateway, and I want to emphasize how critical this is. In a hybrid setup, your gateway needs to:

  1. Route by consumer type - External traffic → REST, internal traffic → GraphQL
  2. Unify authentication - Both protocols should use the same auth tokens/patterns
  3. Aggregate metrics - Single dashboard showing health across both API styles
  4. Handle protocol translation - When your GraphQL layer needs to call REST services

We use Kong with custom plugins, but AWS API Gateway, Apigee, and Apollo Router are all options. The key is treating the gateway as a first-class service with its own team and SLAs, not an afterthought.

My Recommendation for Teams Starting Fresh

If I were advising a team building from scratch in 2026:

  1. Default to REST for public/partner APIs - Familiarity, caching, tooling maturity
  2. Evaluate GraphQL for internal BFF - But only if you have:
    • Complex, nested data requirements
    • Multiple client types with different data needs
    • Frontend teams blocked waiting for backend changes
  3. Invest in gateway infrastructure early - Don’t bolt it on later
  4. Plan for dual documentation - Accept this overhead upfront

The hybrid pattern isn’t free, but for the right use cases, it’s the pragmatic choice.