Học về GraphQL

Học Integration of GraphQL with Angular và Drupal 9

admin — Sun, 08 May 2022 04:23:54 +0000

Học Integration of GraphQL with Angular và Drupal 9 admin Sun, 05/08/2022 - 06:23

Tập tành viết Graphql Server trong Drupal Using graphql-php

admin — Fri, 06 May 2022 09:47:19 +0000

Tập tành viết Graphql Server trong Drupal Using graphql-php admin Fri, 05/06/2022 - 11:47

GraphQL is the better REST with 1 API Endpoint

admin — Fri, 06 May 2022 09:19:50 +0000

GraphQL is the better REST with 1 API Endpoint admin Fri, 05/06/2022 - 11:19

GraphQL is the better REST

Over the past decade, REST has become the standard (yet a fuzzy one) for designing web APIs. It offers some great ideas, such as stateless servers and structured access to resources. However, REST APIs have shown to be too inflexible to keep up with the rapidly changing requirements of the clients that access them.

GraphQL was developed to cope with the need for more flexibility and efficiency! It solves many of the shortcomings and inefficiencies that developers experience when interacting with REST APIs.

To illustrate the major differences between REST and GraphQL when it comes to fetching data from an API, let’s consider a simple example scenario: In a blogging application, an app needs to display the titles of the posts of a specific user. The same screen also displays the names of the last 3 followers of that user. How would that situation be solved with REST and GraphQL?

Check out this article to learn more about why developers love GraphQL.

Data Fetching with REST vs GraphQL

With a REST API, you would typically gather the data by accessing multiple endpoints. In the example, these could be /users/<id> endpoint to fetch the initial user data. Secondly, there’s likely to be a /users/<id>/posts endpoint that returns all the posts for a user. The third endpoint will then be the /users/<id>/followers that returns a list of followers per user.

With REST, you have to make three requests to different endpoints to fetch the required data. You’re also overfetching since the endpoints return additional information that’s not needed.

In GraphQL on the other hand, you’d simply send a single query to the GraphQL server that includes the concrete data requirements. The server then responds with a JSON object where these requirements are fulfilled.

Using GraphQL, the client can specify exactly the data it needs in a query. Notice that the structure of the server’s response follows precisely the nested structure defined in the query.

No more Over- and Underfetching

One of the most common problems with REST is that of over- and underfetching. This happens because the only way for a client to download data is by hitting endpoints that return fixed data structures. It’s very difficult to design the API in a way that it’s able to provide clients with their exact data needs.

“Think in graphs, not endpoints.” Lessons From 4 Years of GraphQL by Lee Byron, GraphQL Co-Inventor.

Overfetching: Downloading superfluous data

Overfetching means that a client downloads more information than is actually required in the app. Imagine for example a screen that needs to display a list of users only with their names. In a REST API, this app would usually hit the /users endpoint and receive a JSON array with user data. This response however might contain more info about the users that are returned, e.g. their birthdays or addresses - information that is useless for the client because it only needs to display the users’ names.

Underfetching and the n+1 problem

Another issue is underfetching and the n+1-requests problem. Underfetching generally means that a specific endpoint doesn’t provide enough of the required information. The client will have to make additional requests to fetch everything it needs. This can escalate to a situation where a client needs to first download a list of elements, but then needs to make one additional request per element to fetch the required data.

As an example, consider the same app would also need to display the last three followers per user. The API provides the additional endpoint /users/<user-id>/followers. In order to be able to display the required information, the app will have to make one request to the /users endpoint and then hit the /users/<user-id>/followers endpoint for each user.

Rapid Product Iterations on the Frontend

A common pattern with REST APIs is to structure the endpoints according to the views that you have inside your app. This is handy since it allows for the client to get all required information for a particular view by simply accessing the corresponding endpoint.

The major drawback of this approach is that it doesn’t allow for rapid iterations on the frontend. With every change that is made to the UI, there is a high risk that now there is more (or less) data required than before. Consequently, the backend needs to be adjusted as well to account for the new data needs. This kills productivity and notably slows down the ability to incorporate user feedback into a product.

With GraphQL, this problem is solved. Thanks to the flexible nature of GraphQL, changes on the client-side can be made without any extra work on the server. Since clients can specify their exact data requirements, no backend engineer needs to make adjustments when the design and data needs on the frontend change.

Insightful Analytics on the Backend

