3 ms·

From my experience (most with github’s graphql api), graphql is phenomenal for get queries as you can get a big chunk of things in a single request exactly as y

by nojvek 6y ago

From my experience (most with github’s graphql api), graphql is phenomenal for get queries as you can get a big chunk of things in a single request exactly as you want. Github’s graphiql explorer was a joy to use and has saved me hours. For fetching a graph of nested data, graphql absolutely shines giving you fast responses of only the data you need. For mutations though, graphql is a giant pain in the ass. We wrote a bunch of things using graphql mutations and after two months reverted all mutation code back to using REST api. GitHub was flakey, some things didn’t have error responses. Mutations would screw up encoding “ character and it was just painful. REST api was much more deterministic and easier to work with. POST/PATCH/PUT/DELETE map well. I wish graphql didn’t invent its own quirky language and stuck to good ol json. In my experience graphql wasn’t worth the hype. There is a lot of over complication. We’ve got a lot more production success sticking to the basics. NOTE: we were interfacing with github’s graphql api from python. Outside of js, graphql tooling is sparse and sometimes non-existent.

jensneuse 6y ago
Do you have ideas on how we can make mutations work better? What's missing? What could have helped in your situation? Would really appreciate your input.
Hurtak 6y 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.
latte 6y ago
Not sure if that's relevant - but were you aware that you can pass GraphQL inputs as plain JSON in variables? In the vast majority of cases, you don't need to build mutation inputs (or anything else, really) in GraphQL syntax. Python requests library should be more than enough if GraphQL is being used the right way.

by nojvek 6y ago

jensneuse 6y ago

Do you have ideas on how we can make mutations work better? What's missing? What could have helped in your situation? Would really appreciate your input.

Hurtak 6y 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.

latte 6y ago

Not sure if that's relevant - but were you aware that you can pass GraphQL inputs as plain JSON in variables? In the vast majority of cases, you don't need to build mutation inputs (or anything else, really) in GraphQL syntax. Python requests library should be more than enough if GraphQL is being used the right way.