GraphQL allows API consumers to make complex, rich queries. However, as with any query language, it is possible to construct poorly optimized queries which negatively impact your user experience.
Here are some general tips to ensure that your queries remain fast and light, and that your frontend remains responsive.
Understanding the performance requirements of your application, and testing the performance of each query used in your application with different bank accounts is a necessary step to understanding where to focus your attention in regard to optimization.
It may be possible to restructure queries in a way that greatly improves performance (e.g. retrieving an item directly by id, rather than going via a bank account) Experimenting in the Stitch IDE is the fastest way to quickly try out different ideas.
The first tip is possibly obvious, but if you don't need a specific field, you will see speedups from omitting it. The magnitude of the speedup is, of course, dependent upon the field, and the bank account, but omitting a field means that the server does not have to resolve it, reducing the total time of the query.
Closely related to over fetching, if you reduce page sizes, you will also likely see an improvement in response times. The Stitch API uses cursor-based pagination, and particularly for user-facing applications, it is often better to prioritize initial responsiveness over fetching all the data at once. It is always possible to fetch the next page in follow-up requests if it's needed.
Frameworks like Relay include GraphQL query optimizers which help you optimize queries for given UI views. This is very useful in complex interfaces where different subcomponents may be requesting different, overlapping pieces of data.
Many GraphQL frameworks include support for caching results of queries or caching specific entities within a query. For example, Apollo Client has the ability to redirect queries to cached data. Stitch API attempts to cache certain information within the context of a session, however as it has less knowledge of application requirements, it cannot make as many assumptions, and thus cannot cache as effectively as an application-specific cache could.
Again on the theme of reducing the amount of data being requested in a single query, query splitting is where a given query is broken up into a number of smaller queries. While this will not reduce the total time taken, it allows for individual parts of a view to load independently, and more easily allows for caching.
Populating the cache with key pieces of data before it's needed is a way to improve the perceived responsiveness of your application. This technique relies however on being able to predict where the user is likely to navigate to next. Nevertheless, if this can be done accurately, it's a good way of reducing the time a user spends waiting.