GraphQL allows you to have fine-grained insights about the data that’s requested on the backend. As each client specifies exactly what information it’s interested in, it is possible to gain a deep understanding of how the available data is being used. This can for example help in evolving an API and deprecating specific fields that are not requested by any clients any more.

With GraphQL, you can also do low-level performance monitoring of the requests that are processed by your server. GraphQL uses the concept of resolver functions to collect the data that’s requested by a client. Instrumenting and measuring performance of these resolvers provides crucial insights about bottlenecks in your system.

Benefits of a Schema & Type System

GraphQL uses a strong type system to define the capabilities of an API. All the types that are exposed in an API are written down in a schema using the GraphQL Schema Definition Language (SDL). This schema serves as the contract between the client and the server to define how a client can access the data.

Once the schema is defined, the teams working on frontend and backends can do their work without further communication since they both are aware of the definite structure of the data that’s sent over the network.

Frontend teams can easily test their applications by mocking the required data structures. Once the server is ready, the switch can be flipped for the client apps to load the data from the actual API.

Category

Học về GraphQL

Image

Tags

Làm Web với Django

Background image

Add new comment

Base Format for GraphQL trong Drupal 9

admin — Fri, 06 May 2022 09:05:38 +0000

Base Format for GraphQL trong Drupal 9 admin Fri, 05/06/2022 - 11:05

Tập tành học GraphQL and Twig trong Drupal 9

admin — Thu, 05 May 2022 14:10:49 +0000

Tập tành học GraphQL and Twig trong Drupal 9 admin Thu, 05/05/2022 - 16:10

This session will present a beginner’s guide and demo on how to use GraphQL. Decoupled Drupal is the future, but learning an entirely new stack can be daunting. Writing GraphQL inside Twig templates gives developers a path to an accessible soft-decoupled approach. This session will introduce GraphQL queries and demonstrate the advantages of changing the Drupal push model to a pull model by letting the template define its data requirements

Data, database, data fetching, data requests, data retrieving, data receiving... all modern web apps — fully or progressively decoupled front-end applications — have an insatiable “appetite” for data. And satisfying this particular “hunger”, with no compromise on performance, is the “mission” that GraphQL on Drupal 8 — the module — has been invested with.

Retrieving the requested data with as little time and resources used on round trips to the server as possible. With no under- or over-fetching, with no need for versioning.

In short: the module “exploits” all the limitations that the Restful approach started to show in addressing well-known data issues; it came out as a result of Dries Buytaert's advice and forecast on advancing Drupal's web services.

But let's not beat around the bush anymore and dive right in:

GraphQL This... GraphQL That... But What Is GraphQL After All?

It's Facebook's patented technology created in 2015.

And app layer query language designed to revolutionize the way data gets retrieved, interpreted and formatted: all these processes take place based on a GraphQL schema!

Approaching the data in terms of graphs and exposing those graphs in a schema guarantees that the caller's data request is identically structured as the delivered answer.

Not to mention that the same caller gets to formulate his data requests more explicitly and specifically thanks to GraphQL.

No wonder that front-end Drupal developers have started to perceive it as a powerful rival to REST! To the standard REST approach to retrieving data in apps built with headless Drupal 8.

In this respect, let's briefly recap just some of its “luring” features:

it perfectly matches the data request's structure with that of the delivered response
it queries the requested data based on s self-documented, automatically generated data exposure schema

GraphQL & Drupal: A Duo Powering The Future of Decoupled Drupal

Take GraphQL as the intermediary used in decoupled Drupal projects between the JavaScript front-end and the Drupal back-end. The one invested with the role of smoothing and streamlining the interaction of the decoupled front-end with the Drupal data source.

A role that used to be played, in all Drupal decoupled apps, exclusively by the RESTful web services, remarkably well developed in Drupal 8. Till the traditionally used REST architecture started to prove its failure in addressing data access issues.

And GraphQL on Drupal 8, the dedicated GraphQL module, started being built.

The improved overall performance, that this new approach to retrieving data promises, derives from:

GraphQL's way of retrieving data based on a schema
its entire system of types and fields

… which guarantees predictable responses only (the client-side apps are enabled to request for specific data) and, implicitly: no round trips and no extraneous data.

A responsible use of server resources.

Moreover, in case of complex, hierarchical data, not only that the caller gets to shape a “straight to the point” request, but it gets to ask for all the needed data on the same query!

