3 ms·

Every REST argument: - REST is standardized, because look at all the standards for it (OData, OpenAPI etc.). - REST is easy, because I don't implement any of

by slver 5y ago

Every REST argument: - REST is standardized, because look at all the standards for it (OData, OpenAPI etc.). - REST is easy, because I don't implement any of those standards. - REST is flexible, because I don't even understand the constraints of REST and violate them at will turning it into RPC calls, thinking that it's about pretty URLs and CRUD verbs. Honestly, it's pointless to argue with those folks. Let them believe REST is the solution. It's way above their paygrade to understand why GraphQL exists.

aniforprez 5y ago
This seems so unnecessarily antagonistic. People violate all kinds of "standards" all the time cause they don't know any better and design stuff terribly. You could pretty much make a terribly designed system in a similar way with GraphQL except maybe less accidentally cause it imposes some constraints on the developer to follow what the library gives you. The benefit of GraphQL is the fact that there's very few ways of implementing it
- slver 5y ago
  So it's unnecessarily antagonistic, but then you proceed to agree with everything I said. Look you can't argue REST is easy by defining REST one way, then argue it's powerful and has these features by defining it another way, and finally implementing it in a third way. GraphQL at least has a shape. It's a thing. It says "you gotta do this and this and this, and then you get that and that and that out of it". The original REST paper also has the same tit-for-tat proposition, but it was abstract, not a concrete architecture, rather it was an architectural style. And as such, it's been basically ignored. Oh, also the REST architectural style is NOT suitable for fine-grained data APIs (Fielding's words not mine). When you say REST API today, REST is not a thing, it's shapeless, formless, it has no smell, no taste, you can't touch it. So newbies can claim it's easy because you just slap some JSON and you call it REST API. No, GraphQL can't compete with that definition of REST. But also it's not trying to.
jrsj 5y ago
My argument is that I know it’s worse, I know in practice it is your 3rd bullet point, but it’s easy for both the lowest common denominator of developer and manager to work with and understand. It’s technologically inferior but has less complications on the human side of things in my experience.

by slver 5y ago

aniforprez 5y ago

This seems so unnecessarily antagonistic. People violate all kinds of "standards" all the time cause they don't know any better and design stuff terribly. You could pretty much make a terribly designed system in a similar way with GraphQL except maybe less accidentally cause it imposes some constraints on the developer to follow what the library gives you. The benefit of GraphQL is the fact that there's very few ways of implementing it

slver 5y ago
So it's unnecessarily antagonistic, but then you proceed to agree with everything I said. Look you can't argue REST is easy by defining REST one way, then argue it's powerful and has these features by defining it another way, and finally implementing it in a third way. GraphQL at least has a shape. It's a thing. It says "you gotta do this and this and this, and then you get that and that and that out of it". The original REST paper also has the same tit-for-tat proposition, but it was abstract, not a concrete architecture, rather it was an architectural style. And as such, it's been basically ignored. Oh, also the REST architectural style is NOT suitable for fine-grained data APIs (Fielding's words not mine). When you say REST API today, REST is not a thing, it's shapeless, formless, it has no smell, no taste, you can't touch it. So newbies can claim it's easy because you just slap some JSON and you call it REST API. No, GraphQL can't compete with that definition of REST. But also it's not trying to.

jrsj 5y ago

My argument is that I know it’s worse, I know in practice it is your 3rd bullet point, but it’s easy for both the lowest common denominator of developer and manager to work with and understand. It’s technologically inferior but has less complications on the human side of things in my experience.