开源软件名称（OpenSource Name）：

开源软件地址(OpenSource Url)：

开源编程语言(OpenSource Language)：

开源软件介绍(OpenSource Introduction)：

Companion Source for the course: GraphQL for Beginners with JavaScript

Why should I learn GraphQL?

Everyone knows, you should use the right tool for the job… But often, what was the “right” tool, becomes the inferior tool, and you might not even notice.

The most popular way of talking to servers today, is using REST. REST offers a nice, easy to understand way of interacting with other servers, but think about this: Rest was introduced about 2 decades ago… That’s a long time in our world!

Let me ask you a question: how much has software development changed in 2 decades? Heck, how much has software development changed in 2 years? A LOT!

So, I think it’s fair to ask the following question:

Do REST api’s still make sense, considering how we write software today?

To answer this question, let’s look at some of the problems with REST API’s:

Problem - Many Concurrent Requests

Many/Most non-trivial applications, make lots of concurrent rest api calls, before they can even render a view… Why is this a problem? It might not be a problem, if the client has an excellent network connection (like our dev machines do), but it can be a horrible problem, on mobile devices with poor connections.

When mobile devices make many concurrent network requests, the response is often very slow, and the app might seem unresponsive and it may not work at all. This can result in a dismal user experience.

So, should you care about mobile devices? Well, the majority of web traffic, comes from mobile devices, which often have poor network connections… and the next Billion internet users, will primarily be smart phone users, are you thinking about them?

"Does GraphQL suffer from this problem?"

Nope, GraphQL allows you to avoid this connection heavy behavior, by combining all your data queries, into a single server request, which greatly improves real and perceived performance.

Problem - Multiple round trips to the server (Under-fetching Data & N+1 Problem)

Sometimes, you’re app needs to fetch some initial data from the server, then you might need to make subsequent requests, based on the initially returned data. This results in a slow app, and it can be a real server performance killer.

"Does GraphQL suffer from this problem?"

Nope, with GraphQL, you avoid this type of “chatty” communication, because GraphQL allows you to perform rich queries, that fetch exactly what you need in one round trip, and you’ll avoid the N+1 problem, that can kill your servers performance.

Problem - Over-fetching Data

Often, REST apis give you more data, then you need. For example, maybe you just need an items description and price, but the API gives you all 80 properties of the item. You end up taxing your servers and clients, dealing with data/bandwidth that’s not needed, which results in degraded application performance.

"Does GraphQL suffer from this problem?"

Nope, with GraphQL, you won’t fetch data, that you don’t need, instead you create explicit queries, asking for exactly what you need, and the graphQL server provides just what’s needed.

Problem - Discoverability & Documentation

Imagine you’re a new employee, and you’re trying to figure out what your companies existing REST api’s have to offer. This can be quite a challenge. If your lucky, people are maintaining documentation on the api, but more often, you’ll need to ask someone, or dig through the code, just to figure out what's available.

"Does GraphQL suffer from this problem?"

Nope, figuring out a GraphQL API is easy.

How’s this possible?

Many of the features in GraphQL, allow the creation of excellent developer tools such as GraphiQL and Insomnia. Tools like these, greatly improve API discoverability, which you'll learn in this course.

With GraphQL, new employees can quickly and easily figure out what the api offers, almost completely on their own.

Problems - Slow Development

It sucks when you have to wait on other people, to complete your job. Countless times I’ve been blocked on a task, waiting on a backend developer. This interruption really sucks when I'm in a flow state.