An efficient use of server power especially when your decoupled Drupal app's front-end requests loads of data in a context of slow mobile internet connection.

GraphQL on Drupal 8: Your Data Graph Conveniently Exposed in a GraphQL Schema

And then... the GraphQL module was born!

Not yet part of the Drupal core, but powerful enough to allow front-end Drupal developers to use it to its full potential in their decoupled Drupal projects.

The main “mission” that its maintainer, Sebastian Siemssen, invested it with was: to turn Drupal into a GraphQL-powered data hub for decoupled front-end apps, by implementing a schema. A GraphQL schema exposing the available field types and entity.

Practically via TypedData API your Drupal 8 site's data graph becomes more “readable” for the GraphQL library.

This way, the client-side app gets to request for more than specific data/field values and to receive precisely the required info. And this streamlined data fetching process with GraphQL on Drupal 8 can only lead to zero bloated responses.

There's more!

We can't be talking about “a” module, but a whole ecosystem of submodules that you can read more about on Drupal GraphQL Github:

GraphQL Content
Entity Reference
Breadcrumbs
Boolean
Content Mutation
Link
Image
Menu
File
Block
Views

Have you already harnessed the full potential of GraphQL on Drupal 8 to fuel your web apps with? If not, why hesitate?

Why do you still think it might not be a robust enough alternative to the traditional REST approach to data fetching?

Category

Học về GraphQL

Image

Tags

Quyết tâm học tập

Add new comment

Học tập Drupal Graphql with Angular từ Lars Soonvald

admin — Thu, 05 May 2022 13:08:35 +0000

Học tập Drupal Graphql with Angular từ Lars Soonvald admin Thu, 05/05/2022 - 15:08

Drupal is a renowned name when it comes to website development. The kind of features and control it allows you to have on your content is quite impressive. The traditional Drupal architecture has repeatedly proven to be valuable and now it is the time for Decoupled Drupal architecture to do the same, which it is on the path of doing. A major reason for the increasing popularity and adoption of the decoupled Drupal is the freedom to make the front-end using the technologies you like.

Since the Decoupled Drupal architecture separates the presentation layer from the backend content, an API becomes the thread that holds the two together to work in sync. So, it is important to choose the right one for your project. While REST API and JSON: API are quite sought after, GraphQL has also emerged as a front runner. So, let us find out what exactly GraphQL is, what it can do and how it plays in the Decoupled Drupal architecture’s picture.

The GraphQL

GraphQL, a query language, came into being about eight years ago, however, its popularity came through in 2016, when it was made open-source. Its founder, Facebook, created a unique API because they needed a program to fetch data from the entirety of its content repository. It is a system that is easy to learn and equally easy to implement, regardless of the massive proportions of data you may have or the massive number of sources you may want to go through.

When I said that GraphQL is a query language, I meant just that. It is a language that will answer all your queries for data using its schema, which can easily be deployed using GraphiQL, an Integrated Development Environment. GraphQL, being a language specific for APIs, is equipped to manipulate data as well with the help of a versatile syntax. The GraphQL syntax was created in a way that it is able to outline the requirements and interactions of data to your particular needs. The shining glory of GraphQL is that you only get what you have asked for, nothing more, nothing less. This means that the application will only work towards retrieving data that is of the essence in the request. The data might have to be loaded from varying sources, but it will still be accurate and precise, succinct to the T and exactly what you sought.

With decoupling becoming a need now more than ever and content and presentation layers segregating from each other, GraphQL becomes the answer for all data queries, essentially becoming the answer for data retrieval for your API and your web application. A query language and a runtime to fulfil every query within your existing data, GraphQL is powered to paint a complete and totally understandable description of your data using the API. Its robust developer tools have proven to make APIs faster, more flexible and extremely friendly to our developer friends. Therefore, achieving decoupling becomes extremely easy as GraphQL provides typed, implementation agnostic contracts amongst systems.

GraphQL vs JSON:API vs REST API

The power and assistance of APIs have become all the more conspicuous in the decoupled world. With three prominent names taking the lead here, it becomes somewhat tricky to get to the right API conclusion. GraphQL, JSON:API and REST API, all three have their own virtues making them great at whatever they intend to do. However, it becomes almost impossible to talk about one and ignore the other two. My writing would not have been complete without a comparison of the three.

