• The State of GraphQL by Reddit
  • By Robert Matyszewski
  • The Nuggets translation Project
  • Permanent link to this article: github.com/xitu/gold-m…
  • Translator: TiaossuP
  • Proofreader: Yangxy81118

A look at the current state of GraphQL from Reddit discussion

When you mention GraphQL, you’ll see hype articles and arguments comparing it to REST. GraphQL is in the early stages of global popularity and full adoption, and no one knows for sure where it will stop. Through research on the Internet, I found many Amway articles on this new technology. Is this just hype for first impressions?

I studied the comments on Reddit about GraphQL and picked out some of the most popular ones. The purpose of this article is to discuss the topic in a transparent and objective manner, so I have selected some of the user discussions and debates for each faction. Each comment reference below has a link to its author and the number of upvotes for that comment in (). Be aware, though, that the likes numbers may change after I write and publish this article.

The agenda

  • The overall situation
  • React & Apollo situation
  • Big Company & GraphQL
  • The cache
  • The request data
  • conclusion

The overall situation

From the perspective of the whole, I choose two practical examples. First, SwiftOneSpeaks shows the front-end developer’s perspective and potential market improvements. Second, Scruffles360 shows how the team adapted to GraphQL and their strategic trends in using specific tools. You’ll find more of his comments later. The second comment is the one with the least likes in this article.

SwiftOneSpeaks (23) says:

