DEV Community

Cover image for 5 reasons why Frontend Developers love GraphQL
Luka Kukina for Bornfight

Posted on

5 reasons why Frontend Developers love GraphQL

Besides creating those beautiful UIs our beloved designers give us, handling complex application logic and component architecture, we as frontend developers work with a lot of data manipulating in the process. In this post I will talk about how can a frontend developer be more productive and have a better developer experience by simply using GraphQL.

Probably like most developers out there, I used to work with REST APIs and mostly enjoyed it, but recently I've got an opportunity to work with GraphQL and instantly fell in love with it.
Here are the reasons why:

1) GraphQL has only one endpoint

When working with REST APIs, you are surrounded with a lot of endpoints, as their configuration is based on the names of the application’s entities they represent. On top of that, each entity has different methods to manipulate its data (POST, GET, DELETE, PUT, PATCH). All that taken into consideration,
basic REST API will look something like the image below:

REST endpoints

With greater complexity there will be more entities and more specific endpoints/queries...

GraphQL to the rescue 🎉 GraphQL uses only one endpoint!

GraphQL server operates on a single URL/endpoint, usually /graphql, and all GraphQL requests for a given service should be directed at this endpoint.

2) GraphQL is self documenting

Developing big applications, having deadlines, difficult or indecisive clients is a developer's everyday experience and to be honest, sometimes, documenting the APIs isn't the highest priority task. Because of that, developer’s productivity and developer experience (DX) may decrease as more time will be needed to understand what exactly a developer needs, it gets harder to onboard other developers on the project and so on...

GraphQL to the rescue (again) 🎉 GraphQL is self documenting!

Self documenting

GraphQL documentation will keep frontend developers up to date with all the changes that might happen.

3) No more underfetching/overfetching

RESTful APIs assume for us which entity's information should be coupled together as a whole. They don't look at the design of the application.
With that said, frontend developers usually get more information than what they need to display on the screen. This is called overfetching.
On the other hand, some screens need a little extra information that we don’t get with only one GET request. This is called underfetching. To overcome this problem, we will make another request to fetch the data we need.
OK, now we overcame that underfetching problem, but remember that we only needed a little more information, so we are now overfetching again (I can smell an infinite loop here 😅).

GraphQL to the rescue (and again) 🎉 GraphQL lets us query for the data that we actually need!

Send a GraphQL query to your API and get exactly what you need, nothing more and nothing less.

GraphQL is actually a query language (Graph Query Language) and it lets us write our own queries. This way we can look at the given design and decide what information we need to fetch. And it is simple too: queries are written in an object-like syntax where you specify the keys and get back the key-value pairs like on image below:

GraphQL query

4) GraphQL playground

That brings us to GraphQL playground - GraphiQL. GraphiQL is a powerful tool that lets you test your queries, see the response, check out the documentation, schema and types for the needed fields. Everything is typed and it even helps you with autocomplete as a nice finishing touch.
All you need to do is enable GraphiQL in your backend (BE developer will do that) and enter your only endpoint into URL.

Example of a free-to-use Rick and Morty API below:

Rick and Morty GraphiQL

5) Apollo Client

Even though Apollo Client is not the part of GraphQL out of the box, it makes the DX much nicer (...and post title: 4 reasons why Frontend Developers love GraphQL wouldn't be as catchy). Apollo Client most importantly provides us with three easy-to-use custom hooks for manipulating the data: useQuery, useLazyQuery and useMutation.

useQuery - we use it when we need to fetch the data when the component mounts. It returns an object containing data, error if any and loading state.
All you need to pass is a query and options object (if there are variables, anything that needs to be done onCompleted etc.)

const { loading, error, data } = useQuery(SOME_QUERY, options)
Enter fullscreen mode Exit fullscreen mode

useLazyQuery - we use it when we need to fetch the data on some event (for example on search button click). It returns an array containing a function to use on some event and an object with data, error if any, loading state.

const [fetchOnSearch, { error, loading, data }] = useLazyQuery(SOME_QUERY, options)
Enter fullscreen mode Exit fullscreen mode

useMutation - we use it when we need to mutate the data. It returns an array containing a function to which mutates the data and an object with data, error if any, loading state.

const [fetchOnSearch, { error, loading, data }] = useMutation(MUTATION_QUERY, options)
Enter fullscreen mode Exit fullscreen mode

Conclusion

GraphQL was created by Facebook developers and it is used by many big companies which means it is not going anywhere. So, if you are a frontend developer and looking for something new to try out - start with GraphQL, you might fall in love with it! 🥰

...For more in detail information please check the official GraphQL and Apollo Client documentations...

Discussion (4)

Collapse
vladi160 profile image
vladi160
  1. You can use 1 endpoint with REST, too;
  2. There is the same for REST
  3. then don't underfetching/overfetching with REST
  4. Postman
  5. All clients including Apollo client
Collapse
jackmellis profile image
Jack

There are definitely places where graphql is better suited and vice versa. In my experience I have had a few issues with graphql:

  • giving the client control over the query and the return fields means it's very hard to control what data should be publicly available, it's very easy to create huge security holes
  • having one endpoint and then dozens or hundreds of queries/mutations is basically gaining you nothing. It's basically the same as using jsonrpc over rest. You still have the same number of endpoints, they're just concealed under 1 url. It also makes it harder to pick out a specific request from the network tab!
  • I've not had to deal with under-fetching luckily but definitely over-fetching (where the response returns 1mb of data but I only needed 1 field!). However, this is not a problem with rest, rather miscommunication within a team or developer laziness...
Collapse
gethackteam profile image
Roy Derks • Edited on

You'll love it even more after you've generated a GraphQL API from your existing REST API automatically stepzen.com/docs/features/connect-...

Collapse
t0nyba11 profile image
Tony B • Edited on

Sadly, it is a nightmare from a security perspective, with denial-of-service very hard to prevent, and authorization (not authentication) terribly hard to control.