If you look at the core functionality of these three APIs, you will realise that GraphQL and JSON: API are much more similar to each other than REST API, which is a whole other ball game compared to them. Let us look at them.

Let us look at them.

Parameters	GraphQL	JSON: API	REST API
How much data is retrieved?	Does not over-fetch data	Does not over-fetch data	Inundates the user with unnecessary proportions data
How is the API explored?	Has best API exploration due to GraphiQL	Uses a browser to explore the API	Relatively does not perform well and the navigable links are rarely available
How is the schema documentation?	Perfect auto-generated documentation and reliable schema	Depends on OpenAPI standard and JSON:API specification only defines generic schema	Depends on OpenAPI standard
How do the write operations work?	Write operations are tricky	Write operations come with complete solutions	Writes can become tedious with multiple implementations
How streamlined it can be during installation and configuration?	Provides numerous non-implementation specific developer tools but is low on scalability and security	Provides numerous non-implementation specific developer tools and is high on scalability and security	Provides numerous tools, but they require specific implementations and come with good scalability and high security

GraphQL

With GraphQL and its distinct fields of query, the developer is asked to specify each and every desired resource in these fields. You might be wondering why? The answer lies in its exactness. It is because of these explicitly mentioned desires that GraphQL never over-fetches data.

Coming to API exploration, GraphQL takes the cake for being the simplest and most conclusive. The fact that a GraphQL query comes with suggestions that can be auto-completed justifies my earlier claim. Moreover, the results are shown alongside the query resulting in smooth feedback. Its in-house IDE, GraphiQL, also helps in generating iterations of the queries, aiding the developers even more.

If you told me that GraphQL specifications are more equipped at handling reads than writes, I would not object to you. Its mutations require you to create a new custom code every time. You can probably tell how much of a hassle it can be. Regardless, GraphQL can easily support bulk write operations that have already been implemented.

In terms of scalability, GraphQL requires additional tools to capitalise on its full potential and there are certainly numerous developer tools made available, and all of them are not implementation-specific.

JSON: API

The problem of over-fetching is not witnessed with JSON:API as well. Its sparse fieldsets produce an output similar to GraphQL. However, unlike GraphQL’s uncacheable requests, JSON: API can omit the sparse fieldsets when they become too long and hence, can cache even the longest requests.

With JSON: API, the explorations are simple as well; as simple as browsing within a web browser, which is basically what the API acts like here. From scouring through different resources to different fields and debugging, you can do all of that with your browser. Can data retrieval be simpler?

In terms of writings, JSON: API is probably the best out of the bunch. It offers a wholesome solution for handling writes by using POST and PATCH requests. Even though bulk support is not available at the moment, it is in the works and would soon be in use.

JSON: API is again similar to GraphQL as it also provides various developer tools that are not implementation-specific. The fact that its infrastructure resembles that of a website, requiring Varnish and CDN, makes it different from the former.

REST API

REST API has probably the most over-fetching system going on. Not only does it mandate multiple requests for one piece of content, it would also give you responses that are often even beyond the threshold of verbose. And the data that you end up with is so much more that you asked and needed.

Again, REST API is completely different from the other two in terms of data exploration. And sadly, this isn’t a good kind of different. REST API is highly dependent on an OpenAPI standard, and if you are not adhering to that, things would seem a tad bleak for you. You will not be able to trust it for an auto-generated documentation or a validatable and programmable schema. The navigation through high volumes of data seeking interactivity is not too impressive either.

Writing data in REST API is quite easy, almost as easy as reading it. Using POST and PATCH requests, every implementation is unique. Bulk support is not on the table.

REST API’s infrastructural needs also resemble that of an ordinary website encompassing Varnish or CDN. However, its additional tools, although many, mandate customisation before implementation.

The GraphQL and Decoupled Drupal Dynamic

GraphQL is a language that is undergoing developments as I am writing and you will be reading, but that does not mean that it is unstable. Moreover, GraphQL is being capitalised by several Drupal websites. The exactness in responses along with the always available introspection layer makes GraphQL truly worth it.

Let us now understand how it is the perfect answer to Decoupled Drupal by asking all the right questions or shall I say queries?

How does Drupal fully capitalise GraphQL?

Drupal can be rigid, it is a fact all of us know. Apart from this, Drupal can also seem to be too much with everything it has to offer. What GraphQL does is, it gives you the ability and the power to create and expose a custom schema that would eventually become the only roadway to all the data; information, operations and interactions, whatever happens within the system. And then, Drupal does not seem to be too rigid.

