ACMC GraphQL Types

ACMC GraphQL Types Overview

The ANZ Cash Management Central (ACMC) GraphQL schema is built using a variety of core GraphQL types. These types structure the API, allowing flexible and efficient querying of data. Below is an overview of the main GraphQL types used in ACMC, along with important concepts regarding mandatory (non-nullable) and optional (nullable) fields.

GraphQL Types in ACMC

  • Object Types: Object types are the core entities in the ACMC schema, representing structured data such as Account, PartyIndividual, and Payment. These types define fields that can either reference scalar values (e.g., String, Int) or other object types, allowing complex and nested queries.

  • Enum Types: Enum types provide a limited set of predefined values for specific fields. For instance, an AccountStatus enum might return ACTIVE, INACTIVE, or CLOSED. Enums ensure consistent responses and improve data integrity.

  • Scalar Types: Scalars represent the simplest data types in GraphQL, and are used for the basic fields in object types and ensure concise, consistent data.
    • Int for integers
    • Float for decimals
    • String for text
    • Boolean for true/false
    • ID for unique identifiers

  • Input Types: Input types are used in mutations to pass structured data to the API. For example, when creating an account, you might use an OpenAccountInput input type to provide fields like accountType and name. Input types ensure the correct data structure is passed during operations.

  • Interface Types: Interfaces allow different object types to share common fields. For instance, BusinessProcess implement a shared interface that includes fields such as transactions and id. This ensures consistency across object types with common attributes.

Nullability in GraphQL

In GraphQL, fields are nullable by default, meaning they can return null if data is unavailable or an error occurs. This design helps maintain partial results in the event of system failures or authorisation issues, ensuring the entire query doesn’t fail.

  • Mandatory (Non-Nullable) Fields: A non-nullable field guarantees a value will always be returned. Non-nullable fields are marked with an exclamation mark (!) in the schema, such as String!. If a non-nullable field cannot be resolved, the parent field will return null instead, propagating the error upward.

  • Optional (Nullable) Fields: Fields that are nullable can return null if necessary. They are are indicated as Type without the exclamation mark. These fields are useful when data might not always be available, such as an optional middleName field in a User profile.

Best Practices for Nullability:

  • Use nullable fields for optional or non-critical information where failure or lack of data is acceptable.

  • Use non-nullable fields for critical data that is required for the operation’s success. Consider the impact of failure on query execution, and whether the entire query or just individual fields should fail.

  • Design for resilience by leveraging nullable fields to handle network, database, or authorisation errors without halting the entire query response.