Comment by replygirl | Hacker News Reader

Comment by replygirl | Hacker News Reader

> It is actually a pain to use, depending on the backend you are using you'll have to manage two or more type systems if there are no code first generates in your language

hasn't been a problem for years in the ts, python, and .net communities

> It doesn't support map/tables/dictionaries. This is actually huge. I get that there might be some pattern where you don't want to allow this but for the majority of situations working with json api's you'll end up with a {[key: string] : T} somewhere

unions, embedded types, and custom resolvers, OR better api design

> No clear path for Api versioning you'll end up with MyQueryV1.01 MyQueryV1.02 MyQueryV1.03

this one is actually insane. /api/v1/graphql. sounds like you are new to apis

---

all of the complaints i hear about graphql have come from people who are early in the process of learning it and/or have built up faulty assumptions through malpractice

In a traditional REST api I can version each resource independently. I can make a breaking change to just one type and it affects that type alone. Graphql is inherently less flexible in this respect as I have to version the entire API together as a single unit.

Graphql itself has no concept of versioning so I need to go out of my way to host a different schema at a different endpoint. And god help any client that's not consistently up to date with the latest schema in all places. You want to query for new feature X only available in api v2, but your client is on api v1? Better go back and upgrade all your existing api v1 schema queries first. Or have a separate gql client for each api version, and remember to use the correct one in the correct place.

Saying "just use better api design" isn't an answer to missing maps. Maybe I am dealing with third party data where I don't have control over the schema?

> > It doesn't support map/tables/dictionaries. This is actually huge. I get that there might be some pattern where you don't want to allow this but for the majority of situations working with json api's you'll end up with a {[key: string] : T} somewhere

> unions

Then you need to know the keys in advance

> embedded types, and custom resolvers

That is "kind of" cheating. I think OP meant a builtin type.

> OR better api design

Sometimes possible but not always.

It's a valid criticism. Emulating another http endpoint in graphql should be super simpel in the best case, but sometimes it is not.

Another example where that is true is union inputs - you can define and return a union of types, but you cannot accept the exact same union in a mutation. Very very unfortunate.

Reply on news.ycombinator.com