Search
  • techucatecmo

Why It’s Time To Switch To GraphQL

If you are a modern day developer, the chances are quite high that you have had to deal with a REST API – it’s just one of the many tasks that software developers must encounter in order to get data from a client to a remote server. However, as software becomes quicker and more efficient on the server and also on the client, we often must twist our API’s to do things that they simply are not designed to do. What if we want to get only specific data field on one webpage of the client but a different data field on the same model from another? Should we build multiple API’s? What if we only want 100 results on one page, but only 3 on the next? While these scenarios may seem trivial at first, the amount of time spent updating and fixing API’s to fit the client’s expectations can become frustrating and time consuming. For this reason, we should explore why developers should switch to GraphQL.


GraphQL is a Facebook-developed API layer that helps you query and mutate server-side data. It was created with the goal of making API’s quicker and easier to stand-up and use. In general, GraphQL doesn’t task the developer with loading in models and manually writing API functions, it instead parses API interactions into repeatable queries and mutations, which are the fundamental building blocks of any API. In order for the queries and mutations to interact with the data models, developers can build schemas, of their data models, which essentially allows GraphQL will use to accurately retrieve or mutate data. Moreover, this process only takes minutes, and becomes more efficient than individually building every component of a monolithic API.


At this point you might be wondering “Sure, this sounds structurally efficient, but how do I actually build the unique API service my client needs?” One of the most important functions of GraphQL is the payload and the resolver. A payload is a unique request that the client sends to get specific API results. Resolvers basically provide the client with the unique methods to satisfy the request. For example, let’s say we are building a social media application and we want to show all of the users. Like I mentioned earlier, we could have two webpages each requesting the User model, but one webpage wants to show the last 100 users and the other webpage only wants to show the last 10. We could even increase the API complexity by wanting to show the username and bio on the first webpage for each of the 100 users, but only the username for the second webpage with 10 results. This is how our two queries could supposedly look:


query getUsers(limit: 100){ username bio }

vs.

query getUsers(limit: 10){ username }


These two queries show the different payloads. The first, like explained earlier, requests the username and the bio, while the second has just a field request of the username.


On the GraphQL side, we would just need to build one resolver, and GraphQL will handle the dynamic changes. Here is what a Ruby based resolver might look like:

def getusers(limit: :limitinput) User.last(limit) end


Pretty cool, right? There’s no doubt that GraphQL is a very powerful tool that has the ability to rapidly change how we build experiences between our client and our server.


If you’re interested in learning more, please go and visit GraphQL’s website at https://www.graphql.com

12 views0 comments