Next revolution
GraphQL is a really hot topic now. While it’s adopted by backend and frontend, the natural path is to transform the mobile side also. But the task is not so trivial. After years of battling about the best mobile architecture, Android developers around the world agreed to a more or less common technological stack.
There is a Room library for the local databases, RxKotlin for reactive streams, and finally some code like Retrofit to handle REST requests. In most cases, with their use a project will be completed painlessly and in reasonable time.
Do we need the next revolution? If we want to ship products even faster, the answer is yes!
Benefits of GraphQL
GraphQL is a quite new solution with concepts varying from the current approach. Fundamental idea to perceive the results as a graph is made to cure most of the REST’s weak points.
Let’s recall the advantages of GraphQL:
- Strong typed data
- Reduced size of response
- Better performance
- Generated documentation
- Useful tools
- Active community
That is a lot! Now, what impact does it have on mobile architecture?
Choose the right way
At this moment we have two ways to start consuming graph’s responses. First is to use Apollo Client written for mobile platforms. Second is to adjust the current HTTP consumer for receiving and sending query language requests.
In my opinion, a dedicated Apollo solution is better to start coding and significantly accelerates the process of creating an MVP. In this article, I assume that we are using Apollo Client for Android which can be found here.
Let’s see how much code we have to write to start.
This is very straightforward — with default values creating a client is just a matter of 3 lines of code 🙂
Everything in single query
The main goal of this technology is to combine data from different sources in a single response. From the backend side it seems logical to have a separate table in the database and corresponding REST endpoint for a single type of information, for example a list of jobs.
What if the frontend (mobile) has to present a list of jobs with an additional thing. In this case, the logo of a company may be serving a job offer. The problem is illustrated in the image below.
To reach this result with REST API, it is necessary to follow these steps:
- Fetch a list of jobs
- Fetch a list of companies
- Create a model for job
- Create a model for company
- Merge fields from both models in view and display
It is a lot of work for such a simple list. On the other hand, graph query may look like this:
Then you will receive all pieces of information you were asking for in only one response! 🙂
Strong typed data and model generation
Using the GraphQL, we always know the type of returned field. This way, it doesn’t lead to errors recognized from REST API, like expecting Integer and receiving String.
Moreover, the declared type tells you whether a value can be null or not. It is especially important for modern languages like Swift or Kotlin with null-safety for models.
Speaking of models, a code from Apollo automatically generates classes. It really simplifies all the process of handling responses from the network.
Generated job model by Apollo may look like this:
As you can see, although all code is generated, it is much logical for a data class!
It is also worth mentioning that, when generated models are very handy, the developer loses some flexibility, such as use of generics, abstraction, and inheritance.
Cache strategy
With a single query, a user can fetch a lot of info. For example a list of jobs already with their details. It would be great to cache this list for future usage, e.g. offline work. For our convenience, Apollo Client has three steps of caching:
- HTTP cache — sets regular well known HTTP cache for queries with appropriate policy
- Normalized cache — stores in memory pieces of response that can be reused in future
- Automatic Persisted Queries — immediately returns cached queries on server and thus graph doesn’t have to be searched every time
It allows building blazing fast applications without annoying loaders just with a few lines of code.
Without problems during migration
All these functionalities are awesome and mostly can convince developers that GraphQL is better and faster than REST, but what if we want to migrate an existing project?
Fortunately, an Apollo product can generate models in both Kotlin and Java. What’s more, it is based on regular okHttpClient so if you have experience with Retrofit this knowledge is suitable here, too.
It is possible to use RxJava or Kotlin Coroutines for handling the results — it depends on your necessities.
Great documentation
This advantage doesn’t correspond directly to Apollo Client but working with well written documentation is easier and faster.
GraphQL tools like GraphiQL or GraphQL Voyager help understand the API and see what fields will be returned.
Developers can write queries and test their result right in the browser. Many of these online documentations are interactive which means you can jump between the nested types.
I won’t go through all the details. The key is that a developer fetching information from the server knows everything and doesn’t have to attach external tools like Postman.
Summary
Nowadays, GraphQL seems to be a perfect technology for creating MVP. Developers can focus more on the visual layer of application and consume data right from the queries.
It is too early to say whether applications made with Apollo Client will scale without the efforts. Generated models, break up with REST methods, and different approaches may lead to some complications in the future.
In my opinion, Android development should be calmly adopting GraphQL as it reduces much of the work on the earliest stages of production.
Want to know more? We’ve already written about the architecture and advantages of this technology in our latest blogpost.
If you’d like to see sample repository with examples used in this article, check our github.
