Using Ionic, GraphQL, and Loona
At our last Kick Back & Code meetup, we hosted a discussion about GraphQL where we gave a brief overview of what it is, how it works, and demonstrated a sample project. This blog post briefly covers the GraphQL portion of the meetup. If you would like more insight into the content covered in this meetup please refer to the slides.
What is GraphQL?
GraphQL is an alternative to REST and, like REST, it is a specification. This means that it is not a library; there is no code-base backing up GraphQL. Instead, GraphQL is a set of rules that the front-end and the back-end of an application need to agree upon in order to communicate with each other.
REST vs GraphQL
Consider an app that utilizes user profiles. When looking at someone’s profile you might need to access a fairly large data object depending on how big the app is. Below is an example of querying a REST end-point for a user profile.
This is great, we have all the information we need to display this user’s information on a profile page. What about the case of displaying a user’s friends list? We might display a large list of users but we probably wouldn’t need their entire profile, probably just their username and profile picture. With a traditional REST API, we would have 2 potential options.
Option 1 — New Endpoint
GET /user-short
The first option we have is to create a new API endpoint. This endpoint would be separate from the original endpoint that returned the full user profile and would return only the user info needed to display a user in a list. This endpoint might be named.
This approach gets the job done but at a price. The developer working on the friends list feature will have to spend added development time on creating this new backend endpoint. As requirements change, this will eventually lead to a ton of different endpoints that need to constantly be updated.
Option 2 — Query Parameter
GET /user?data=short
The second option we have is to allow our endpoint to accept query parameters. The inclusion or exclusion of the “short” parameter would determine whether the full user profile data was being returned or the shortened version.
The approach looks cool but it too has a cost. Like the first option, the developer working on this particular endpoint will need to add time to her development for customizing the existing endpoint to suit her needs. This is perhaps more taxing than the first option because it not only requires testing of the new logic that was added, but also testing of the old endpoint logic to ensure that nothing was broken. This method can also eventually cause the logic to become hard to follow.
Option 3 — GraphQL
A third option is to use a GraphQL API instead of a RESTful one. With REST you typically use GET to fetch our data from the backend and POST, UPDATE, DELETE to create and update data. With GraphQL you are only writing to a single endpoint. This endpoint (usually /graphql) is flexible enough to fetch data in the format requested by the front-end as well as create and update data.
The trick with GraphQL is that we’re always using POST, even if we’re just fetching data. Using this method we can submit data from the front-end that represents how the data we want back is modeled. The example below shows what it might look like if we were to query the same endpoint for different data models using GraphQL. Properties can be added or removed from the Query without needing to change the backend logic. Pretty cool stuff!
Thank you for reading this brief overview of GraphQL. For more information check out our slides below and if you’re in the DC area be sure to join our Meetup group (also linked below.)
Check Us Out
We regularly host meetups about the technology we like to use, so stop by our Meetup page or Eventbrite and sign up. If you’re interested in talking or hearing about a topic, let us know!
The Washington Ionic Framework Meetup
Eventbrite
Blast From The Past
We have blog posts for other past meetups. Read them!
