As a performance improvement, investigate and create a Proof of Concept that integrates the Work Items REST API into the planning view app. This integration should only fetch list data, and support all of the current filtering and sorting capabilities. While it's easier to integrate this as a new totally separate mechanism, by using `axios` and an async method in a component, that will result in us no longer having the benefit of the data living in Apollo cache and automatically handling refetching, caching, and sharing data between other components via cache. ## Local resolver We should explore writing a local resolver, for example: ```javascript const resolvers = { Namespace: { workItems: async (namespace) => { const res = await fetch(`https://gitlab.com/api/v4/namespaces/${namespace.fullPath}/-/work_items`) if (!res.ok) throw new Error(`REST fetch failed: ${res.status}`) return res.json() // we'll probably need to alter this data to be in the correct format first }, }, } ``` ```graphql query GetProduct($fullPath: ID!) { namespace(fullPath: $fullPath) { id workItems @client { # resolved locally, never sent to the server id } } } ``` ## Alternative approach Alternatively, we could write a `read` policy for the `workItems` field, which would require more work and would not integrate as neatly into the existing GraphQL stack. The dowside of this approach is that `read` functions in policies cannot be `async` or return a `Promise`, so we'd need to handle some internal reactive state within the policy + apollo cache and the API request would be 'fire and forget' with no automatic re-fetching etc. For this reason, the above method of using a local resolver is better. ## Additional challenge If this works nicely, we should add a feature flag which switches between the `@client` and regular version of the query. If `@client` is missing, the regular GraphQL API will be used, if it's present, the REST API will be used.