Translation: Crazy geek

Medium.freecodecamp.org/why-graphql…

Since the Web has exploded, developing apis has been a daunting task for programmers. The way we develop our apis must evolve over time so that we can always develop good, intuitive, and well-designed apis.

GraphQL has become increasingly popular with developers over the past few years. Many companies are already adopting this technique to build their apis. GraphQL is a query language developed by Facebook in 2012 and publicly released in 2015. It has received a lot of attention and has been adopted by many big companies, such as Spotify, Facebook, GitHub, NYTimes, Netflix, walmart, etc.

In this series of tutorials, we’ll explore GraphQL, learn what it is, and learn what makes this query language so intuitive and easy to use.

Let’s take a look at REST’s problems and how GraphQL solves them. We’ll also learn why big companies are building apis with GraphQL and why it’s the future of apis.

REST

A long time ago, when we switched our API design from SOAP to REST, we thought this would provide more flexibility for our work. We can’t deny that REST worked well and was a good move at the time. But as applications and the Web become more complex, apis evolve with these changes.

REST does have a lot of problems, though. Let’s see what they are:

Too many endpoints

Every resource in REST is represented by an endpoint. Therefore, in a real program, we would end up providing a large number of endpoints for these resources. If you want to make a GET request, you need to have specific parameters and be specific to the endpoint of the request. If a POST request is to be made, another endpoint of the request is required.

But what’s wrong with that? Let’s say we’re developing a large social media application like Facebook, and we end up with many endpoints, which means that developing and maintaining these apis will take more time and effort.

Over-access and lack of information

The real annoyance is the over-availability and lack of information through REST apis. This is because REST apis always return fixed structures. Unless we create a specific endpoint, we won’t be able to get exactly the data we need.

So if we only need a small piece of data, we have to deal with the whole object. For example, if we only need to get the user’s firstName, lastName, and age in the REST API, we can’t get this data without getting the whole object.

Lack of information is also a problem. If we want to get data from two different resources, we need to make calls to two different endpoints. In a huge program, scalability is poor because in some cases we only need to fetch specific data, not the whole object. Suppose we are developing a program with 100 endpoints. Imagine the effort and the amount of code generated. As time goes on, development becomes more difficult, the code becomes harder to maintain, and the programmer gets lost.

Version control

One pain point in REST, in my opinion, is version control. With REST apis, it’s common to see many apis with v1 or V2. This is not needed in GraphQL because you can improve the API by adding or removing types.

In GraphQL, all you need to do is write new code. You can write new types, queries, and modifications without having to maintain other versions of the API.

So you won’t see the GraphQL API with endpoints like this:

https://example.com/api/v1/users/12312
https://example.com/api/v2/users/12312
Copy the code

Why is GraphQL the future

Back in 2012, Facebook had a problem developing mobile apps that led them to create GraphQL. These questions are very common, especially when we’re talking about RESTful API design. As mentioned above, the questions are:

  • Poor performance
  • The endpoint too much
  • Excessive acquisition or lack of data
  • Every time we add or remove something, we need to develop another version
  • The API is hard to understand

With many concepts in mind, the Facebook developers took a better approach to designing the API, which they later named GraphQL. It’s basically a replacement for REST, with a lot of improvements.

Using GraphQL, we can get a lot of new functionality that gives you a lot of power when building apis. Let’s take a look at them one by one:

A single endpoint

There’s no need to build a lot of endpoints! GraphQL requires only one endpoint, through which we can get as much data as possible in a single request. Basically GraphQL encapsulates all of your queries, modifications, and subscriptions in one endpoint for you to call. It improves your development cycle because you don’t have to make requests to two different sources to get data. In addition, when we develop a large application, we don’t have to have as many endpoints and code as REST does. We just need to get one endpoint and develop as many requests as we need.

As I said above, the “single endpoint” approach makes your API self-describing, and you no longer need to build documentation because your programmers already know how to use it. They can learn about the API simply by looking at the code. We’ll look at this in more detail later (the next tutorial in this series). It looks amazing, but that’s GraphQL!

With GraphQL, you can only get the data you need

There is no over-access or under-use of information, you just get the data you need. Remember our initial discussion of performance? It won’t be like that anymore, because GraphQL improves the performance of the API, especially when network connections are slow.

GraphQL makes developing apis easy and consistent

Many people think GraphQL is very complex because it involves schemas and a single endpoint. But once you start developing apis with it, it’s a lot easier than you think. When you’re developing a website or application, a “single endpoint” API can help you a lot. It makes your API more self-describing and doesn’t require extensive documentation for it.

If you don’t use JavaScript as your primary language, that’s not a problem. GraphQL is a query language, which means you can use any language you’re familiar with. At the time of writing this tutorial, GraphQL supports over 12 languages.

GraphQL is the future

GraphQL is an open source query language, which means the community can contribute to it and improve on it. When Facebook released it to the community, there was a lot of acceptance. Now GraphQL is growing rapidly as more and more programmers build apis with it. But some people have been asking if it’s really going to replace REST, or become the new way to build apis.

At first, I thought GraphQL was hype, just another way to create aN API. But when I started looking into it, GraphQL had the basic capabilities needed to create apis for modern applications, because it fits well into today’s technology stack.

So if I had to say something to you, I’d say: Yes, GraphQL is really the future of apis. That’s why big companies are betting on it.

In November 2018, GraphQL partnered with the Linux Foundation to create a GraphQL Foundation. This query language encourages its developers to create more documentation, tools, and language support. This will ensure GraphQL’s stable, neutral and sustainable future. So that’s another reason to see GraphQL as the future of apis.

Of course GraphQL won’t immediately replace REST, as many applications still use it, and it won’t be possible to rewrite them overnight. Both UX and DX will improve as more companies adopt GraphQL.

conclusion

GraphQL is really the future of apis, and we need to learn more. That’s why I decided to write a series of tutorials that will show you how to use GraphQL well, starting with queries and modifications, followed by subscriptions and authentication.

In the next tutorial in this series, I’ll dig into GraphQL, show how it works with types, and create our first queries and modifications.

So stay tuned and hope to see you in the next tutorial!

Welcome to pay attention to the public number: front-end pioneer, get more front-end dry goods.