You get a GraphQL module in Drupal which is designed around webonyx or graphql-php. What this means is that the module is basically as jam-packed with features as the actual language is with all the GraphQL specifications.

The module can be used as the basis for creating your very own schema by generating a custom code;
The module can also be used to extend the already existing schema with the use of the plugin architecture, wherein the plugin would act as the sub-module.
To aid development even more, GraphiQL is also included at /graphql/explorer, which acts as a user interface for you.
Lastly, there are built-in debugging tools that are competent to issue queries and analyse their responses and that too in real time.

GraphQL is a powerful tool and Drupal has ensured that all its community can easily tap into its power.

The GraphQL Twig module is the next advancement in Drupal. It was and generally is thought that GraphQL queries can only be sent over HTTP, but that isn't true. It can be, but there are other ways as well and this module personifies that. You can segregate the Twig templates from the internal structures of Drupal, so that maintenance and reuse is easier without any involvement of HTTP.

Should we use GraphQL or JSON:API or REST in Drupal?

Before getting into why GraphQL, we have to understand why not REST and what are its limitations. First of all, REST UI is absolutely important to set up the REST module in Drupal. Not to forget, it can be pretty arduous to configure it. In addition, the primary problem with REST is that it over fetches information, bombarding you with data you do not even need and certainly did not ask for. You might have just needed the title of an article, but the author’s user id is also included in the response list. This leads to a cycle of follow-up queries and you end up with the article’s title, link, its author’s name, his information and the entire content of the said article. Over-fetching is putting it lightly.

Because GraphQL uses the APIs in a more simplistic way, it becomes better than REST endpoints. The former does not expose single resources with fixed data structures and links between them, rather it provides you the opportunity to request any selection of data that you may need. You can easily query multiple resources on the server side simultaneously, consequently combining the different pieces of data in one single query. Hence, your work as a front-end developer becomes as easy as pie. You could still go for REST, if you wanted, it does have its own set of merits

Now coming to choosing between JSON: API and GraphQL, this is a more difficult choice to make. These two perform at a level parallel to each other. For instance, installing the JSON: API module is a piece of cake with absolutely no configuration required. As for GraphQL, the installation is easy as well, but there is a need for some configuration.

Do you see why I said the choice was difficult?

Where decoupling is concerned, JSON: API and GraphQL are much better than REST. Server-side configuration is not required by the clients to perform content queries. While JSON: API has the default setting of altering every client-generated query, GraphQL mandates the permissions to be held by the consumer so that he can forego any access restrictions. There is no right or wrong method here, both have the right filtering tools for decoupling and both are security for your content.

When is the GraphQL module the most suitable?

Only fetching the data that is asked for should be the tagline of GraphQL and that is why in scenarios where you need data retrieval, it becomes quite handy.

Decoupled Drupal applications, with Drupal as the content repository and a React, Angular or Ember powered front-end.
Mobile applications, wherein data storage is the need of the hour.
Internet of Things data storage.
If you want to retrieve the JSON data from Drupal.
And also if you plan to use the Twig Templates in Drupal themes.

The GraphQL module would be perfect in all of these instances.

Why do GraphQL and Drupal fit so well?

GraphQL is considered to be an excellent fit for Decoupled Drupal websites, especially if they comprise entities as fields for stored data and these fields have relationships with other entities. GraphQL helps you curate queries for just the fields you need from the Article. This kind of flexibility makes it easy to restructure an object you wanted back, helping you to change the display as well. You can write queries, add or remove fields from the results and you can do all of this without writing a code on the backend. The GraphQL module’s ability to expose every entity including pages, users and customer data makes all of this seem quite simple. So, it would be suffice to say that the decoupling experience would not be the same without GraphQL.

Has GraphQL impacted the conventional server-client relationship?

Traditionally, the server was the dominant in the server-client relationship, however, now the client holds more power and GraphQL has made certain of this. With it, the client need not follow everything the server imposes, it can simply enunciate its needs on a per-request basis. After the server would show the data possibilities it is equipped to fulfil, it would be extremely easy for the client to define its needs with the catalogued possibilities at the forefront. The shape of the values GraphQL API inserts and returns is every bit the same.

