top | item 25019693

(no title)

Hurtak | 5 years ago

> GitHub was flakey, some things didn’t have error responses

That just seems like API problem rather than GraphQL problem. The equivalent would be REST API that just returns 500 without any additional info. You can be lazy in both stacks, I don't think any one of them particularly prevents you from being lazy about handling errors / typing useful error messages.

> Mutations would screw up encoding “ character and it was just painful.

Interesting, haven't heard about this. Also cant come up with how this is related to GraphQL, as you are just transferring string, just like you would do with REST. It seems more of an problem with some proxy/grapql framework layer that didn't handle the character correctly?

> REST api was much more deterministic and easier to work with. POST/PATCH/PUT/DELETE map well.

I don't see this as a big win, in GraphQL you just have `somethindUpdate` `somethingCreate` `somethingDelete` mutations, it is true that it is up to you to keep the naming consistent but nothing really that would be big trouble, or win for the REST.

> I wish graphql didn’t invent its own quirky language and stuck to good ol json.

If they did that you would end up with some quirky JSON query and schema syntax that would look like json schema or the mongo query schema. It is true that if you do new syntax you lose some json tooling that could be used (eg syntax highlight) but I don't see that much stuff transferable to the problems that GraphQL is solving.. so you would still end up with bunch of custom tooling on top, and when you need that you might as well go the way they did, with new syntax, that is not as quirky as whatever mongo/json schema like thing they would come up with.

> There is a lot of over complication.

This is definitely true and one of the most overlooked things by GraphQL evangelists, the "additional complexity layers" are non negligible.

discuss

order

No comments yet.