{"action":"created","issue":{"url":"https://api.github.com/repos/facebook/graphql/issues/163","repository_url":"https://api.github.com/repos/facebook/graphql","labels_url":"https://api.github.com/repos/facebook/graphql/issues/163/labels{/name}","comments_url":"https://api.github.com/repos/facebook/graphql/issues/163/comments","events_url":"https://api.github.com/repos/facebook/graphql/issues/163/events","html_url":"https://github.com/facebook/graphql/issues/163","id":147272840,"number":163,"title":"Namespaces","user":{"login":"OlegIlyenko","id":156569,"avatar_url":"https://avatars2.githubusercontent.com/u/156569?v=4","gravatar_id":"","url":"https://api.github.com/users/OlegIlyenko","html_url":"https://github.com/OlegIlyenko","followers_url":"https://api.github.com/users/OlegIlyenko/followers","following_url":"https://api.github.com/users/OlegIlyenko/following{/other_user}","gists_url":"https://api.github.com/users/OlegIlyenko/gists{/gist_id}","starred_url":"https://api.github.com/users/OlegIlyenko/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/OlegIlyenko/subscriptions","organizations_url":"https://api.github.com/users/OlegIlyenko/orgs","repos_url":"https://api.github.com/users/OlegIlyenko/repos","events_url":"https://api.github.com/users/OlegIlyenko/events{/privacy}","received_events_url":"https://api.github.com/users/OlegIlyenko/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":33,"created_at":"2016-04-10T22:06:10Z","updated_at":"2018-03-03T09:12:53Z","closed_at":null,"author_association":"NONE","body":"At the moment all GraphQL types share one global namespace. This is also true for all of the fields in mutation/subscription type. It can be a concern for bigger projects which may contain several loosely-coupled parts in a GraphQL schema. \n\nI tried to describe this feature in detail in following article (which also includes motivation and different use-cases):\n\n[GraphQL Namespaces Proposal](https://medium.com/@oleg.ilyenko/graphql-namespaces-proposal-2a097ce81d2a)\n\nAfter posting this it, I saw interest from different people within the GraphQL community, so I decided go one step further and open this issue in order to suggest inclusion of this feature in the spec and start a discussion around it.\n\nI suggested particular syntax & semantics for the namespaces, but I myself still not 100% sure that it can be used as-is. I hope, that as we discuss it, we would come up with better syntax and semantics (or maybe even entirely different feature) that better fits existing language features and covers described use-cases.\n"},"comment":{"url":"https://api.github.com/repos/facebook/graphql/issues/comments/370133058","html_url":"https://github.com/facebook/graphql/issues/163#issuecomment-370133058","issue_url":"https://api.github.com/repos/facebook/graphql/issues/163","id":370133058,"user":{"login":"acjay","id":1256382,"avatar_url":"https://avatars2.githubusercontent.com/u/1256382?v=4","gravatar_id":"","url":"https://api.github.com/users/acjay","html_url":"https://github.com/acjay","followers_url":"https://api.github.com/users/acjay/followers","following_url":"https://api.github.com/users/acjay/following{/other_user}","gists_url":"https://api.github.com/users/acjay/gists{/gist_id}","starred_url":"https://api.github.com/users/acjay/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/acjay/subscriptions","organizations_url":"https://api.github.com/users/acjay/orgs","repos_url":"https://api.github.com/users/acjay/repos","events_url":"https://api.github.com/users/acjay/events{/privacy}","received_events_url":"https://api.github.com/users/acjay/received_events","type":"User","site_admin":false},"created_at":"2018-03-03T09:12:53Z","updated_at":"2018-03-03T09:12:53Z","author_association":"NONE","body":"@yordis I'm for your plan or something like it. I was saying it's a shame we wasted a decade faking namespaces poorly in those other web techs. Especially when it's really pretty simple to make a namespace/module system that's there when you need it, but out of the way when you don't.\r\n\r\n@rydrman I think I can rephrase what you're saying: in a perfect world, GraphQL hides system boundaries as an implementation detail and just provides a fresh type space. I love that concept in theory, but in reality, I think it would involve painstaking manual composition of types and resolvers. But I also don't think it should be necessary to choose one or the other. A gateway API could present a consolidated schema, while still proxying underlying schemas in their namespaces. I think the former is ideal for applications to consume and the latter for prototyping and operations. "}}
{"actor":{"display_login":"acjay"}}