On top of these, GraphQL taps into the deeply nested relational data structures, which are suitable for graph models. The abilities of GraphQL schema and query validation ensures that it can prevent distributed denial-of-service attacks, thereby preventing attempts at overloading queries. The benefits of GraphQL in Drupal are indeed far and many.

What Will the Future Look Like?

GraphQL is not a part of Drupal Core, being an advanced tool that is a little more complex to use. The future is not showing any signs of it becoming one either. However, there are other aspects to look forward to. GraphQL v4 for Drupal is one of the most awaited releases of the GraphQL module. It would bring along numerous improvements for the module that seems to be perpetually evolving. GraphQL schema will be in total control of Drupal developers, since schema customisation was the holy grail of this module, things are looking up and the future brighter. GraphQL and Drupal have a long way to go.

Category

Học về GraphQL

Image

Tags

Quyết tâm học tập

Add new comment

GraphQL3.1 On Drupal 9.1.4

admin — Thu, 05 May 2022 09:49:58 +0000

GraphQL3.1 On Drupal 9.1.4 admin Thu, 05/05/2022 - 11:49

Drupal 9.1.4 - GraphQL3.1 interacting with external database using graphql views and graphql_twig

GraphQL gần đây đã trở nên phổ biến, đến mức nó đã đi đầu trong lĩnh vực phát triển API. Ngày nay, có một số ứng dụng khách GraphQL cho các khung công tác front-end. Ứng dụng khách Apollo là một trong những ứng dụng phổ biến hơn cho các ứng dụng Angular.

Category

Học về GraphQL

Image

Tags

Quyết tâm học tập

Add new comment

Hướng dẫn sử dụng basics for the GraphQL Search API module

admin — Thu, 05 May 2022 09:46:42 +0000

Hướng dẫn sử dụng basics for the GraphQL Search API module admin Thu, 05/05/2022 - 11:46

Search condition could be anything, and it could change the search response's structure. eg. if we use the collapse for the elasticsearch, the returned response could be any structure, I guess that it is difficult to define the graphql for the search response. especially if the index include some dynamic fields, it is not easier to do that in strong type of graphQL.

I think that the response structure is known by the client who send the query or the business logic service, they can define the field for the graphql, they can transform the response from search engine. and the search engine should not havve any business logic, it have no idea about the api consumer , no idean about the business logic, so just return the JSON is fine or include a little fixed field for the node of the relayconnection.

Category

Học về GraphQL

Image

Tags

Quyết tâm học tập

Add new comment

Đang học về GraphQL và Drupal 9 quá hay Encapsulation

admin — Thu, 05 May 2022 08:10:21 +0000

Đang học về GraphQL và Drupal 9 quá hay Encapsulation admin Thu, 05/05/2022 - 10:10

Học làm theme với Drupal module GraphQL Twig

admin — Thu, 05 May 2022 06:52:25 +0000

Học làm theme với Drupal module GraphQL Twig admin Thu, 05/05/2022 - 08:52

The power of GraphQL Twig

Decoupling Drupal is the future, however, it may be a big leap to learn a whole new development stack. With GraphQL Twig, we can take baby steps with a soft-decoupled approach by writing GraphQL inside our Twig templates.

TL;DR

Video here: https://youtu.be/QsmeXMZ0foM
Repo with slides: github.com/AmazeeLabs/bartik_graphql

On Friday 11th May, Amazee Labs hosted its first Amazeenar - a live video training session presented by Philipp Melab who demonstrated some of the capabilities of GraphQL with the Drupal module GraphQL Twig.

We started the webinar while a crowd joined live from over 13 countries around the world, including Belgium, Brazil, Canada, South Africa, and as far east as Thailand.

It felt exciting to have a community of enthusiastic people connecting from so many different locations across the globe. This once again reinforced that Drupal is really about coming for the code and staying for the community.

Philipp dove into the talk by giving us a quick introduction to GraphQL, with an example query for us to better understand the concept:

query {
  node:nodeById(id: "1") {
    title:entityLabel
    related:relatedNodes {
      title:entityLabel
    }
  }
}

Running this example GraphQL query would give us the following JSON response:

{
  “node”: {
    “title”: “Article A”,
    “related” {
      { “title”: “Article B” },
      { “title”: “Article C” }
    }
  }
}

Category

Học về GraphQL

Image

Tags

Quyết tâm học tập

Attach

bartik_graphql-master.zip3.46 MB