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?

Takeaways

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.