[Translation] GraphQL status quo as seen from the Reddit discussion

• Original Address: at The State of GraphQL by Reddit
• Original author: Robert Matyszewski
• Translation from: Nuggets Translation Project
• Permalink article: github.com/xitu/gold-m...
• Translator: TiaossuP
• Proofreaders: yangxy81118

GraphQL status quo as seen from the Reddit discussion

Mention GraphQL, you will see all kinds of speculation in articles and it will argue compared with REST. GraphQL global epidemic is now in the early stages of a comprehensive use, no one knows exactly where it will stop. Through research on the Internet, I found many articles for Amway this new technology. This is just speculation first impression of it?

I studied on Reddit comments on GraphQL and pick up some of the most popular content. This article is intended to be transparent and objective manner to discuss this topic, so for different perspectives of each faction, I have selected the content of discussion and debate for some users. Each of the following commentary references have a link pointing to their authors, and () in the comments for this point Chan (translation: Originally upvote) number. Note, however, I wrote and published after this article, thumbs numbers may vary.

Agenda

• Overall situation
• React & Apollo situation
• Large companies & GraphQL
• Cache
• Request data
• to sum up

Overall situation

A holistic approach, I chose two practical examples. First, SwiftOneSpeaks shows a perspective front-end developers and potential market improvement. Secondly, Scruffles360 show the team how to adapt strategies and trends graphql they use specific tools. Later you will find more of his comments. The second comment is herein chosen like the least comment.

SwiftOneSpeaks (23) said:

When I back-end development team, they are more inclined to offer a new query to meet my needs, because this will not affect existing queries they must support. (In other words, I do not know, over time, the expansion of the query will happen). GraphQL also reduces the amount I have to re-resolve to poor response available (for my needs) data structure. (For example, I got three arrays, I must associate them together and compressed to a set of objects. Although the back end still need to have some work to do, but using GraphQL, I can have more ability to request data format .)

Scruffles360 (8) describes the three development direction he saw in GraphQL areas:

• Boulder Application: This is now driven by Apollo. Every company has one and only one schema api endpoint agent and all the other stuff ( principledgraphql.com/ ). I completely disagree with this idea, but it will not repeat my arguments here (if you want to know, you can dig my comment history)
• Database api: For some strange reason, people have started to add to the database plug-ins that can graphql direct access to the database. For many reasons, Graphql great, but it is not comparable with native database query language. More importantly, it removes your business layer, so that the caller can access your store directly. In addition to a micro-service application, any remaining people should not have access to the store - someone else should call the service through your api.
• Middle course: the classic API approach, each application has its own API (in this case GraphQL). It is possible to isolate the business logic to the micro or proxy service (by rest or by schema stitching to another Graphql architecture). This is the way to go, so far I have not regretted.

React & Apollo situation

React combination of Apollo and received a lot of attention. In addition Wronglyzorro and Livelierepeat discuss why the back-end developers may not like GraphQL. A more responsive developer experience gained more praise. Also, I have chosen a longer but very detailed comments.

Wronglyzorro（12）：

We strictly use react + apollo applications on the network. We are also forced to move clients also use it. Although it sounds absurd, but it really is a big trend. Of course, the back-end developers hate it, because they are accustomed to the way it defines itself, does not like change. However, our failure occurs in the past year, the never GraphQL caused the collapse of the rear end is always left service.

Livelierepeat (40) Re:

Of course, the back-end developers hate it, because they are accustomed to the way it defines itself, does not like change.

You may want to know my point of view, I was a young developer, using all the latest tools, and laugh at those who "can not adapt to" the. I learned that there are more than usually "People hate change" more interesting reason. For example GraphQL abstract whether too complex? They resist the increased workload, can actually increase what?

Sometimes, all the tools are up to date, they may not let the utility of these tools to get the maximum highlights. Even more critical is that people understand and participate in the development of the code.

Of CAPAJ (11) a detailed summary:

We start from May GraphQL use in a production environment. We are a full-stack team, so we do not need to rely on the back-end teamwork mercy. Persuade everyone is not easy, but built a GQL example, everyone thinks it looks better than REST. Graphiql this helps a lot.

This is good. We use apollo engine in the back end, I really like the use of indicators to capture API error in a production environment. We use decapi to decorate our objection.js DB Model. We define the model in a separate place, then do not do what you can automatically generate GQL.

In the front end, we use apollo-client, but so far we have not use the cache. Our focus is on the front end to get rid of before angular.js code, so we have not had time to test front-end cache.

I have not used apollo client-side state management, because all the feedback I've heard so far are that it is not yet ready for production environments. Also, I have to say it looks very long-winded, to write very long-winded. Instead, I hope I can extend github.com/mhaagens/gq... and for our state management needs. MST use a good typescript performance. MST model dynamically generated from the query if we can edit the query in GQL, we can greatly improve our efficiency.

Cache

I have from SwiftOneSpeaks and Scruffles360 saw a lot of great reviews and high praise, these comments have been mentioned above. The following is a caching issue they discussed and potential solutions.

SwiftOneSpeaks (23) wrote:

