GraphQL PRO vs CON

gistfile1.txt

PRO:
- Self documenting. Exploring data becomes trivial.
- Mobile devs can request everything once
- Mobile devs only get the data they need
- You don’t have to know your active record relations.

CON:
- You have to manually write all end points
- Attributes can become bloated. Suppose we make a breaking update to an attribute.  The solution is to create a new attribute.

TBD:
- How to limit attributes by user role
- Performance of nested finds.  Does graphQL know how to optimize find to include associations.  (Concerned with the performance implications)
- How does graphQL compare to jasonapi?

Wishlist:
- I wish it automatically built all the attributes as default string

Questions:
- Update/Create records need to be clearly defined.  
- How do you add a where clause to a list

Maybe on the first CON, you actually mean: fields (In GraphQL terms) rather than end points? since there is only 1 endpoint (URL speaking), although nothing prevents us to create more URL endpoints

Actually you probably want to avoid having multiple URL endpoints or more than one schema as it doesn't look like it was intended for that when considering how interfaces is designed. Maybe it's just a bug with InterfaceType though and will be fixed later. But basically if you have two schemas, if you use the same InterfaceType in the two schemas, using it the second time will wipe out @possible_types from the first schema because InterfaceType objects stores @possible_types on itself.

But this will probably be fixed in the future. Interface's possible types should be a property of the schema, not the interface.