Orbital

Compare

OrbitalvsGraphQL

GraphQL unifies an application API. Orbital connects the systems, streams and data products behind the enterprise.

Both can compose data for request/response APIs, and for that job GraphQL is excellent - it was designed for exactly it, the tooling is mature, and a great many teams should keep using it.

Orbital solves a wider problem: a semantic execution layer across APIs, databases, event streams and batch workloads, where the systems are heterogeneous, the teams are independent, and the contracts keep moving.

This page is about where the two overlap and where they do not. If you are replacing an integration platform rather than drawing a boundary, the MuleSoft comparison is the more useful one.

See where they overlapUse both together

GraphQL

Clients query one composed schema, which resolves against the services behind it.

Orbital

Applications, agents, streams and batch jobs query one model of meaning across the estate.

Two correct pictures of two different scopes. The graph composes an API for clients; the semantic layer composes meaning across an estate - and an existing GraphQL API is one of the consumers it can sit behind.

Scope

Different tools, different scopes

These overlap in one place and diverge everywhere else. The third card is not a courtesy - keeping an existing graph is usually the right answer.

Architecture

Where the two actually differ

It is worth separating the GraphQL specification from the ecosystem around it. The specification defines queries and mutations as stateless and subscriptions as stateful; durable event processing, change data capture, ETL and cross-protocol integration are normally supplied by other systems.

Almost anything can be built around the protocol given resolvers, middleware or a gateway. The useful question is not whether it is possible but what it takes - which is what these four dimensions are about.

Who is asking, and how much say do they get over the shape of the answer?

Orbital

A schema declared per consumer

A consumer describes the model it wants back - its own field names, its own structure, its own format - and Orbital maps the estate onto it.

Two consumers can hold genuinely different models of the same data, in different serialisation formats, without either being canonical.

GraphQL

Fields selected from a shared schema

A client selects the fields it needs from the schema the graph publishes, which is exactly the over-fetching problem GraphQL was built to fix, and it fixes it cleanly.

The shape available is the shape the composed schema defines. Serving a consumer a different model means adding it to that schema or transforming outside the graph.

Compare by workload

The same job, done both ways

Three workloads, compared as work rather than as capabilities. The first is a deliberately close comparison and Orbital does not win it.

The requirement

A web and a mobile client need one typed endpoint that composes customer, order and product data from three services, without over-fetching.

Systems involved

  • Customers API
  • Orders API
  • Products API
  • Two clients
What you build

Orbital

Semantic types on the three specifications, and a query per consumer describing the response it wants.

GraphQL

A schema for the composed graph and resolvers for each field, or a subgraph per service with a composition step over them.
Effort

Orbital

Low. This is well inside what Orbital is for, and there is nothing clever about it.

GraphQL

Low. This is the problem GraphQL was designed for, and the tooling, tracing and client libraries around it are excellent.
Honest assessment

Orbital

No meaningful advantage. If this is the whole of the requirement, the deciding factors are your team’s existing skills and tooling - not this page.

GraphQL

A very good fit. A team already fluent in GraphQL should expect to move faster here than with anything they have to learn first.

The decision

Three questions that settle it

Technologies, consumers and teams. Answer these three honestly about your own estate and the rest of this page is confirmation.

  1. How many technologies are involved?

    The single best predictor of which side of the line you are on. Count the things that are not HTTP services.

    Orbital

    Read natively

    API descriptions, Protobuf and Avro schemas, database schemas and streaming sources are all first-class inputs. Adding one is describing what its fields mean.

    GraphQL

    Reached through resolvers

    Anything can be brought into a graph, and connector tooling has made much of it declarative. It is still an integration somebody owns and maintains in front of each system.

  2. How many consumers are involved?

    One consumer, or five with genuinely different models and formats? The answer changes what "the schema" even means.

    Orbital

    A model per consumer

    Each consumer declares the model and format it wants - JSON, CSV, Avro, Protobuf - and none of them is canonical. Nothing has to agree with anything else.

    GraphQL

    Fields from one composed schema

    Clients select what they need from a shared schema, which is precisely the right answer when they are all applications. It becomes a constraint when they are not.

  3. How many teams are involved?

    Independent ownership is where the difference is most often misstated. Federation is a real answer to it - the question is what it asks of everyone.

    Orbital

    Contracts that never have to merge

    Domains publish and evolve their own contracts. The agreement between them is about what fields mean, not about how their schemas fit together.

    GraphQL

    Subgraphs that have to compose

    Federation supports independently defined subgraphs. Composition is the shared obligation: conflicting definitions can prevent a supergraph from being composed.

Coexistence

Use Orbital and GraphQL

Adopting Orbital does not mean removing a GraphQL API you already have, and in most estates it should not. The two arrangements below are both common, and the first is the more common by a distance.

Orbital behind the graph

The graph stays the application-facing contract; its resolvers stop being an integration layer.

Orbital in front of the graph

