GraphQL implementation for Australian businesses
GraphQL cuts endpoint sprawl for multi-client integrations, but adds schema governance work REST doesn't need. Here's when it pays off.
National Digital designs, builds, hosts and supports the platforms it delivers, with no reseller or integrator between the client and its engineers.
Written by Tara Buckley, COO · Reviewed by Cameron Young, CEO on
- API development and management
- Platform engineering
- Legacy system modernisation
Quick answer:GraphQL consolidates multiple REST endpoints into one typed schema, useful when several front-ends query the same backend, but it adds schema governance work REST avoids.
Quick answer
What does GraphQL implementation actually solve for a business running several connected systems?
GraphQL consolidates multiple REST endpoints into one typed schema, letting a website, app and partner system each query exactly the fields they need from shared backend data.
Additional Context
It's most valuable when several independent client applications need overlapping but non-identical data from the same systems, not as a general replacement for REST.
Sources
- Australian Government API Design Standard
Guidance maintained by the Digital Transformation Agency on designing consistent, well-governed APIs for government and industry integration work.
- Digital Transformation Agency
Australian Government agency responsible for digital service and API standards applied across government and partner integrations.
API Integration Patterns
What GraphQL actually changes for integration work
GraphQL is a query language and runtime for APIs, built so a client can ask for exactly the fields it needs in a single request. A mobile app, a web dashboard and a partner portal can each query the same backend schema and get back different shapes of data, without three separate sets of REST endpoints maintained in parallel. For a business running Shopify on the front end, a custom order system behind it and a logistics partner needing status updates, that single schema becomes the contract everyone builds against.
The practical effect shows up in custom API development work: teams stop writing a bespoke REST endpoint every time a new screen needs a slightly different combination of fields. Instead of separate order, summary and detail endpoints, there's one orders type and each client asks for what it needs. That matters more as the number of consuming applications grows past two or three, which is usually the point a business first notices REST endpoint sprawl.
When GraphQL earns its complexity
GraphQL is not free. It needs a resolver layer, a schema someone owns and keeps coherent, and query depth limits to stop a client requesting a response that fans out across a dozen downstream calls. A business integrating two systems with a stable, well-understood data shape rarely needs it; a well-documented API built to the sort of REST API versioning and security standards most integration work already follows does the job with less operational overhead. GraphQL earns its place when several independent front ends query overlapping but not identical data from the same backend, or when a legacy system needs a single modern interface in front of several older services with inconsistent field names and formats.
Questions buyers ask
Should a partner-facing API use GraphQL or REST?
The choice turns on who controls the shape of a response. With GraphQL the partner picks the fields in each query, so the schema becomes a public contract that you must version carefully. With REST you decide the shape of each response and the partner takes what you return. A business can run both, with GraphQL layered over the services that REST already exposes.
API & Integration Strategy
Untangling REST Endpoint Sprawl with GraphQL
Problem
Businesses running several client applications, such as a website, a mobile app and a partner API, against the same backend often end up maintaining a growing set of REST endpoints, each shaped for one consumer, that duplicate logic and drift out of sync as requirements change.
Common Pain Points
- Endpoint duplication Each new client application spawns its own REST endpoint shaped to its exact needs.
- Caching assumptions break Standard HTTP caching stops working cleanly once queries become flexible and field-specific.
- Repeated resolver calls Poorly designed resolvers can trigger dozens of downstream calls per query under real load.
Business Impact
- Time Wasted Developer time spent building near-duplicate endpoints for each new client view
- Cost Implication Cost grows with every additional client integration rather than with actual business volume
- Opportunity Cost New integration requests queue behind endpoint maintenance instead of new feature work
Solution
A GraphQL layer placed in front of existing systems gives every client one schema to query, replacing growing REST endpoint sprawl with a single, governed contract each team builds against.
Our Approach
- Map the real query patterns (Early discovery phase)Identify which client applications query which data and where field requirements overlap, rather than guessing at schema shape upfront.
- Build the schema against core data first (Initial build phase)Stand up GraphQL resolvers for the two or three systems causing the most endpoint duplication, leaving stable REST integrations untouched.
- Add governance before scaling consumers (Pre-scale phase)Set schema ownership, deprecation rules and query complexity limits before adding more client applications to the schema.
Expected Outcome
Fewer duplicate endpoints to maintain and one governed schema that new client applications can query without a bespoke REST build.
Key Takeaways
What to weigh before building a GraphQL layer
- GraphQL mainly fixes consumer-side data shaping across multiple client appsImportant
It is most valuable when several independent front ends query overlapping data from the same systems, not as a general API upgrade applied everywhere.
- REST still wins for simple, stable system-to-system linksImportant
A single integration syncing one system to another, like an accounting feed, rarely benefits enough to justify GraphQL's extra resolver and governance layer.
- Repeated resolver queries catch most first-time GraphQL buildsCritical
Resolvers that call downstream services per field can multiply into dozens of calls per request unless batching is designed in from the start.
- A GraphQL layer works best placed in front of existing systemsImportant
Building the schema against legacy or disparate systems without replacing them keeps the project staged and avoids a disruptive rebuild.
GraphQL earns its complexity when multiple client applications need overlapping data from shared backends. A staged schema layered over existing systems, with governance built in early, avoids the sprawl it's meant to fix.
Where GraphQL Changes the Integration Picture
These points describe structural differences between GraphQL and REST integration patterns relevant to businesses running several client applications against shared backend systems.
Single schema
Endpoint consolidation
Significance: highA GraphQL implementation typically replaces multiple purpose-built REST endpoints with one schema that every client queries differently, reducing duplicate server-side logic.
Source: Australian Government API Design Standard, api.gov.au
Native subscriptions
Real-time update handling
Significance: mediumGraphQL subscriptions provide a standard, documented mechanism for push-based updates, where REST integrations usually require a bolted-on websocket or polling layer instead.
Source: GraphQL specification, GraphQL Foundation
Single contract
Schema governance need
Significance: highA GraphQL schema functions as a shared contract between every consuming team, which raises the governance bar compared with independently versioned REST endpoints.
Source: Australian Government API Design Standard, api.gov.au
Methodology
Drawn from published API design guidance and GraphQL specification documentation rather than a single benchmark study, reflecting structural patterns rather than measured outcomes.
GraphQL in Practice
GraphQL versus REST: the practical trade-off
The comparison that matters is not which technology is newer. It is which one matches the shape of the integration problem. REST maps cleanly to HTTP caching, is simple to secure with standard OAuth 2.0 client credentials flows, and is the right default for a straightforward system-to-system integration like syncing Xero invoices into a reporting tool. GraphQL trades that caching simplicity for flexibility: because every request can ask for a different combination of fields, a CDN can't cache a GraphQL response the way it caches a REST GET. Teams moving from REST to GraphQL for the first time are usually surprised by the repeated-query problem, where a single GraphQL query that looks simple on the client side triggers dozens of resolver calls to underlying services if the schema wasn't designed with batching in mind. It is one of the more common reasons a GraphQL pilot performs well in testing and then slows noticeably once real production traffic hits it.
A staged path into GraphQL without a rewrite
The lower-risk pattern for an established business is to put a GraphQL layer in front of existing systems rather than replacing them. A schema is built first against the two or three data sources that genuinely need a unified view, such as order status from an ERP and customer data from a CRM, while everything else stays on its existing integration path. This mirrors the approach used on real-time systems work using GraphQL subscriptions, where push-based updates were layered over existing hardware interfaces without rebuilding them from scratch. Good API governance from day one, including schema ownership, deprecation rules for breaking changes, and query complexity limits, avoids the schema sprawl that makes a GraphQL layer as hard to maintain as the REST sprawl it replaced.
Considering GraphQL for your integration layer?
Send us the query patterns across your client applications and get a recommendation between GraphQL, REST or a mix of both, so you build the right contract instead of the trendiest one.
GraphQL implementation questions answered
What is GraphQL and how is it different from a REST API?
GraphQL is a query language for APIs where a client specifies exactly which fields it needs in a single request. REST exposes fixed endpoints that return a set response shape, so adding a new client view often means adding a new endpoint. GraphQL lets each client ask for a different combination of fields from one schema.
When does GraphQL implementation make sense for an existing business system?
It earns its complexity when several independent applications, such as a website, mobile app and partner portal, need overlapping but not identical data from the same backend. A single integration between two stable systems rarely needs GraphQL; a well-built REST API usually does that job with less overhead.
Can GraphQL be layered over legacy systems without rewriting them?
Yes. A common staged approach builds a GraphQL schema in front of two or three systems causing the most endpoint duplication, leaving other integrations running on their existing path untouched. This avoids a disruptive rebuild and lets the schema grow only as more consuming applications genuinely need it.
What is the repeated-query problem in GraphQL and why does it matter?
It happens when a single GraphQL query triggers many separate calls to underlying services, one per field or record, instead of one batched call. A query that performs well in testing can slow sharply under real traffic if resolvers weren't designed with batching or data-loading patterns from the start.
Does GraphQL work with Xero, MYOB, Shopify or HubSpot integrations?
Yes, though most of these platforms only expose REST or app-specific APIs natively. A GraphQL layer is typically built as middleware that queries Xero, MYOB, Shopify or HubSpot behind the scenes and presents one unified schema to internal applications or partners, rather than forcing every client to learn each platform's quirks separately.
What does a GraphQL implementation project typically involve?
It usually starts with mapping which applications query which data and where requirements overlap, followed by building resolvers against the highest-duplication systems first. Schema governance, including ownership and deprecation rules for breaking changes, is set up before more consuming applications are added to the schema.