DEV Community

loading...
Cover image for GraphQL - Why you should be using it in 2021.

GraphQL - Why you should be using it in 2021.

Jack Buchanan-Conroy
Front-End Developer & React Contractor at Happy Coding Ltd.
・2 min read

It would seem that every day, more and more companies have been pushing to introduce GraphQL in their modern applications, but what exactly is GraphQL and why should you be using it in your projects in 2021?

What is GraphQL?

GraphQL is a query language for reading and mutating data in APIs. It provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools.

What problems does GraphQL solve?

Traditionally, Front-End Developers have consumed APIs using REST, where data entities exist on a group of URLs on a server. When a request is received the API responds with the full data payload of that entity. Although that sounds simple, there are two big disadvantages here.

The first disadvantage, is that we could need multiple entities at one time, in which case each request is under fetching the actual data we want.

The second disadvantage, is that we may only want a small part of that data (in which case we need to over fetch from the API and that is both costly, and bad for the environment).

GraphQL provides Back-End Developer's with a type system where they can describe a schema for the data, in turn this gives us Front-End Developers the power to explore and request the exact data we need from the API. With GraphQL, instead of multiple URLs an API has a single entry point where data is queried (or fetched) by describing it with a syntax that replicates its return shape in JSON. As Front-End Developers we can describe exactly the data we want while the Back-End Developer writes code to resolve the request. Best of all, everything happens in a syntax that can work agnostically with any programming language.

What is so amazing about types?

GraphQL APIs are organized in terms of types and fields, not endpoints. Using the type syntax in this way allows you to access the full capabilities of your data from a single endpoint. GraphQL uses types to ensure Apps only ask for what’s possible and provide clear and helpful errors. Apps can use types to avoid writing manual parsing code.

Discussion (9)

Collapse
jamesthomson profile image
James Thomson

Can you point to any resource that go through setting things up all the way from backend to frontend? I was really interested in GraphQL a couple years ago, but all the resources I found just talked about how the FE sent queries to the BE. It always felt like how to setup the BE was glossed over/assumed (maybe it's simpler than I think, but my BE dev knowledge is limited).

A common use case I would think would be: How would one transition to using GraphQL with an existing BE already in place?

Collapse
a03z profile image
Daniil

you can check out this website: howtographql.com/

Collapse
jamesthomson profile image
James Thomson

Thank you! This is exactly what I need 🙌

Collapse
jackbuchananconroy profile image
Jack Buchanan-Conroy Author

This is a really great resource :)

Collapse
blackr1234 profile image
blackr1234 • Edited

If you are using Java Spring Boot you could take a look at com.graphql-java-kickstart. It has GraphQL and GraphiQL libraries for Spring Boot Starter.

Collapse
vladi160 profile image
vladi160

You can use a single endpoint and with the standard API, which asks for what you develop it to asks (the exact data) no need of GraphQL for that, nothing unique. A tech used just because it is good to be used, but nobody knows why ;)

Collapse
stradivario profile image
Kristiqn Tachev • Edited

Also you can check one framework that i build for scalable graphql api's

github.com/Stradivario/gapi

And here is some starter frontend side with LitHTML and connected to SpaceX API

github.com/rxdi/starter-client-sid...

Regards!

Collapse
urielfrankel profile image
Uriel Frankel

Sorry Jack, but I tend to disagree. It doesn't worth the pain, IMHO. The client side has to hussle with the complexity of the backend. If you have Android ,ios, and react, you tripple the burden. BTW, something I learned recently, you can't use mutation and query at the same request.

Collapse
mariomeyrelles profile image
Mario Meyrelles

Hey Uriel, can you give a concrete example of this?

To be fair, I agree that the toolling for graphql is indeed immature in many aspects (troubleshooting requests for example). But the main idea of asking the backend for only what you need is very interesting to be ignored, even on mobile.