Skip to main content
GraphQL offers several key advantages:
  • Strongly-typed. GraphQL’s schema is less error-prone than other API styles and provides additional validation and consistency.
  • Efficient. GraphQL allows clients to specify in a single request the exact data they need. No over- or under-fetching.
  • Flexibile in handling complex queries. Developers can tailor their queries to meet specific needs without altering the server-side code.
  • Evolving API. No need to maintain API versions. New fields can be added and older fields deprecate as needed.

​
Why GraphQL?

REST becomes hard to maintain as an API grows in complexity, and payments APIs are complex. GraphQL lets clients request exactly the data they need in a single query and lets us evolve the schema without versioning, so we built the Acquiring API on it.

​
GraphQL vs. REST

​
Advantages

Strongly-typed schema: Each data type (Boolean, String, Int, Float, ID, Scalar, etc.) is specified in the schema of the GraphQL Schema Definition Language (SDL), and determines the available data and the form in which it exists. This strongly-typed schema makes GraphQL less error-prone, and provides additional validation. Saves time and bandwidth: By requesting only the data you need, there’s no worry of over- or under-fetching. One of the common ask from most of our prospects is detailed and accurate reporting. Financial transactions contain many different attributes including unique IDs and references, dates, amounts, payment method details, authorization responses and codes, and depending on the report and the KPIs being monitored, not all fields are needed all the time. GraphQL allows each of our design partners to define the fields they need returned without having to fuss with complex filtering at our end or their end. Schema stitching: Schema stitching allows combining multiple, different schemas into a single “super graph” schema. In a microservices architecture, where each microservice handles the business logic and data for a specific domain, this is very useful. Each microservice can define its GraphQL schema, after which you use schema stitching to weave them into one schema accessible by the client. At Tesouro, each service has its own API, and schema stitching combines them into a single source: Evolving API: REST APIs version by URL (api.domain.com/v1/, api.domain.com/v2/) when the request or response structure changes. GraphQL doesn’t need versions: the resource URL stays the same, and you add new fields or deprecate old ones as needed. Clients get a deprecation warning when they query a deprecated field, so you can add and support new features without breaking existing integrations. For example, when new payment methods come to market, you don’t need to change your integration. The same API endpoints support the new features once we add the data elements for them.

​
Disadvantages

  • Lack of resources and tools on the backend part.
  • Performance issues with complex queries.
  • Overkill for small and simple applications.
  • It lacks built-in HTTP caching mechanisms, potentially making efficient caching more complex to implement.
  • You need to learn the GraphQL Schema Definition Language before you implement GraphQL strategies.

​
Resources

Official GraphQL website
Find a full overview of the language and lots of examples. GraphQL tutorial from educative.io
Learn fullstack GraphQL fast with hands-on practice and projects. Apollo GraphQL
An assortment of hands-on GraphQL tutorials The Fullstack Tutorial for GraphQL
The free and open-source tutorial to learn all around GraphQL to go from zero to production. Brought to you by the GraphQL Community and Prisma. Exploring GraphQL: A Query Language for APIs
A free online course offered by edX, an online learning platform from digital education company 2U, Inc.