When I work with back-end development teams, they are more inclined to provide new queries to meet my needs because it doesn’t affect the existing queries they have to support. (That said, I don’t know how extensible this query will be over time). GraphQL also reduces the number of bad responses I have to reparse into usable data structures that fit my needs. (For example, I get three arrays that I have to associate and compress into a set of objects. While the back end still needs some work to do, using GraphQL, I have a much richer ability to request data formats.

Scruffles360 (8) describes the three directions he sees in GraphQL:

  • Stonehenge applications: This is what Apollo is pushing now. Every company has one and only one API endpoint and schema broker for everything else (principledgraphql.com/). I totally disagree with this line of thinking, but I won’t repeat my argument here (dig into my comment history if you want to know).
  • Database APIS: For some strange reason, people have started adding plug-ins to databases that can be accessed directly through GraphQL. Graphql is great for a number of reasons, but it’s not as good as the native database query language. More importantly, this removes your business layer, giving callers direct access to your Store. No one except a microservice application should have access to the Store — anyone else should call the service through your API.
  • Middle way: The classic API approach, where each application has its own API (GraphQL in this case). It is possible to isolate business logic or agents to microservices (either through REST or through Schema kevlar to another Graphql schema). It’s the path we’ve taken, and so far it hasn’t made me regret it.

React & Apollo situation

React and Apollo got a lot of attention. In addition, Wronglyzorro and Livelierepeat discuss why back-end developers might not like GraphQL. A response from a more experienced developer got more likes. Also, I chose a longer but very detailed comment.

Wronglyzorro (12) :

We strictly use React + Apollo on our web applications. We also force mobile clients to use it. It may sound ridiculous, but this is the trend. Back-end developers hate it, of course, because they’re used to their old ways and don’t like to change. However, none of the failures we’ve had over the past year were GraphQL’s fault, it was always the legacy back-end services that crashed.

Livelierepeat (40) Reply:

Back-end developers hate it, of course, because they’re used to their old ways and don’t like to change.

You might want to know my perspective, I used to be a young developer, using all the latest tools and laughing at those who “couldn’t adapt”. I learned that there are usually more interesting reasons than “people hate change.” For example, is GraphQL too complicated to abstract? They resist the increased workload, but what is it?

Sometimes, all the tools are up to date, which may not maximize their usefulness. It’s more about understanding the code and the people involved.

A detailed summary of Capaj (11) :

We started using GraphQL in production in May. We’re a full-stack team, so we don’t have to rely on the mercy of the collaborating back-end teams. It wasn’t easy to convince everyone, but GQL has a built-in example that everyone agrees looks better than REST. Graphiql helps a lot with this.

That’s good. We use the Apollo engine on the back end, and I’m a big fan of using metrics to catch API errors in a production environment. We use decAPI to decorate our object.js DB Model. We define the Model in a separate place and then generate the GQL automatically without doing anything.

On the front end, we use Apollo-client, but so far we haven’t used caching. Our front-end focus is getting rid of our angular.js code, so we haven’t had time to experiment with front-end caching.

I haven’t used Apollo for client-side state management because all the feedback I’ve heard so far suggests it’s not ready for production. Also, I have to say it looks wordy, and it’s wordy to write. Instead, I wish I could expand github.com/mhaagens/gq… And use it for our state management needs. MST works well with typescript. If we can dynamically generate MST models from queries when editing GQL queries, we can greatly improve our productivity.

The cache

I’ve seen a lot of great and awesome reviews from SwiftOneSpeaks and Scruffles360 already mentioned above. Here’s their discussion of caching issues and potential solutions.

SwiftOneSpeaks (23) writes:

While you can configure GraphQL to work in various ways, in reality they are always POST requests. This means that all browser caches, CDN caches, and proxy caches that rely on the convention that GET is idempotent and POST is not are invalidated by default. Everything is treated as a new request. While you can do some smarter caching on the client side, this is really just solving a problem that you created (and guided into GraphQL) yourself.

Scruffles360 (11) Replies:

Apollo has a solution called “dynamic persistent queries,” but I haven’t tried it yet. Basically, the client will use the GET request (hash the Query) and fall back to POST if it fails. Subsequent GET calls will succeed and apply to any proxy caches.

The request data

These people also put forward different views on data extraction. In GraphQL-VS-REST, the author describes an example blog application with multiple authors and the possibilities of using GraphQL with REST.

SwiftOneSpeaks (23) said.

Everyone emphasized the problem of “Over fetching”, which means that there are many fields in the requested data that you do not need to fetching. There is a similar concept that Under fetching, which means that not enough data is returned from an interface and some fields are missing so that a second interface needs to be called upon, which in both cases is due to wasted network resources. I don’t think this is an excuse for designing a bad service at all. (The problem is that if a developer sucks all the time, then his GraphQL service doesn’t suddenly work.) This can be easily solved by adding a service in front of the existing one — GraphQL does the job, but you can do it with something else. The issue is not whether excessive requests are made, but rather central service and resolve caching issues.

Scruffles360 (12) Replies:

Overasking is a real problem. When you have hundreds of clients, each calling your system in a different way, adding a property to the REST API can cause a significant loss of efficiency. Many people have proposed different facade interfaces for mobile clients and The Web, but this scalability is poor. My project is called by hundreds of clients, each requesting something slightly different from what it is asking for.

Big Company & GraphQL

Everyone is interested in big companies like Facebook, Netflix, and Coursera and how they use GraphQL. For this graphQL-VS-rest comment in Reddit, we can find two main reasons as author-state. The first comment I made was the most popular I found.

  • In early 2010, the number of mobile subscribers surged and there were some problems related to low-power devices and slow networks. REST is not the best choice for addressing these issues;
  • As mobile usage increases, so does the number of different front-end frameworks and platforms for running client applications. REST’s inflexibility makes it harder to develop a single API that meets the needs of all end applications.

Greulich (62) replies to this article:

It’s beside the point. It doesn’t make sense. Another way of structuring requests does not make the network on which those requests reside better or worse. I think the author is describing an endpoint rather than an API, because any endpoint, no matter how many, is just part of an API. Assuming this is the case, why do we need only one endpoint?

Scruffles360 (16) replies to Greulich:

The first two points in the article are not well worded, but they are still correct. REST apis can be generic and reusable, or they can be designed specifically for known clients. In the first case, you will not obtain satisfactory fetching performance when you have to constantly call the system again to fetch more data (especially if you have a high latency network like we had on mobile devices 10 years ago). If you make apis for specific clients, you obviously run into scalability issues.

conclusion

There’s a lot to say or choose from when choosing the right comment to summarize the state of GraphQL. To this day, the most popular submissions on Reddit are case studies on Facebook or Netflix, but those submissions don’t receive many comments. This gives us a good summary of reddit’s views on GraphQL. When I think about the daily lives of developers, I can’t ignore what Kdesign (36) wrote:

GraphQL makes your work safer, that’s for sure.

You must spend time finding the location of the data in all the N layers between the front end and the actual data store.

Kollektiv (44) lists a number of GraphQL problems:

  • Query speed limit and permission evaluation are difficult to implement.
  • The way types and data loaders work, grouping queries without writing a full module makes it difficult to bind queries to the database layer in an efficient way.
  • Validation only checks the type, so you still need some JSON Schema to perform other format validation.
  • GraphQL queries only allow left Join, so recreating SQL like INNER Join plus filtering becomes tricky.
  • Paging (connections) imposed from frameworks like Relay is still a mess.

About my initial research on GraphQL SwiftOneSpeaks (24) writes:

I think we see a lot of “GraphQL is great” reports mainly because any new service is great — over time, because assumptions are violated. Architectural assumptions, requirement changes, and code changes are examples of concepts that are bound to become increasingly awkward. That doesn’t mean GraphQL isn’t good — it just means I can’t put too much faith in early reports.

Finally, I have chosen the opinion of Mando0975 (28) to conclude this article:

Development is always about picking the right tools for the job. GraphQL is not a silver bullet. REST isn’t dead, and GraphQL isn’t going to kill it.

How was your GraphQL experience?

If you find any mistakes in your translation or other areas that need to be improved, you are welcome to the Nuggets Translation Program to revise and PR your translation, and you can also get the corresponding reward points. The permanent link to this article at the beginning of this article is the MarkDown link to this article on GitHub.

The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.