Own Your Crash Logs with PLCrashReporter: Part 3
iOSIn the third post of our PLCrashReporter series, we will walk through how to get PLCrashReporter up and running on your machine. And make...
GraphQL can revolutionize your product by improving performance, reducing friction between development teams, and even helping with documentation. But it’s important to understand the tool before deciding if it’s the right one for the job. This is the first post in a series that intends to give a strong foundational knowledge to anyone interested in learning if GraphQL is right for their project.
First, let’s explore the basics of GraphQL in order to get a baseline understanding of this query language.
We’ll start with a definition. According to the GraphQL Foundation, “GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data.”
At its core, GraphQL allows the client to retrieve data from the server. It is a specification that can have different implementations for different platforms, on both the client and server-side. GraphQL also contains a key defining feature that makes it stand out from other web services, which we will explore next.
Once the GraphQL architecture has been set up, the client only has to work with one endpoint, which is typically /graphql
. By using this single endpoint, the client can request only the data it needs within the GraphQL query. This enormous degree of flexibility is what sets GraphQL apart because it lets the client control what data it receives. See below for a quick example taken from GraphQL.org:
What the client asks for:
{ hero { name height mass } }
In its simplest form, this is how the request would look in a POST request body being sent to /graphql
:
{ "query": "hero{name height mass}" }
And this is what the client would receive:
{ "hero": { "name": "Luke Skywalker", "height": 1.72, "mass": 77 } }
If the above scenario took place in a REST architecture, it is easy to imagine that the client could have asked for the hero
and received a lot of unneeded data (over-fetching), or the client may have had to make multiple calls to receive each of these specific attributes (under-fetching). Thanks to GraphQL, we have the advantage of “exactly-right fetching.”
There is much more to GraphQL and its advantages (and disadvantages), but before we get there, let’s briefly explore its origins.
In 2012, Facebook began its efforts to redesign its native mobile apps due to their poor performance. This effort created new consumers of all their APIs and complex data. Additionally, performance became more critical as large user bases began to grow in regions of the world that lacked fast cellular networks. Milliseconds and kilobytes now mattered more than ever when fetching data.
Unfortunately, this redesign led to frustration. Not only did Facebook have to grapple with the difference between the data they wanted to use and the server queries required to fetch them, but they also had to write a considerable amount of code on both the server and client-side to prepare and parse the data.
These struggles led Facebook to rethink mobile app data-fetching from the perspective of product designers and developers. What was started as an internal project to give more control to the client-side grew into what is now known as GraphQL.
In 2015, it was made open-source. Then, in 2018, the GraphQL project was moved from Facebook to the GraphQL Foundation which is hosted by the non-profit Linux Foundation. A large community of developers and technology companies has grown around it ever since to provide contributions and stewardship to GraphQL.
Since becoming open-source, a variety of companies have adopted GraphQL. Some of the most recognizable names are:
As you can see, if you choose to implement GraphQL, you will be in good company. According to GraphQL, their users have a combined market cap of $4.08T and funding of $9.34B. For a more complete list of big-name adopters, take a look at this landscape.
Interest in GraphQL can come from several different roles in your organization.
Front-end developers might be interested in implementing it to reduce the number of requests they need to make. Or they might be drawn in by the “exactly-right” fetching we discussed earlier. The front-end devs might also be attracted to the potential for fast iteration on their side. Without the need to ask the server-side to update an endpoint every time the UI changes, the front-end can make changes faster and with less friction.
On the back-end, developers can create a GraphQL server using any common language. This makes GraphQL a strong option to consider. A key reason back-end developers will be interested in GraphQL is that they will not have to spend time making changes to endpoints every time the front-end has changed. Not only this, but GraphQL could also replace legacy REST APIs and reduce the amount of versioning and maintenance required. Another upside for back-end developers is the self-documenting nature of the GraphQL schema.
Project stakeholders would also benefit from learning about GraphQL and what implementing it could mean for a project. If performance is critical, GraphQL would be something to give strong consideration to, especially for apps operating in areas with slower internet speeds. GraphQL could be a valid solution for a project that has growing technical debt due to legacy or ever-evolving REST APIs. A project that has complex systems and microservices could also benefit from the unification that GraphQL can provide.
Due to the growing popularity of GraphQL, there are numerous tools and resources to help you get started.
We’ve just begun to scratch the surface of GraphQL and what it can do for your project. But just like any other tool, considerations must be made to determine if it is the right one for the job.
For help in determining whether GraphQL is the right choice, be on the lookout for our next post: Is GraphQL Right For My Project?
In the third post of our PLCrashReporter series, we will walk through how to get PLCrashReporter up and running on your machine. And make...
In part two of our PLCrashReporter series, we will examine how crashes are created and learn more about specific crash types.
In this four-part series, we will first dive deep into crashes and will provide you with a step-by-step tutorial on how to get PLCrashReporter...