Using GraphQL in Production iOS Applications – Part 3

Chris Downie and Sam Landfried

2 min read

Apr 8, 2019

Using GraphQL in Production iOS Applications – Part 3

In Part 1, we discussed what made us choose GraphQL for a client project. Part 2 recapped everything we learned working with GraphQL.

After all that, how would we recommend those less familiar with GraphQL use the technology?


So, is GraphQL the right technology for your project? Maybe! Like any technology, GraphQL has strengths and weaknesses that need to be weighed against the requirements of a project. As long as you’re aware of the constraints of this new technology, we have no doubt you’ll gain benefit from it. If you’re just starting a project with GraphQL, we’d make a few recommendations:

Be aware of the Apollo iOS SDK’s data & caching models

While the Apollo iOS SDK is absolutely the fastest way to start coding against a GraphQL API, it comes with a few quirks. Weighing the pros & cons of those quirks will help you decide if this is right for your project. If you decide it is, be aware that these constraints on the query models & caching are ones you’ll have to work around.

Hash out the schema early

The GraphQL schema is a unique concept that powers a lot of the GraphQL perks. The sooner it’s built, the sooner the frontend and backend teams can start building. Theoretically, anyone who has access to the app designs should be able to design the schema. To avoid assumptions that might result in an untenable schema, the frontend and backend teams should design the schema together.

Err towards flexibility when designing the schema

It is important to note that the GraphQL schema is not the same as the type definitions of a strongly typed programming language, even though they look similar. GraphQL queries are often resolved from external data sources that might fail for reasons beyond our control. Because of this, it is a good rule of thumb to make queries and fields nullable as default. Even fields that seem guaranteed to exist, like a user’s first name on a user query, might need to be nullable at some point if you wanted to restrict certain fields on a query based on the requestor’s authorization level.

GraphQL and REST endpoints can coexist in the same server

We used REST endpoints for authentication. There were reasons it would have been better to handle authentication and authorization in GraphQL queries, but it’s not because they were RESTful.

Building a GraphQL API allowed us to partially decouple frontend and backend development. It also gave us access to powerful and convenient utilities. If you’re considering adopting GraphQL for a project, weigh the pros and cons as you would before buying into any other technology. If you decide it is a good fit for your use case, you’re likely to find a lot of value in GraphQL.

Mark Dalrymple

Reviewer Big Nerd Ranch

MarkD is a long-time Unix and Mac developer, having worked at AOL, Google, and several start-ups over the years.  He’s the author of Advanced Mac OS X Programming: The Big Nerd Ranch Guide, over 100 blog posts for Big Nerd Ranch, and an occasional speaker at conferences. Believing in the power of community, he’s a co-founder of CocoaHeads, an international Mac and iPhone meetup, and runs the Pittsburgh PA chapter. In his spare time, he plays orchestral and swing band music.

Speak with a Nerd

Schedule a call today! Our team of Nerds are ready to help

Let's Talk

Related Posts

We are ready to discuss your needs.

Stay in Touch WITH Big Nerd Ranch News