Yes. Both staunch Republicans and Democrats portray themselves as always being on the back foot, being attacked, and on the verge of losing control from the other party due to some contentious and highly important issue. Each side portrays themself as their views originating from reason (independence of thinking) and the other side as excreted out of ideology (convention).
I've heard this sentiment expressed. The limits of rationality, reason, and scientific process is a whole topic worth exploring even if just for the philosophic value, but right now, discourse, within the framework of rationality and reason is the best tool society has to solve its problems. There's nothing else. Violence clearly isn't the tool. Nor is emotional reflex. Nor is anecdotal thinking. Nothing else scales and has the capability to tackle the sophistication of society-wide problems.
I once worked as part of a team which had graphics people who were allergic to the command line.
Of course there are some things for which Gimp/Photoshop is really necessary, but it turns out that there is a massive amount of image manipulation that is better done on the command line than within Photoshop. The people who were dependent on Photoshop would take endless hours completing the same tasks which can be done in seconds using the command line.
I'm really looking forward to see where the new RFC process will take GraphQL in the next few years. Was great being able to contribute to the standardisation process for subscriptions.
> I now see people on HN have very similar complaints about GraphQL - how its power and flexibility makes making a performant and secure GraphQL backend significantly harder than making an oldschool REST API backend.
I'm curious to learn about people who have had this kind of experience with GraphQL, can you please share a link?
> Does anyone have experience with both? Is GraphQL any better than OData in server-side implementability?
OData is complicated, in part, because it includes semantics for querying collections. In GraphQL, it's a little easier to get started by using GraphQL's List type. Later, if you want to pagination/cursors, you can add Connection support (https://facebook.github.io/relay/docs/graphql-connections.ht...).
They're similar with a few key differences. First, in OData, the URI is still a big part of the API, whereas the URI is unimportant in GraphQL, which allows GraphQL clients to simplify routing logic. Second, GraphQL lets you specify arguments on any field within the selection set. OData's parameters are far less flexible. Finally, and less objectively, I feel OData's query filters on collections is too burdensome and, in practice, ends up tightly coupled to a SQL-like backend.
Simplify routing logic unless you want to route based on URL, which e.g. AWS ALBs or nginx or haproxy can do, but they don't understand GraphQL. What's the alternative?
Like other posters have said, the author appears to be pointing out shortcomings with HTTP, not REST. Roy Fielding made it fairly clear that REST is not strictly associated with HTTP. REST, as an architectural style, is defined by a set of constraints: https://en.wikipedia.org/wiki/Representational_state_transfe.... Anything that meets these constraints is considered "REST". Most of the constraints sound like common sense for API design, and where most APIs are disqualified from being truly "REST" and merely "RESTish" is in trying (or not) to fulfill the Uniform Interface/HATEOAS constraint: that the client dynamically traverses information and operations from one resource to another via hypermedia links.
Interestingly there's yet a deeper problem with fully RESTful APIs (Hypermedia APIs), where REST's Stateless Protocol constraint combined with HATEOAS creates an API where clients need to undergo multiple HTTP round trips to load the data they need. For example, suppose your app lets users browse movies. You might have a sequence like:
client: "hey, I'm gonna act like a browser and hit api.com and take it from there"
GET api.com
=>
{
"movies": {
"rel": "content/movies",
"href": "/movies"
}
}
client: "hmm, ok I guess I'll click the movies link"
GET api.com/movies
=>
{
"items": {
"count": 4,
"prev": null,
"next": "/movies/page/2",
[
{"href": "/movies/1"},
{"href": "/movies/2"},
{"href": "/movies/3"},
{"href": "/movies/4"},
]
}
}
client: "ok, I guess I'll fetch each of those movies (I kinda wish the server had just told me what those contents were in the first place)"
GET api.com/movies/1... etc.
=>
{
"href": "/movies/1",
"rel": "self",
"title": "Waterworld",
"image": "/images/waterworld.png",
}
...
And don't forget the client-side logic to join/order all this data and handle errors. This problem is called "underfetching" and it's present in true REST APIs by design. Ironically, many "RESTful" APIs break from the REST constraints specifically to avoid this problem.
> Roy Fielding made it fairly clear that REST is not strictly associated with HTTP. REST, as an architectural style, is defined by a set of constraints:
Out of curiosity, do you know of any examples of RESTful APIs that use a protocol other than HTTP (say like IMAP or NNTP)?
He isn't going to provide you an example because there is none meaning full in production. REST uses HTTP because it makes no sense to use it with anything else. REST only makes sense with HTTP. With another socket protocol, there is no need to bother with headers and co.
You're right, there are no other protocols at nearly the scale of HTTP that use REST. I was just pointing out that REST was not strictly associated with HTTP in Roy Fielding's definition. If you look at my other link (Richardson Maturity Model), you can see that RPC-over-HTTP is vulnerable to same criticisms in the OP's link. Hence, I think the issues discussed in the article don't singularly apply to REST.
That is the the real test beyond technical jargon and If someone provides a working example that works over different protocols as you have suggested that will be end of discussion :)
