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.
Top comments (10)
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?
you can check out this website: howtographql.com/
Thank you! This is exactly what I need 🙌
This is a really great resource :)
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.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 ;)
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.
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.
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!
Do i get it right, that first you select the WHOLE entity, that can take pretty long in case of multiple oneToMany, ManyToOne fields, then spring graphql returns only the requested fields? What is the benefit? The speed of generating a small graphql based json request response instead of a large REST response?