Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

REST in Peace. Long Live GraphQL

medium.freecodecamp.org

Post reply on HN
Print view View original

81–90 of 94 posts

Re: REST in Peace. Long Live GraphQL

#81

Post by cholantesh »

daliwali wrote: post #68
nemild wrote: post #42

I'm pretty disappointed by this title. I know that it might be said in fun - and is an easy way to get clicks, but it feeds into the narrative of new, shiny tech. As the article points out at the end, there are very real engineering tradeoffs with GraphQL - and the answer isn't as easy as REST is dead, anachronistic technology that no engineer should consider (the XML analogy felt particularly inflammatory). Kelly an…

>A number of "engineering" posts are not written as a thoughtful engineer might, and are in many ways marketing for the products sold (like a training program). I think this is a great insight that is often overlooked in tech marketing. When any vendor comes up with a product that claims "[industry standard] is dead, use [our product]", there should be alarm bells ringing already.

The author of this piece is selling a Pluralsight course on building GraphQL applications, so qui bono certainly applies.

Re: REST in Peace. Long Live GraphQL

#82

Post by jmakeig »

daliwali wrote: post #63

There is a lot of FUD from the GraphQL side of this debate, and even overlapping goals with REST. From the article: >With GraphQL, the client speaks a request language which decouples clients from servers. This means we can maintain and improve clients separately from servers. This is actually how the web works right now. Browsers (clients) evolve independently from web pages (servers). Even the author of REST said i…

If you control both the client and the server, there are lots of shortcuts you can take. As you say, that’s not the problem that REST was trying to solve, though.

Re: REST in Peace. Long Live GraphQL

#83

Post by jmakeig »

tomc1985 wrote: post #59

"who in their right mind would use XML over JSON today?" Lost me already... there are lots of reasons to still use XML today. And since someone is going to ask, here are some: * you want to use xpath * you want to communicate with an enterprise app (salesforce, magento, etc) * you need strongly-typed message-passing in a human-readable well-understood format (rules out messagepack, etc) * nobody actually documented t…

Or your data is…you know…mark-up. Imagine a biology textbook, or legal contract, with inline citations and entities. There’s lots of marked-up human text around, even if that’s not what you’re sending to a JavaScript front-end. (Ironically, all of our JavaScript front-end frameworks are ultimately building mark-up as documents for human consumption.)

Re: REST in Peace. Long Live GraphQL

#84

Post by andrewingram »

Daishiman wrote: post #79
andrewingram wrote: post #54

Earlier quoted context omitted.

Mostly i'm referring to the methodology I followed here: https://dev-blog.apollodata.com/optimizing-your-graphql-requ... I haven't looked into optimising other types of architecture (eg GraphQL server talking directly to the database), but there seem to be plenty of solutions that people are happy with.

That doesn't touch upon the N + 1 query problem at all.

Can you tell me which particular problem you're talking about? When people talk about GraphQL and the n+1 problem, they're typically talking about the problem which Dataloader solves, and this is the problem this article builds upon.

Re: REST in Peace. Long Live GraphQL

#85

Post by vram22 »

daliwali wrote: post #68
nemild wrote: post #42

I'm pretty disappointed by this title. I know that it might be said in fun - and is an easy way to get clicks, but it feeds into the narrative of new, shiny tech. As the article points out at the end, there are very real engineering tradeoffs with GraphQL - and the answer isn't as easy as REST is dead, anachronistic technology that no engineer should consider (the XML analogy felt particularly inflammatory). Kelly an…

>A number of "engineering" posts are not written as a thoughtful engineer might, and are in many ways marketing for the products sold (like a training program). I think this is a great insight that is often overlooked in tech marketing. When any vendor comes up with a product that claims "[industry standard] is dead, use [our product]", there should be alarm bells ringing already.

>When any vendor comes up with a product that claims "[industry standard] is dead, use [our product]", there should be alarm bells ringing already.

Seen this from quite a ways back. When .NET came out, I remember college students in my neighborhood (e.g. when hanging out at some tea shop or restaurant), asking me (they knew me, and that I was in software), in a concerned tone, stuff like:

"We hear that now that .NET has come, Java will be dead. Is that right?"

I used to have to disabuse them of such nonsensical notions. Not that Java will live forever, but obviously a mature and widely adopted technology is not going to die off overnight. Such is the hype, though, for the new and shiny.

Re: REST in Peace. Long Live GraphQL

#87

Post by chiefalchemist »

merb wrote: post #3

> The need to do multiple round trips to fetch data required by a view: With GraphQL, you can always fetch all the initial data required by a view with a single round-trip to the server. I'm not sure what's different. You can actually implement the same with plain old http api's, also.

Yes, that's true. But I don't think that's legit within the technical and absolute definition of REST. Perhaps they used that strict definition in order to differentiate the product?

Re: REST in Peace. Long Live GraphQL

#88

Post by luord »

I'll keep creating plain REST APIs for the time being. I haven't really faced any of the issues mentioned. Or at least they haven't impacted development time for me in a meaningful way.

If a client requires a GraphQL API, I'll happily learn. It does look like an interesting technology and a valid alternative.

Re: REST in Peace. Long Live GraphQL

#89

Post by bmn__ »

jmull wrote: post #78

I guess this makes me sad. Apparently REST has come to mean such a small and specific thing that a REST vs. GraphQL comparison makes sense. There actually shouldn't be anything contradictory about choosing the GraphQL interface for a REST API. Also, before anyone jumps in head first on this, keep in mind the downside to things like GraphQL. Your data API is a promise to your clients and GraphQL presents a flexible, u…

> Apparently REST has come to mean such a small and specific thing

It's called an argumentative straw man. The article attacks… something, but that thing ain't Rest, clearly. But ooooh boy, must it feel satisfying for Samer Buna to topple it over!

HN readers should not fall for the oldest trick in the book.

Re: REST in Peace. Long Live GraphQL

#90

Post by lolive »

linkmotif wrote: post #40
lolive wrote: post #27

Basically, GraphQL is a revamping of SPARQL (you know, the W3C language to query RDF databases). FYI, DBPedia is a big big endpoint for these old-school technologies. My question is then: - will there be a "standard" way to describe the data model (aka vocabulary) of your GraphQL endpoint? Something like RDFS or OWL.

This is entirely incorrect. GraphQL is a wrapper around your service layer, or worse, around a number of ad hoc data sources. That service layer or those data sources may query SPARQL services.

So GraphQL is a graph abstraction over REST APIs, at the cost of massive REST calls to rebuild a graph. True?
Post reply on HN