4 ms·

I have a lot of experience with GraphQL and I love it. It saves a ton of development time. However, for those who wonder what the disadvantages are, here are s

I have a lot of experience with GraphQL and I love it. It saves a ton of development time. However, for those who wonder what the disadvantages are, here are some. They are from real world production experience and they are not what people usually claim wrongly (like graphql would be harder to secure/version, ...) No, some real pain points are: 1. Lack of a Map-type. There is no native type to return a list/array of objects but not a map with unique keys or even a set instead of a list. You can fallback to "convention" or custom types (like plain json) but it sucks. 2. Uploading big files (in chunks) is much more tricky than expected 3. There are union-types for the returned data. For example, I can query for an animal and get either a cat or a dolphin and if I use typescript or another capable language then the compiler will tell me that. But I cannot send such a request to the server, saying "here I send you an animal, the data is this ...". The server will have to provide a separate query/endpoint per animal. Very very annoying. 4. While graphql is awesome when it comes to batching requests, what it is not so awesome at is to improve performance by allowing the server to return the part of the data is already resolved. So while reducing the number http requests, now the previous slowest http request will become the bottleneck for all. This means the page might load subjectively faster because some parts are rendered later than possible. There is work going on here (like @defer) but it's not fully spec'd and also the solution doesn't work for some cases There are more points but this gives you some idea of the ACTUAL problems. Otherwise, from development and setup time over maintenance, analytics, versioning/deprecation, tooling and so on, graphql is much better than your standard REST api in my opinion.

scotty79 3y ago
> Lack of a Map-type. Why do you need special map types for transferring maps? Doesn't list of key-value pairs suffice? Also, why am I wrong to even ask the above questions?
- tadfisher 3y ago
  A (single-level) Map is generally understood to have unique keys, which allows for some invariants derived from this property, such as a one-to-one or one-to-many object relationship, without runtime checks in client code. I do think it's worthwhile to ask the question, though. I have a strong personal preference to avoid encoding invariants like this in wire representations, because they are properties of the _schema_ and not the wire type (JSON object, in my most commonly-encountered case). Of course, the entire point of GraphQL is to encode invariants in the data schema, so it's entirely reasonable to ask for a built-in Map type instead of building your own for every project.
  - jonhohle 3y ago
    JSON (as defined by json.org), for example, does not specify that key/value pairs need to be unique. ECMA-404 explicitly calls this out as an implementation consideration. I know of one implementation that supports multiple entries with the same key.
- valenterry 3y ago
  It's a fair question. Having a map-type has several benefits: 1. I can signal to my api's users that there won't be any repeating keys without having to write documentation 2. The type can be mapped correctly into the target language. Most languages have a map-type and so it's nice if you don't have to convert it yourself 3. No manual conversion also saves time in most cases, since libraries can do it efficiently in one step. Otherwise you get a list<X> from your library and have to turn it into a map. Not good for bigger lists in performance sensitive applications 4. The same is also true the other way around when sending data to the server 5. It saves space in many serialization formats like json. Instead of [{"key": "key1", value: "value1"}, ...] you get {"key1": "value1", ...} 6. It's nicer to read and debug 7. It's nicer to manually create/write those values in tools like graphiql to test queries by hand and those tools can even warn you if you repeat a key by accident Just some of the things out of my head, I'm sure I've missed a bunch.
  - scotty79 3y ago
    1. Pretty much that's the answer I was looking for. ... 5. I thought about something like [["key1", "value1"], ["... like in Lisp-y languages.
    - valenterry 3y ago
      Yes (5.) is possible, but now your API type becomes "List of List of String" and you need documentation and examples to explain that every list will have two entries and the first one will be the key. On top of that, if you have a different types for keys and values you have an even bigger problem, because lists in graphql need to have one type for all elements. And while you can use a uniontype (like String | Integer) to have strings as keys and integers as values, your user now ends up with an ugly typ in their code and has to untangle it by hand. So the user will have to 1.) know about that it is supposed to be a map, 2.) untangle the list types in their code, 3.) convert it into a map while not mixing up key and value Therefore I usually go with explicit key/value objects if it's okay for performance or go with a custom JSON type if performance trumps the rest.
      - 3y ago
