GraphQL isn't a replacement for REST.<p>REST is great for most applications. GraphQL is helpful in some specific applications where the benefits outweigh the downsides of additional complexity, but it shouldn't be viewed as universally superior to REST.
REST itself is such an amorphous term nowadays that it's tough to even measure/define this. It seems to now mean basically any multi-endpoint based JSON API.<p>GraphQL is trendy and might take over "REST" for startups soon if it hasn't already. But in real-world adoption in established companies and dev teams I'm not sure that it ever will. REST / typical JSON APIs are so prevalent because they are fully backend agnostic and so darn easy to write (Note: not easy to write well). GraphQL has some architecture and typed overhead to learn prior to spinning up an endpoint and the underlying logic to stitch together the data. With REST, it's just HTTP call, backend processes call, return JSON, done.
On one level never, so long as http is the dominant protocol.<p>For some things REST is appropriate, for other things it is not.<p>I am impressed with websockets; it's easy to make a web page that controls your smart lights, stereo volumes and such where the updating is symmetrical: not only does clicking on the HTML button toggle the light, the web page changes when the light is toggled from a different switch.<p>With the right backend a business application could do the following: you are looking at a customer record that shows the order hasn't shipped yet, the page updates the instant the order is shipped instead of requiring a reload.<p>The other thing I would look at is web workers, service workers, and indexed storage. One scenario is:<p>you want to read the manuals for your favorite programming language on your computer disconnected from the net; a web app creates a Service Worker that downloads all the web pages as a brotli tar file (not ZIP for many reasons) and stores them in IndexedStorage on your browser: the Service Worker then acts like an http server integrated that serves the pages of the manual.<p>If you want to avoid the baggage of http you can also create a Web Worker and communicate with it with JSON messages, a little like having a local "websocket server".<p>Those tech have not been used much because the coding is tricky and the most popular framework so far is<p><a href="https://developers.google.com/web/tools/workbox/" rel="nofollow">https://developers.google.com/web/tools/workbox/</a><p>which really just complicates the cache behavior of the browser -- the probability that workbox will really speed up your app is about 0.01%, compared to something like the "solid compressed tar" approach which will have much better performance you can feel. (Like try the quarter mile in a Dodge Viper instead of a Honda Fit)<p>One could even picture a news site, for instance, that uses push updates, websockets, or polling, to update a user's local copy of the site.
It's imprecise for various reasons, but Google Trends is often good at providing a brief assessment in situations like this. It does appear useful here too:<p><a href="https://trends.google.com/trends/explore?date=all&q=restful,graphql,grpc" rel="nofollow">https://trends.google.com/trends/explore?date=all&q=restful,...</a><p>Edit: added grpc into the mix
A typical frontend needs a heavy layer to connect properly with a gql endpoint. You also need somewhat black box type frameworks on the backend. You can make a REST http server just by understanding basic routes.<p>GQL is very black boxy when you think about the layers involved to expose it.
I use graphql extensively at work, because it requires it. I wouldn’t use graphql if my use case was sufficiently solved with REST. And in most cases, it is. Saying graphql will take over rest is like saying apples will take over bananas.