20 Oct Unveiling GraphQL: A Potent Tool, Not a Panacea

Posted at 18:12h in apis, backend, latest, Rails, Ruby by
0 Likes
GraphQL is powerful and awesome but still is not a silver bullet
Drawing from my extensive background with REST APIs, I recently embarked on a journey to enhance my proficiency in GraphQL, and initially, it seemed like GraphQL was perfect and could be the ultimate successor to REST APIs. However, hands-on experimentation quickly dispelled that notion, highlighting that GraphQL, despite its robustness, isn’t a one-size-fits-all solution.
In this post, I’ll be sharing some insights got after a few days of playing with GraphQL in Ruby using the following GraphQL gems :
  • gem 'graphql'
  • gem 'graphql-client'
  • gem 'graphql-batch'
Why should we prefer GraphQL over REST APIs?
Efficiency and Precision
You can allow clients to fetch exactly what they need, no more and no less. In REST, you might have to hit multiple endpoints to gather all the needed data or over-fetch data from a single endpoint. With GraphQL, you specify exactly what you need, leading to smaller and more precise data payloads.
Single Endpoint
Unlike REST which can have multiple endpoints for different resources (e.g., /v1/orders, /v2/items, etc.), GraphQL typically exposes a single endpoint that handles all queries and mutations. This centralization simplifies the communication between client and server.
Strongly Typed Schema
GraphQL requires you to define a schema that specifies the types of data that can be fetched and the set of possible queries, mutations, and subscriptions. This schema acts as a contract between the client and the server, ensuring type safety and enabling powerful developer tools.
Introspection
The schema can be queried for the types it supports. This enables powerful tooling that can auto-generate documentation, assist in query construction, and more.
Flexibility for Frontend Development
As frontends evolve faster than backends, GraphQL empowers frontend developers to request data in the shape and format they need without backend changes.
Versioning
In REST, changes often lead to versioning of the API (e.g., /v1/users, /v2/users). With GraphQL, the same schema can be evolved and fields can be deprecated without breaking existing clients.
Endpoint vs. Schema
REST APIs are organized around endpoints that represent entities. GraphQL APIs are organized around a schema and a type system.
Error Handling
In REST, you have status codes that indicate the nature of the error (404 for not found, 500 for server error, etc.). With GraphQL, the server always returns a 200 OK status code, and errors are communicated within the response payload.
Statelessness vs. Flexibility
REST is stateless between requests, and each request contains all the information needed to process it. GraphQL queries can be more flexible and dynamic, potentially requiring more stateful handling.
In essence

GraphQL was developed by Facebook in 2012 to address the inefficiencies of REST, especially in the context of mobile devices with limited bandwidth and the need for faster development cycles. It was later open-sourced in 2015.

So at first glance, GraphQL seems perfect for everything, doesn’t it? Well…

Let's look into the potential difficulties and challenges of using GraphQL.
Complexity
GraphQL can sometimes introduce complexity for simple use cases where a REST API might suffice.
Caching
Client-side caching can be more challenging compared to REST.
Learning Curve
For teams familiar with REST, the initial learning curve can be steep.
Rate Limiting
Implementing rate limiting with GraphQL can be more challenging compared to REST due to the flexible nature of GraphQL queries.
Performance Concerns
Without careful design, GraphQL can lead to inefficient database queries such as N + 1 queries
Over-fetching
Clients can make expensive requests by asking for too much-nested data.
In this post, I wanted to focus on over-fetching and performance concerns that I noticed in one of the big GraphQL players: Github
Over-Fetching: A Practical Guide Using a Popular Platform
Curious about reproducing over-fetching issues? Let’s delve into a practical example utilizing none other than the GitHub GraphQL API Explorer. Here’s how you can experience it first-hand
Step Into the World of GitHub's GraphQL API Explorer
Access the interactive platform here: GitHub GraphQL API Explorer
Initial Setup: Authorization
Before you begin, you’ll need to authorize your account for access to GitHub’s GraphQL API. It’s a straightforward process

Then you might be able to perform a query like this:

github error overfetching
In my experience, I encountered several issues with that particular endpoint, including occasional delays in query responses that impacted performance.

Which brings me to the following question:  What is your experience with preventing abuse and over-fetching in GraphQL?

Diving Back into Open-Source: Enhancing SMS Capabilities with GraphQL
I’m excited to share that I’ll be diving back into a cherished open-source project, SMS For All. This endeavor involves revamping an existing REST API, originally built with Ruby on Rails, and transitioning it into a more dynamic GraphQL API. The focus is on streamlining the management of SMS notifications, hubs, and all associated functionalities, enabling seamless sending of unlimited SMS notifications right from your Android device.
Repository Insights: Behind the Scenes

API Backend (Ruby on Rails): Explore the inner workings of our API backend. Your insights, pull requests, and contributions are welcome! Check it out here: GraphQL SMS API Repository

Frontend Client (React): A dedicated repository for the frontend client is in the works, promising a user experience in line with the current production site, accessible at SMS For All App. Stay tuned for more updates on this!

The existing code base for the Android App: For those interested in the project’s roots, the original code base is still accessible for reference: SMS Mobile Hub

Join the Conversation - Share Your GraphQL Journey


I’m eager to hear more about your personal experiences with GraphQL. Whether it’s challenges you’ve faced, success stories, or intriguing insights, your journey enriches our collective learning process. Let’s delve deeper into GraphQL together – your thoughts are invaluable! 

H.

No Comments

Post A Comment