GraphQLifying React Native App

Yle’s news app had more than 200,000 weekly active users, but years of added features had made its code and startup process complex. Linnanen found more than 15 API calls involved in startup, with Redux and Redux Saga helping keep local and remote data in sync. He built a one-week proof of concept that combined REST data behind a GraphQL gateway and reduced startup to one or two calls.

The team chose a JVM-based CraftQL server for the production API and kept article content on its existing optimized REST endpoint. Client-side local resolvers fetched articles with Axios and wrote them into Apollo’s cache. Because optional fields could be missing, Linnanen’s team built a schema enforcement function to supply defaults and add __typename; he notes this approach was tricky and local resolvers were deprecated in Apollo Client 3.

Type policies let the team look up an article by ID while returning the fuller article query data, including related concepts. Linnanen separates state into remote data for Apollo queries, shared local data for reactive variables, and component-only data for React hooks. Reactive variables update queries that depend on them, but the team had to persist their values separately in AsyncStorage.

Linnanen used React Native Debugger to inspect Apollo queries, mutations, and normalized cache contents. He also described an early Flipper plugin with a working cache tab. For tests, Apollo’s MockedProvider could pair requests with responses, but its mocks did not cover local resolvers, which instead required passing resolvers to the provider.

The app was still in active development, but the team reported clearer API contracts through the GraphQL schema and TypeScript, plus fewer overfetching and underfetching issues. Startup went from 15 API calls to one. Linnanen said separating remote, shared local, and component state also made the app logic easier to understand and test.