{"action":"created","issue":{"url":"https://api.github.com/repos/facebook/graphql/issues/232","repository_url":"https://api.github.com/repos/facebook/graphql","labels_url":"https://api.github.com/repos/facebook/graphql/issues/232/labels{/name}","comments_url":"https://api.github.com/repos/facebook/graphql/issues/232/comments","events_url":"https://api.github.com/repos/facebook/graphql/issues/232/events","html_url":"https://github.com/facebook/graphql/pull/232","id":186040715,"number":232,"title":"[RFC] __id field for unique identifiers","user":{"login":"stubailo","id":448783,"avatar_url":"https://avatars.githubusercontent.com/u/448783?v=3","gravatar_id":"","url":"https://api.github.com/users/stubailo","html_url":"https://github.com/stubailo","followers_url":"https://api.github.com/users/stubailo/followers","following_url":"https://api.github.com/users/stubailo/following{/other_user}","gists_url":"https://api.github.com/users/stubailo/gists{/gist_id}","starred_url":"https://api.github.com/users/stubailo/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/stubailo/subscriptions","organizations_url":"https://api.github.com/users/stubailo/orgs","repos_url":"https://api.github.com/users/stubailo/repos","events_url":"https://api.github.com/users/stubailo/events{/privacy}","received_events_url":"https://api.github.com/users/stubailo/received_events","type":"User","site_admin":false},"labels":[{"id":230925497,"url":"https://api.github.com/repos/facebook/graphql/labels/CLA%20Signed","name":"CLA Signed","color":"009900","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":6,"created_at":"2016-10-28T23:07:34Z","updated_at":"2016-11-01T18:13:14Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/facebook/graphql/pulls/232","html_url":"https://github.com/facebook/graphql/pull/232","diff_url":"https://github.com/facebook/graphql/pull/232.diff","patch_url":"https://github.com/facebook/graphql/pull/232.patch"},"body":"This brings together many of the considerations about a `__id` unique identifier field into one document. There is still a lot of work to do before this becomes a merge-able diff on the spec:\n- [ ] Agree on field semantics specified in this PR\n- [ ] Restructure the spec so that the description for `__id` can live next to `__typename`\n- [ ] Write the change to the spec\n"},"comment":{"url":"https://api.github.com/repos/facebook/graphql/issues/comments/257646709","html_url":"https://github.com/facebook/graphql/pull/232#issuecomment-257646709","issue_url":"https://api.github.com/repos/facebook/graphql/issues/232","id":257646709,"user":{"login":"calebmer","id":8282507,"avatar_url":"https://avatars.githubusercontent.com/u/8282507?v=3","gravatar_id":"","url":"https://api.github.com/users/calebmer","html_url":"https://github.com/calebmer","followers_url":"https://api.github.com/users/calebmer/followers","following_url":"https://api.github.com/users/calebmer/following{/other_user}","gists_url":"https://api.github.com/users/calebmer/gists{/gist_id}","starred_url":"https://api.github.com/users/calebmer/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/calebmer/subscriptions","organizations_url":"https://api.github.com/users/calebmer/orgs","repos_url":"https://api.github.com/users/calebmer/repos","events_url":"https://api.github.com/users/calebmer/events{/privacy}","received_events_url":"https://api.github.com/users/calebmer/received_events","type":"User","site_admin":false},"created_at":"2016-11-01T18:13:14Z","updated_at":"2016-11-01T18:13:14Z","body":"> Another piece of feedback is just at a high level - why should we be including this in the spec with additional behavior rather than simply making an `id: ID!` field a best practice for cacheable types? The spec should be as small as possible and no smaller, so we should ensure we have a strong argument for moving this from best practice to spec.\r\n> \r\n> Specifically I think the argument \"client caches would like to rely on this\" is a little faulty as we already have client caches that rely on different forms of pagination and connection models with those as best practices and no impact on the spec.\r\n\r\nIn my opinion the specification of `__id` is perhaps the most important addition to the spec for GraphQL’s future. Cacheability is a side benefit of what an `__id` field gives us, the `__id` field gives us identity. Vanilla GraphQL is incredibly powerful for the first data query but after that first query reconciling data from mutations, subscriptions, and other queries is an incredibly hard problem. Falcor got the identity story right with paths (at the cost of good pagination), and resource identity was a fundamental principle of REST for good reasons.\r\n\r\nBeing able to identify data is important, so then the next question is how we identify that data. Whichever approach we choose, it must be consistent. There are problems with `id: ID!` which has become best practice thanks to Relay 1, chiefly that the name `id` conflicts with SQL field names. So then we need an alternative, which exists in renaming the field to `__id`. However, using a name like `__id` is useless unless the tooling agrees. In my opinion, fragmentation is not worth keeping this out of the spec.\r\n\r\n* * *\r\n\r\nSo in summary, this issue (in my opinion) is the most important issue to resolve for the long term success of GraphQL, and since there are problems with the community solution (Relay `id` name choice) to avoid fragmentation we should standardize data identity with a solution which is both agreeable by the community and will help to build much better developer tooling."}}
{"actor":{"display_login":"calebmer"}}