3 ms·
Some nits: > It doesn't support map/tables/dictionaries. This is actually huge. I get that there might be It does. You can define, say, an "any" or "json" typ
by dmitryminkovsky 4y ago
Some nits:
> It doesn't support map/tables/dictionaries. This is actually huge. I get that there might be
It does. You can define, say, an "any" or "json" type in your schema and emit anything you want at a field with such a type. For example https://stackoverflow.com/a/63588485 https://stackoverflow.com/a/63588485
> No clear path for Api versioning
Some options include:
- Prefixes (`/v1/graphql`, `/v2/graphql`)
- Backward compatibility: only adding and not subtracting things you want to support.
Lots of fair criticisms though. My two cents:
There are very few cases for starting a GraphQL based project by writing a GraphQL server (resolvers, queries, etc). This is where devs waste time instead of exploring their concepts. Instead, use GraphQL with something like Hasura that generates the GraphQL service for you based on database schema.
- ojkelly 4y ago> Instead, use GraphQL with something like Hasura that generates the GraphQL service for you based on database schema. I generally disagree. While Hasura and the like can get you moving quickly, they let you cheat on designing your data model. Ideally it’s a collaboration between all involved to develop a shared understanding of the domain, and the queries and mutations (how to read and write). Where possible avoiding implementation details leaking into the schema will let you change those implementation details when needed. If you auto-generate from a database, your database itself becomes your schema. This is rarely the best way to represent your data model in an API.
- deleted 4y ago[deleted]