- nojvek 3y ago
  I created a proposal for Map type but didn’t make it through. https://github.com/graphql/graphql-spec/pull/888 https://github.com/graphql/graphql-spec/pull/888 The issue with GraphQL is it tries to appease too many masters. Similar to jsx. The language isn’t evolving. The good thing is the spec is (almost) frozen, so there’s many implementations, the bad is it can’t encompass the flexibility of json schema can do. Going with GraphQL means you have to have good control over both client and server. And like any tool, there are new ways to shoot yourself.
ghnws 3y ago
> It saves a ton of development time. Could you expand on this? I have had the completely opposite experience.
- valenterry 3y ago
  Why don't you explain your experiences first so that we can learn from what you found were drawbacks?

scotty79 3y ago

> Lack of a Map-type. Why do you need special map types for transferring maps? Doesn't list of key-value pairs suffice? Also, why am I wrong to even ask the above questions?

tadfisher 3y ago
A (single-level) Map is generally understood to have unique keys, which allows for some invariants derived from this property, such as a one-to-one or one-to-many object relationship, without runtime checks in client code. I do think it's worthwhile to ask the question, though. I have a strong personal preference to avoid encoding invariants like this in wire representations, because they are properties of the _schema_ and not the wire type (JSON object, in my most commonly-encountered case). Of course, the entire point of GraphQL is to encode invariants in the data schema, so it's entirely reasonable to ask for a built-in Map type instead of building your own for every project.
- jonhohle 3y ago
  JSON (as defined by json.org), for example, does not specify that key/value pairs need to be unique. ECMA-404 explicitly calls this out as an implementation consideration. I know of one implementation that supports multiple entries with the same key.
valenterry 3y ago
It's a fair question. Having a map-type has several benefits: 1. I can signal to my api's users that there won't be any repeating keys without having to write documentation 2. The type can be mapped correctly into the target language. Most languages have a map-type and so it's nice if you don't have to convert it yourself 3. No manual conversion also saves time in most cases, since libraries can do it efficiently in one step. Otherwise you get a list<X> from your library and have to turn it into a map. Not good for bigger lists in performance sensitive applications 4. The same is also true the other way around when sending data to the server 5. It saves space in many serialization formats like json. Instead of [{"key": "key1", value: "value1"}, ...] you get {"key1": "value1", ...} 6. It's nicer to read and debug 7. It's nicer to manually create/write those values in tools like graphiql to test queries by hand and those tools can even warn you if you repeat a key by accident Just some of the things out of my head, I'm sure I've missed a bunch.
- scotty79 3y ago
  1. Pretty much that's the answer I was looking for. ... 5. I thought about something like [["key1", "value1"], ["... like in Lisp-y languages.
  - valenterry 3y ago
    Yes (5.) is possible, but now your API type becomes "List of List of String" and you need documentation and examples to explain that every list will have two entries and the first one will be the key. On top of that, if you have a different types for keys and values you have an even bigger problem, because lists in graphql need to have one type for all elements. And while you can use a uniontype (like String | Integer) to have strings as keys and integers as values, your user now ends up with an ugly typ in their code and has to untangle it by hand. So the user will have to 1.) know about that it is supposed to be a map, 2.) untangle the list types in their code, 3.) convert it into a map while not mixing up key and value Therefore I usually go with explicit key/value objects if it's okay for performance or go with a custom JSON type if performance trumps the rest.
    - 3y ago
nojvek 3y ago
I created a proposal for Map type but didn’t make it through. https://github.com/graphql/graphql-spec/pull/888 https://github.com/graphql/graphql-spec/pull/888 The issue with GraphQL is it tries to appease too many masters. Similar to jsx. The language isn’t evolving. The good thing is the spec is (almost) frozen, so there’s many implementations, the bad is it can’t encompass the flexibility of json schema can do. Going with GraphQL means you have to have good control over both client and server. And like any tool, there are new ways to shoot yourself.

ghnws 3y ago

> It saves a ton of development time. Could you expand on this? I have had the completely opposite experience.

valenterry 3y ago
Why don't you explain your experiences first so that we can learn from what you found were drawbacks?