Skip to main content
Tesouro’s API is built using GraphQL - a flexible, developer-friendly query and manipulation language that enables clients to get exactly what they need with a single query. This 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?

We were asked this question a lot by our design partners when we were initially building out our platform and API, and candidly, we asked the question to ourselves numerous times. We initially planned to use REST, which has been the recent standard for designing web APIs, however REST quickly becomes cumbersome to maintain as complexity grows, and in the world of payments, complexity is everywhere. So, following the Tesouro way of looking forward, we put our full effort towards researching the best solution for our partners success. We studied, tested, tweaked, and continued to challenge our thinking, and after sharing our findings with design partners and collecting their feedback and guidance, we strategically embraced GraphQL.

​
History of GraphQL

Developed by Facebook in 2012 and released publically in 2015, GraphQL is an open-source data query and manipulation language for APIs, and a runtime for fulfilling queries with existing data. It provides a complete and understandable description of the data in the API, and gives clients the power to ask for exactly what they need and nothing more, making it easier to evolve over time, and enable powerful new developer tools.

​
GraphQL vs. REST

GraphQLREST
A query language for solving common problems when integrating APIsAn architectural style largely viewed as a conventional standard for designing APIs.
Deployed over HTTP using a single endpoint that provides the full capabilities of the exposed service.Deployed over a set of URLs where each of them exposes a single resource.
Uses a client-driven architecture.Uses a server-driven architecture.
Lacks in-built caching mechanism.Uses caching automatically.
No API versioning required.Supports multiple API versions.
Response output in JSON.Response output usually in XML, JSON, and YAML.
Offers type-safety and auto-generated documentation.Doesn’t offer type-safety or auto-generated documentation.
Allows for schema stitching and remote data fetching.Simplifying work with multiple endpoints requires expensive custom middleware.

​
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. With modern technology and microservice architecture at Tesouro, each service will have its own APIs and schema stitching will allow all services to be presented together from a single source: Evolving API: In REST architecture, developers create new API versions (e.g., api.domain.com/v1/, api.domain.com/v2/) when there are changes in resources or to the request/response structure of the resources. With GraphQL, there is no need to maintain versions - the resource URL or address remains the same. New fields can be added and older fields deprecate as needed. Not only is this approach intuitive as the client will receive a deprecation warning when querying a deprecated field, but it’s also a very favorable feature for Tesouro as we continue to add and support new features on top of our existing build. For example, as new payment methods are introduced to the market, there will be no need for to change your integrations to our API. The same API endpoints with additional data elements can be used to access the new features when added.

​
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.
The adoption of GraphQL has been growing steadily year over year since its introduction in 2015. According to the State of JavaScript 2020 survey, which surveyed over 23,000 developers worldwide, GraphQL usage increased from 22% in 2018 to 47% in 2020, and statistics recently released by Gartner reveal how by 2027, more than 60% of enterprises will use GraphQL in production, up from less than 30% in 2024. Furthermore, the GraphQL ecosystem has been expanding rapidly. There are now many open-source tools and libraries available for GraphQL development, including Apollo, Prisma, and Wundergraph, making it easier for developers to adopt and work with GraphQL. In addition, many large companies have adopted GraphQL for their APIs. Braintree, Credit Karma, Airbnb, and Shopify are just a few examples of companies that have publicly stated their use of GraphQL, and have contributed to the growth of the GraphQL ecosystem by sharing their experiences and best practices with the community. Overall, the trend for GraphQL adoption has been positive year over year, with more developers and companies adopting the technology. As a result, we can expect to see continued growth in the GraphQL ecosystem in the coming years.

​
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.