When building a robust, high-performing core banking system, implementing GraphQL Federation can significantly augment RESTful APIs. Let’s delve into how GraphQL Federation adds value to your RESTful APIs, and why it’s a crucial part of a modern core banking system.
GraphQL Federation is an architectural pattern in which a central GraphQL gateway aggregates multiple underlying APIs or microservices into a single, unified API surface. Clients submit queries to the GraphQL gateway specifying exactly the data they require, and the gateway retrieves that data from the relevant underlying services, assembling the response before returning it to the client. This pattern addresses a set of specific performance and architectural challenges that arise when building complex, microservice-based systems such as modern core banking platforms, where a single user-facing operation may require data from multiple independent services.
As illustrated in a typical GraphQL Federation architecture within a core banking system, a client application submits a single GraphQL query requesting a customer’s account balance, recent transaction history, and active product subscriptions. The GraphQL gateway decomposes this query into sub-requests directed at the account management service, the transaction processing service, and the product management service respectively, retrieves the data from each, and assembles a single consolidated response. Without GraphQL Federation, the client application would need to make three separate API calls, handle the responses independently, and assemble the combined data on the client side, increasing both network round trips and client-side complexity.
Key Takeaways: #
- GraphQL Federation is an architectural pattern that creates a unified API gateway layer over multiple underlying RESTful APIs or microservices, allowing clients to retrieve data from multiple sources through a single query rather than multiple separate API calls;
- In core banking software, GraphQL Federation addresses specific performance and developer experience limitations of RESTful APIs, including overfetching, underfetching, and the need for multiple network round trips to fulfil complex data requests;
- GraphQL Federation and RESTful APIs are complementary rather than competing approaches. RESTful APIs remain the standard for external-facing integrations, including PSD2 open banking interfaces, while GraphQL Federation operates as an internal orchestration layer within the core banking system architecture.
How GraphQL Federation Enhances RESTful APIs in Core Banking Contexts #
Unified API endpoint and reduced network round trips: In a microservice-based core banking architecture, different functions such as account management, payment processing, customer data, and product management are typically exposed through separate RESTful API endpoints. A client application requiring data from multiple services must make a separate API call to each endpoint, with each call adding latency to the overall operation. GraphQL Federation consolidates these into a single endpoint, allowing the client to retrieve data from multiple underlying services in a single network round trip. For real-time banking applications where response time directly affects user experience, this reduction in network round trips produces measurable performance improvements.
Precise data fetching and elimination of overfetching and underfetching: A structural characteristic of RESTful APIs is that each endpoint returns a predefined data structure, regardless of whether the client requires all of the fields in that structure. Where a client requires only a subset of the available fields, it receives and must process more data than necessary, a problem known as overfetching. Conversely, where a client requires data that spans multiple endpoints, it must make additional API calls to retrieve it, a problem known as underfetching. GraphQL Federation resolves both issues by allowing the client to specify exactly which fields it requires in its query. The gateway retrieves only the requested fields from the relevant underlying services, eliminating unnecessary data transmission and reducing the processing overhead on both the client and server sides.
Schema stitching and unified data model: GraphQL Federation provides mechanisms for combining the data schemas of multiple underlying services into a single, unified federated schema. This unified schema presents a consistent and comprehensive view of all available data to client applications, abstracting the complexity of the underlying microservice architecture. In a core banking context, this means that developers building client applications interact with a single, coherent data model rather than needing to understand the individual data structures and endpoint conventions of each underlying service. Schema stitching also enables relationships between data entities managed by different services to be expressed and navigated within a single query, simplifying the development of features that depend on data from multiple sources.
Declarative data fetching and developer productivity: GraphQL’s query language allows clients to express their data requirements declaratively, specifying the fields and relationships they need rather than constructing URLs and parsing the fixed response structures of individual RESTful endpoints. This declarative approach reduces the amount of client-side code required to retrieve and process data, simplifies testing, and makes the intent of each data retrieval operation more readable and maintainable. For development teams building and maintaining complex core banking applications, the reduction in boilerplate code and the improved readability of data fetching logic contribute to faster development cycles and lower maintenance overhead.
Efficient batched requests: GraphQL Federation supports the batching of multiple data requests into a single query, even where the required data is distributed across different underlying services. In a core banking context, this is particularly valuable for operations that require data from multiple domains simultaneously, such as generating a customer dashboard that combines account balances, recent transactions, pending payments, and product information. Batching these requests through a single GraphQL query reduces the total number of network round trips and the associated latency, compared to the sequential or parallel RESTful API calls that would otherwise be required.
Evolutionary API development and schema versioning: GraphQL Federation supports gradual, iterative evolution of the API schema. New fields, types, and relationships can be added to the federated schema without breaking existing client integrations, as clients only request the fields they need and are unaffected by additions to the schema. This evolutionary approach avoids the versioning challenges that arise in RESTful API development, where changes to an endpoint’s response structure may require the introduction of a new API version and coordinated updates across all client applications. For core banking software that must adapt continuously to new product requirements and regulatory changes, the ability to evolve the API schema incrementally without breaking existing integrations reduces the operational risk of API updates.
Where RESTful APIs Remain the Appropriate Standard #
GraphQL Federation operates as an internal orchestration layer within the core banking system architecture and is not a replacement for RESTful APIs in all contexts. For external-facing integrations, including PSD2 open banking interfaces, payment network connections, and third-party TPP access, RESTful APIs remain the required and appropriate standard. The EBA RTS on SCA and secure communication specifies RESTful architecture for open banking interfaces, and the Berlin Group NextGenPSD2 specification and UK Open Banking Standard are both RESTful implementations. GraphQL Federation is therefore most appropriately used as an internal performance and developer experience optimisation layer, rather than as the interface exposed to external parties and regulated TPPs.
FAQ: #
What is the difference between GraphQL and GraphQL Federation?
- GraphQL is a query language and runtime for APIs, developed by Meta, that allows clients to request exactly the data they need from a single API. GraphQL Federation is an architectural pattern built on top of GraphQL that extends its capabilities to distributed systems composed of multiple independent services. In a GraphQL Federation architecture, each service maintains its own GraphQL schema, and a central gateway combines these into a unified federated schema that clients interact with as a single API. GraphQL Federation is therefore the approach used when applying GraphQL principles to a microservice architecture, rather than to a single monolithic API.
Does implementing GraphQL Federation affect PSD2 open banking API compliance?
- GraphQL Federation operates as an internal API orchestration layer within the core banking system and does not directly affect the external-facing open banking API interface that the institution must provide under PSD2. The PSD2-compliant open banking interface, whether implemented to the Berlin Group NextGenPSD2 specification or the UK Open Banking Standard, must be a RESTful API regardless of the internal architecture of the core banking system. An institution can use GraphQL Federation internally for data orchestration across its microservices while exposing a fully compliant RESTful open banking API externally. The two architectural layers are independent and do not interfere with each other.
GraphQL Federation encourages gradual and iterative API development. Developers can introduce new fields, types, and relationships to the federated schema without impacting existing clients. As clients can selectively adopt new features as needed, it offers flexibility and prevents versioning issues often encountered in RESTful API development.
Leveraging GraphQL Federation in conjunction with RESTful APIs allows core banking software developers to create a more efficient, flexible, and high-performing data-fetching experience. By optimizing these processes, the end-user benefits from a streamlined, robust core banking software experience.
Innovation and strategic utilisation of technology are at the heart of Baseella’s operations. As part of our commitment to optimize the performance of our core banking system, Baseella integrates the efficiency of RESTful APIs with the robust capabilities of GraphQL Federation. Reach out to us to discuss more how actually we are leveraging the most robust technology.
