Shulou(Shulou.com)06/02 Report--

This article mainly introduces "Why to use GraphQL". In daily operation, I believe many people have doubts about why to use GraphQL. The editor consulted all kinds of materials and sorted out simple and easy-to-use methods of operation. I hope it will be helpful to answer the questions of "Why should you use GraphQL?" Next, please follow the editor to study!

The rise of GraphQL

The increased importance of mobile application performance and organizational agility provides a booster for GraphQL to reach the top of modern enterprise architecture.

Given that REST is a very popular architectural style and already provides a mechanism for data interaction, what are the advantages of the new technology GraphQL over REST? The "QL" in GraphQL represents the query language, which is a good starting point.

With GraphQL, different client applications within an organization can easily query only the data they need, which goes beyond other REST methods and results in improved performance of real-world applications. Using traditional REST API endpoints, the client application inquires the server resources and accepts a response that contains all the data that matches the request. If the successful response from the REST API endpoint returns 35 fields, the client application receives 35 fields.

Problem of acquisition

Traditionally, REST API does not provide an easy way for client applications to retrieve or update only the data they care about. This is often described as a problem of "overfetching over-fetching". With the widespread use of mobile applications in people's daily life, excessive access to problems will bring adverse consequences to the real world. The acceptance and transmission of every request and byte made by a mobile application has an increasing impact on the performance of end users. Users with slow data connections are particularly affected by poor API designs. Customers who use mobile applications with poor performance experience are more likely not to buy products or use services. Inefficient API design is only a waste of corporate money.

"over-acquisition" is not the only problem, "lack of acquisition" is also a problem. By default, the endpoint returns only part of the data that the client actually needs, which requires the client to make additional calls to meet its data needs, which results in additional HTTP requests. Due to the problem of excessive and lack of access and its impact on the performance of client applications, API technology that promotes effective access has the opportunity to cause a sensation in the market-GraphQL boldly intervened and filled this gap.

The response of REST

REST API designers are not willing to quit without a fight, they try to deal with mobile application performance problems in the following ways:

The include and exclude query parameters allow client applications to specify the required fields through possibly longer query formats.

A "composite" service that combines multiple endpoints to make client applications more efficient in terms of the number of requests they make and the data they receive. Although these models are heroic attempts by the REST API community to address the challenges facing mobile clients, they are still inadequate in the following key areas:

Including and excluding query key / value pairs can quickly become confusing, especially for deep object graphs that need to use nested "dot representation" syntax (or similar methods) to include and exclude target data. In addition, the problem of debugging query strings in this model usually requires manual decomposition of URL.

The implementation of the server that contains and excludes queries is often custom, because server-based applications do not have a standard way to handle the use of include and exclude queries, just as there is no standard way to include and exclude queries.

The rise of composite services has led to more closely coupled back-end and front-end systems, which requires enhanced coordination to deliver projects and shift former agile projects back to waterfall development. Another painful side effect of this coordination and coupling is that it reduces the agility of the organization. In addition, as the name implies, composite services are not RESTful.

The Origin of GraphQL

For Facebook, GraphQL was shaped by the pain points and experiences experienced in its flagship mobile application based on the HTML5 version of 2011-2012. Facebook engineers realize that improving performance is critical, so they realize that they need a new API design to ensure optimal performance. Given the limitations of the above REST and the need to support the different needs of many API clients, one can understand what caused its co-founders Lee Byron and Dan Schaeffer (who were Facebook employees at the time) to create the early seeds of what became known as GraphQL.

With the GraphQL query language, client-side (usually a single GraphQL endpoint) applications can often significantly reduce the number of network calls required and ensure that only the data they need is retrieved. In many ways, this can be traced back to the early Web programming model, where client application code queries back-end systems directly-- for example, some people may remember writing SQL queries in JSTL on JSP 10 to 15 years ago.

The biggest difference now is using GraphQL, where we have a specification that spans multiple client and server languages and library implementations. With an API technology such as GraphQL, we decouple back-end and front-end application systems by introducing a GraphQL application middle layer, which provides a mechanism to access organizational data in a manner consistent with the organization's business domain.

In addition to addressing the technical challenges faced by software engineering teams, GraphQL promotes organizational agility, especially in the enterprise. Organizational agility with GraphQL enabled is usually attributed to the following factors:

Instead of creating new endpoints when the client needs one or more new fields, GraphQL API designers and developers can include these fields in existing diagram implementations, thus demonstrating new functionality with less development effort and fewer changes across application systems.

By encouraging the API design team to focus more on defining object diagrams than on client application delivery, front-end and back-end software teams are increasingly decoupling the speed at which solutions are delivered to customers. # precautions before adoption

Despite the compelling advantages of GraphQL, GraphQL is not without challenges. Some examples include:

The caching mechanism established for REST API is more mature.

The pattern of using REST to build API is more sophisticated.

Although engineers may prefer new technologies such as GraphQL, the talent pool on the market is more focused on building REST-based solutions than GraphQL.

At this point, the study on "Why to use GraphQL" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.