robzhu

This is really cool! Definitely going to check it out

Can you provide an example?

During China's Cultural Revolution, the Communist party also kept track of an adversity score.

This is why I'm creating a command-line alternative to Photoshop.

This seems like a pretty benign "cash grab" since it depends on helping the client succeed.

Congrats to the Graphcool team on the launch! You're part of what makes the GraphQL community awesome. I can't wait to see what you come up with next!

> 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...).

One very common failure mode we observe with GraphQL users: they do not have a clearly defined boundary between their GraphQL schema definition and their domain layer: http://graphql.org/learn/thinking-in-graphs/#business-logic-...

I'm not sure I understand your use case. Can you give me an example of the problem you're dealing with?

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.

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.

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.

Another great article on REST APIs: https://martinfowler.com/articles/richardsonMaturityModel.ht...

I highly recommend babun: http://babun.github.io/

You can send a GraphQL query as part of the query in your HTTP GET request: http://graphql.org/learn/serving-over-http/#get-request.

They're similar; both technologies allow clients to specify the data they need. I would say that GraphQL is more flexible and has a strong type system. For example, the filter semantics are defined within OData, while in GraphQL, you define how your data can be filtered within your schema.

As a personal opinion, I also feel OData exposes an API that is too tightly coupled to the persistence layer. GraphQL objects and properties are all backed by arbitrary "resolver" functions, which means you can stitch together multiple/legacy backends to generate your response.

You might want to check out GraphQL: http://graphql.org/. One of its killer features is the ability for clients to specify exactly the data it needs and obtain it in a single request/response.