Meeting GraphQL at a Cocktail Mixer

REST and GraphQL are two specifications for building website APIs. REST defines a series of unique identifiers (URLs) that applications use to request and send data. GraphQL defines a query language that allows client applications to specify exactly the data they need to fetch from a single endpoint. They are related techniques for roughly the same things (in fact, they can and often coexist), but they are also very different.

Let's explain it in a more interesting way, which may help you understand better and may make you a little excited about GraphQL!

? You're at a cocktail party

You attend this cocktail party to expand your professional connections, so naturally, you want to collect some data about the people around you. There were five other attendees nearby.

Their name tag says:

• Richy REST
• Richy REST's Friends
• Richy REST's employer
• Georgia GraphQL

As your energetic, social, and outgoing nature, you walked straight to Richy REST and said, "Hello, I am Adam Application, who are you?" Richy REST replied:

 <code>{ name: "Richy REST", age: 33, married: false, hometown: "Circuits-ville", employed: true // ... Richy REST的其他20条信息}</code>

"Wow, there's so much information," you thought to yourself. To avoid any awkward silence, you remember Richy REST mentioned that he was hired and asked, “Where are you working?”

Strangely, Richy REST doesn't know where he works. Maybe Richy REST's employer knows?

You asked the Richy REST employer the same question and he would be happy to answer your inquiry! He answered this way:

 <code>{ company: "Mega Corp", employee_count: 11230, head_quarters: "1 Main Avenue, Big City, 10001, PL" year_founded: 2005, revenue: 100000000, // ... Richy REST雇主的其他20条信息}</code>

At this time, you are exhausted. You don't even want to meet Richy REST's friends! That can take a long time, drain all your energy, and you don't have time.

However, Georgia GraphQL has been standing there politely, so you decided to communicate with her.

"Hello, what's your name?"

 <code>{ name: "Georgia GraphQL" }</code>

"Where are you from, how old are you?"*

 <code>{ hometown: "Pleasant-Ville", age: 28 }</code>

"How many hobbies and friends do you have, what is your friend's name?"

 <code>{ hobbies_count: 12, friends_count: 50, friends: [ { name: "Steve" }, { name: "Anjalla" }, // ...等等] }</code>

Georgia GraphQL is awesome, clear, concise and to the point. You want to exchange business cards with her and work with her in future projects.

This story sums up the experience of developers using GraphQL instead of REST. GraphQL allows developers to express their needs with concise queries and only receive content they specify—no more or less. These queries are completely dynamic, so only one endpoint is required. On the other hand, REST has a predefined response and often requires the application to use multiple endpoints to meet the full data needs.

The metaphor ends! Let's talk about the key points.

To further elaborate on the basic concepts proposed in cocktail party metaphors, let us discuss in detail two limitations that often appear when using REST.

1. Multiple requests are required when obtaining related resources

Data-driven mobile and web applications often require relevant resources and data sets. Therefore, retrieving data using the REST API may require multiple requests to multiple endpoints. For example, requesting Post entities and related authors may need to issue two requests to different endpoints:

 <code>someServer.com/authors/:id someServer.com/posts/:id</code>

Multiple access to the API can affect the performance and availability of your application. This is also a more important issue for low bandwidth devices (such as smartwatches, Internet of Things, older mobile devices, etc.).

2. Over-acquisition and insufficient data acquisition

Over-fetching and insufficient data acquisition are inevitable when using the RESTful API. Using the example above, the endpoint domainName.com/posts/:id gets the data for a specific Post. Each Post consists of attributes, such as id, body, title, publishingDate, authorId, etc. In REST, the same data object is always returned; the response is predefined.

In cases where only the Post title and body are needed, over-retrieval of data occurs - because more data is sent to the network than is actually used. When data related to the entire Post and its author is needed, insufficient data acquisition occurs - because less data is sent to the network than actually used. Insufficient data acquisition can lead to excessive bandwidth usage due to multiple requests to the API.

Client query using GraphQL

GraphQL introduces a truly unique approach that provides great flexibility for client applications. Using GraphQL, the query is sent to your API and returns only what you need—no more or less—in a request. The query results are returned in the same shape as your query, ensuring that the response structure is always predictable. These factors allow applications to run faster and more stable because they can control the data they get, not the server.

"The result is returned in the same shape as the query."

 <code>/* 查询*/ { myFriends(first: 2) { items { name age } } }</code>

 <code>/* 响应*/ { "data": { "items": [ { "name": "Steve", "age": 27 }, { "name": "Kelly", "age": 31 } ] } }</code>

Reality test✅

Now, you might think GraphQL is as easy as cutting hot butter with a samurai knife. For front-end developers, this may be a reality – especially those who use the GraphQL API. However, when it comes to server-side setup, someone has to make sausages. Our friend Georgia GraphQL put a lot of effort into becoming such an outstanding professional she is now!

Building a GraphQL API (server side) takes time, effort, and expertise. That said, it’s not something that can’t be handled for those ready to face the challenge! There are many different ways to get involved at all levels of abstraction. For example:

• No helper: If you really want to do it yourself, you can use the software package to build the GraphQL API. For example, like Rails? Check out graphql-ruby. Like Node.js? Try express-graphql.
• Assistant: If fully maintaining your server/self-hosting is a priority, something like Graph.cool can help you start a GraphQL project.
• Instant: Tired of writing CRUD boilerplate code, want to get started quickly? 8base provides an instant GraphQL API and serverless backend, which is fully scalable.

Summarize

REST has brought great progress to web services by enabling highly available resource-specific APIs. That is, it is designed without taking into account the surge in today's interconnected devices, all of which have different data limitations and requirements. This oversight quickly led to the popularity of GraphQL (open sourced by Facebook in 2015) as it provides great flexibility for front-end developers. Using GraphQL is a great development experience, both for individual developers and teams.

The above is the detailed content of Meeting GraphQL at a Cocktail Mixer. For more information, please follow other related articles on the PHP Chinese website!