New consumers the graph was never meant to serve read the estate - including the graph itself.

  1. 1

    Keep the graph

    It stays the application-facing contract. Web and mobile clients are not touched, and nothing about the schema they query changes.

  2. 2

    Model behind it

    Describe what the systems the resolvers call actually mean, in Taxi. This is additive: the resolvers keep working while it happens.

  3. 3

    Move the integration

    Resolvers that fan out across six services ask Orbital once instead. The graph gets simpler; its contract does not change.

  4. 4

    Serve what the graph does not

    Streams, batch, agents and non-JSON consumers come off the same model - without adding any of them to the composed schema.

Talk through a coexistence plan

Decision guide

When each one is the right answer

There is a large set of problems where GraphQL is the better choice and this page would be wrong to pretend otherwise.

  • Choose GraphQL when…

    • The primary problem is a typed API for application clients, and over-fetching is the thing you are solving.
    • Most of the integration logic already sits behind resolvers or subgraphs and is working.
    • A composed graph is the contract you want teams to agree on, and federation is doing that job well.
    • Your team is fluent in the ecosystem - the tooling, tracing and client libraries are a real advantage and they are not free to replace.

  • Choose Orbital when…

    • The problem spans protocols and systems: databases, queues, gRPC, files and third-party APIs, not just HTTP services.
    • Streaming, batch, change data capture or cross-system actions are first-class requirements rather than edges.
    • Consumers need different models and formats of the same data, and some of them are not JSON.
    • Independent teams need to evolve contracts without a composition step that everyone has to stay compatible with.

  • Use both when…

    • GraphQL is already the application-facing API and there is no reason to change what clients query.
    • The resolvers behind it have quietly become an integration layer nobody set out to build.
    • New consumers - agents, streams, partner feeds - need the same data in shapes the graph was never meant to serve.
    • Existing GraphQL investment should stay intact, which is usually the right call.

Detailed comparison

The distinctions that matter

Four states rather than two, because on this page a yes/no answer would nearly always be the wrong one: almost anything can be built around GraphQL, and what a reader needs to know is what it would take.

  • NativePart of the runtime. Nothing else to stand up.
  • SupportedA first-class capability, configured rather than built.
  • Requires extensionAchievable with additional code, tooling or infrastructure.
  • Not the intended useOutside what the technology set out to solve.

Primary purpose

What the technology is for
Native· OrbitalA semantic execution layer across an estate of heterogeneous systems.
Native· GraphQLA typed, client-driven API for application clients, without over-fetching.
Composing data for a request/response API
Native· OrbitalA query describing the response, planned across whatever holds the data.
Native· GraphQLThe problem it was designed for, with a mature ecosystem behind it.

Query and consumer model

Who defines the response shape
Native· OrbitalThe consumer, in its own query, using its own field names and structure.
Supported· GraphQLThe client, by selecting fields from the schema the graph publishes.
Consumer-specific semantic modelTwo consumers holding genuinely different models of the same data.
Native· OrbitalEach consumer declares its own model. None of them is canonical.
Requires extension· GraphQLThe composed schema is the shared model; a different one is transformed outside the graph.
Output formats other than JSONCSV, Avro, Protobuf, XML.
Native· OrbitalA query’s output format is declared with its shape.
Requires extension· GraphQLGraphQL responses are JSON; other formats are produced by a layer around the API.

Source protocols

REST and OpenAPI
Native· OrbitalThe specification is read directly; semantic types are annotations on it.
Supported· GraphQLReached through resolvers, or declaratively through connector tooling.
Databases
Native· OrbitalSchemas are read and queried as a source like any other.
Requires extension· GraphQLReached through resolvers, an ORM or a database-backed subgraph somebody owns.
Protobuf, Avro and gRPC
Native· OrbitalSchemas are first-class inputs to the model.
Requires extension· GraphQLBridged into the graph by generated or hand-written resolvers.
An existing GraphQL API
Supported· OrbitalConsumed as one more source, which is what makes coexistence straightforward.
Native· GraphQLA subgraph, composed into the supergraph.

Workloads

Request and response
Native· OrbitalA query, published as an endpoint.
Native· GraphQLQueries and mutations, defined by the specification as stateless.
Live push to a connected client
Native· OrbitalA streaming query published over a websocket.
Native· GraphQLSubscriptions, which the specification defines as stateful.
Durable event streaming and CDCReplayable, at-least-once, consumer groups.
Native· OrbitalA streaming query reads a topic, enriches each event and republishes it.
Not the intended use· GraphQLSupplied by a streaming platform. Subscriptions are a live channel, not a durable pipeline.
Batch and ETL
Native· OrbitalA query reading from object storage, a database or an upload, writing wherever it belongs.
Not the intended use· GraphQLOutside what the protocol set out to solve; handled by separate pipeline tooling.

Keep the graph. Move the integration behind it.

Bring one resolver that fans out across half a dozen services. We will model what it reaches and show you what is left of it.

Start for freeTalk to us

Other comparisons