Although you can GraphQL configured to operate in a variety of ways, but in fact they are always POST request. This means that all depends on the GET and POST is not idempotent idempotent browser cache this agreement, CDN caching, proxy caching by default will fail. Everything is treated as a new request. Although you can do some more intelligent cache in its own client, but this is really just address your own produce (refer to the introduction of GraphQL) of.

Scruffles360 (11) Re:

Apollo has a solution - "dynamic persistent queries," but I have not tried it. Generally speaking, the client uses the GET request (the query hash), and if that fails, then fall back to POST. The next GET calls and successfully applied to any proxy cache.

Request data

These people also extracted data put forward different views. In graphql-VS-REST ( translation here ) , the authors describe the sample application blog with multiple authors as well as the possibility of using the REST of GraphQL.

SwiftOneSpeaks (23) said:

Everyone stressed that "excessive requests" issue (translation: Originally Over fetching, the requested data means there are many fields that you do not need there is a similar concept:. Under fetching, means a return data interface not enough, part of the field is missing, resulting also need to request the second interface, the problem is that these two cases are wasted in unnecessary network resource) issues. I think this is not a bad design services excuse (in fact the problem is that - if the developer has been very dish, so he wrote out GraphQL service can not suddenly easy to use). It is easy to solve, just add a service in front of the existing service on the line - GraphQL can do the job, but with something else can. The question is not whether excessive requests, but central services and resolve caching issues.

Scruffles360 (12) Re:

Excessive request is indeed a problem. When you have hundreds of clients, each client calls your system in a different way, add a property to the rest api will lead to greatly reduced efficiency. Many argue that the facade provide different interfaces for mobile and web client end, but so scalability is very poor. My project consists of hundreds of client calls, the way each client's request and the request has a slightly different content.

Large companies & GraphQL

Everyone interested in Facebook, Netflix and Coursera and other large companies as well as their use of the GraphQL. For this graphql-vs-rest comment on Reddit is, we can find two main reasons as the author - state. The first is the most popular of the comments made comments that I found.

• In early 2010, the surge in the number of mobile users, there are some problems associated with low-power devices and slow the network. REST is not the best choice for handling these issues;
• The amount of movement increases as the number of different front-end frame and platforms running a client application is also increasing. Because REST is not flexible enough, resulting in more difficult for us to develop a single API to meet the needs of all end-use applications.

Greulich (62) Respond to this article:

This digress too far, does not make sense. Another method for constructing the request does not make those requests network where better or worse. I think the author describes the endpoint rather than the API, because any endpoint, no matter how many endpoint, are only part of the API. Assuming that is the case, why do we only need one endpoint?

Scruffles360 (16) Reply Greulich:

The first two points of the wording of the article is not good, but it is still correct. REST API may be a general purpose, reusable, and may be a client designed specifically known. In the first case, when you need to keep calling the system again to get more data (Translator's Note: the Under fetching mentioned above) (especially on high latency networks like 10 years ago we did on mobile devices ), you will not get good performance. If you end make API for a particular client, then obviously you encounter scalability issues.

to sum up

When choosing the right comment to sum up the state GraphQL, or select a lot to say. Even today's most popular submissions on facebook reddit is a case study or netflix , but submission of these comments are not many. This gives us to reddit views on GraphQL's a good summary. After you think of the developer's everyday life, I can not ignore the content Kdesign (36) wrote:

GraphQL make your job more secure, that's for sure.

You have to spend time in all N multi-layer between the front and the actual data store, find the location of the data.

Kollektiv (44) listed a number of GraphQL questions:

• Query speed limits and permissions assessment difficult to achieve.
• Work types and data loader, if you do not write a complete module on the grouping queries, it is difficult to effectively bind to the way queries the database layer.
• Verify only checks types, so you still need to perform some other format JSON schema validation.
• GraphQL query allows only left join, thus adding to filter such as the INNER JOIN to re-create SQL becomes very tricky.
• From page like this imposed framework Relay (connection) or a mess.

About My initial research GraphQL of SwiftOneSpeaks (24-) writes:

I think we saw a lot of "great GraphQL" report mainly because any new services are great - as time goes on, because the assumption is violated (translation: The concept of assumptions can refer to Talking Architectural Assumption (Software Architecture design assumptions) ) , needs to change and change the code, they will certainly become increasingly unwieldy. But this does not mean GraphQL bad - just means I can not say too much trust in earlier reports.

Finally, I chose Mando0975 (28) point of view to summarize this article:

Development is always to pick the right tool for the job. GraphQL is not a silver bullet. REST is not dead, GraphQL will not kill it.

GraphQL how your experience?

If you find there is a translation error or other areas for improvement, welcome to Denver translation program to be modified and translations PR, also obtained the corresponding bonus points. The beginning of the article Permalink article is the MarkDown the links in this article on GitHub.

---

Nuggets Translation Project is a high-quality translation of technical articles Internet community, Source for the Nuggets English Share article on. Content covering Android , iOS , front-end , back-end , block chain , product , design , artificial intelligence field, etc., you want to see more high-quality translations, please continue to focus Nuggets translation program , the official micro-blog , we know almost columns .