Namespaces #163
Comments
|
I think the And still I think #174 have something similar,just a little namespace. |
|
Thanks for writing this up, Oleg! I'm a bit confused as to what this is enabling that isn't already possible or what the immediate goal of using namespaces would be. I also expressly want to avoid namespaces being included and then people naively namespacing everything just because the feature is there, since that would result in a lot of bloated queries. For example, in your post you explain that we could write queries like this: {
person(id: 12345) {
id
firstName
schema.org/parent {
givenName
}
schema.org/knows {
givenName
taxID
}
}
}but I'm curious why you would prefer that over: {
person(id: 12345) {
id
firstName
parent {
givenName
}
knows {
givenName
taxID
}
}
}The latter seems to represent the same thing, but just requires less typing. Is the goal to just describe what the fields relate to? Perhaps we could have metadata about the fields in the introspection system? |
|
I think that the namespaces here enable one to "import" another schema. One could potentially import an schema and build on top of that rather than starting from scratch every time. Implementation wise it looks tough to do though. It might just be easier to import a library (js, ruby, python, java depending on the graphql implementation language) and then build schema using types available from that library. Another reason why namespaces could be useful is so one can filter a introspection query with a namespace string. In a large system the number of types can make the introspection query results quite unwieldy. But then one could always write a custom introspection query that accepted a filter on a field that's common to all types. I can think of another use of namespace which is that the number of top level fields (especially those with parameters) and mutations can become quite unwieldy and so one would have trouble viewing them in a graphql api browser like GraphiQL. Having top level fields and mutations further filtered by a namespace would make things easier on the eye. |
|
@leebyron Thanks a lot for looking into this and giving your feedback! I think we can approach this from 3 different perspectives. First is a semantic meaning of types and fields. This is where schema.org example came from. I think for this one it should be enough to have a user-defined metadata on a field and type level which is exposed via introspection. I think community then can come up with conventions for how to encode this semantic information for use in different tools. The second is the fact that the mutation (as well as subscription) fields share global namespace. Mutation type is the only place where mutation can be defined for a whole GraphQL schema. This is where my original motivation came from. I went into details about this particular point in the original post ("Mutation Type" section). There are several factors to why I see it as a concern. At the moment mutation type should be an ObjectType, which means there that all mutation fields should be defined in it. This makes it hard to work with loosely-coupled parts of the schema which potentially may have name conflicts. In my opinion, one of the contributing factors is also the lack of polymorphism in input objects. This greatly limits amount of logic one can encode in one particular mutation field, which means that different variations of updates need to be represented as top-level mutation fields. Namespaces can provide a solution for this particular problem, but I'm pretty sure that there are also other approaches we can take. For instance, let's imagine that it is possible to use a union type as a mutation type: type AuthorMutation {
create(firstName: String!, lastName: String!): Author
changeName(id: String!, firstName: String!): Author
delete(id: String!): Author
}
type ArticleMutation {
create(title: String!, authorId: String!): Article
changeText(id: String!, text: String): Article
delete(id: String!): Article
}
union Mutation = AuthorMutation | ArticleMutation
schema {
mutation: Mutation
}a query like this would not make much sense because field name is ambiguous: mutation {
create(firstName: "John", lastName: "Doe") { id }
delete(id: "1234") { id }
}but we can use an inline fragment to disambiguate it: mutation {
... on AuthorMutation {
create(firstName: "John", lastName: "Doe") { id }
}
... on ArticleMutation {
delete(id: "1234") { id }
}
}If we provide a shorthand syntax for inline fragments, it can become a bit more cleaner: mutation {
AuthorMutation/create(firstName: "John", lastName: "Doe") { id }
ArticleMutation/delete(id: "1234") { id }
}This code violates the semantics of inline fragments and union types - they normally represent 2 mutually exclusive fields, still I use them here just to disambiguate the field names, so both mutation fields would be resolved. For the sake of example I use this approach simply because there is already syntax available for it in the language. The point I would like to make is that this example does not involve namespaces, still it addresses my issue with the global namespace for the mutation fields. The third perspective is the the global namespace for the types. I recently had a few conversations with different people who are thinking on introducing GraphQL in their projects and companies (from small to pretty big). One question that came up several times in the discussion is whether GraphQL should serve as a facade for different internal services managed by different teams and if yes, then how does DDD fit into this picture. I do believe that GraphQL is a perfect fit for a facade API. Many client applications often have cross-cutting concerns, so it is very helpful to provide a facade for these client through a single GraphQL API, especially if clients are constrained in some ways (like mobile clients or embedded devices). On the other hand I find it helpful to think about different internal services as a bounded contexts. Each bounded context comes with it's own ubiquitous language. Given a system designed with these principles in mind, name conflicts are actually desired, but ubiquitous language within different bounded contexts can define very different semantics for the same terms (like User, Account, Product, etc.). I don't want to say that it's the best way to model system or anything like this, it's just some people use it and find it helpful for their own systems (including myself). This is where namespaces can be a very helpful tool when designing a GraphQL facade that aggregates several bounded contexts. I would be really interested to know your opinion on this topic. Do you think that GraphQL is suitable as facade in these kind of systems and if yes, then will you try to define the single model for all bounded contexts or you will try to preserve the ubiquitous language of every bounded context and minimize a common/shared area of the schema? (/cc @dschafer, @schrockn)
Indeed, I do share this concern. I guess if one asks himself whether he/she needs to use namespaces, then the answer is probably no. On the other hand, as I described above, namespaces may be a useful tool to solve particular challenges (although, not the only possible tool in every given case).
Indeed, in this particular example query I would normally skip the namespaces. This is the nice thing about the namespaces in contrast to naming conversions and other namespace emulation techniques which have quite a few disadvantages: even in presence of namespaces one can just skip them if they are not necessary (some implicit namespacing rules will apply in this case). There are also a few reasons why I may use explicit namespace in this query:
That said, I don't really want push concept of namespaces per se. My main goal is to address some of the issues, like global namespace for a mutations fields. Whether it is solved with namespaces or not does not really matter. I hope what I described here reveals a bit my original motivations for this proposal :) |
|
Hi @OlegIlyenko , Nice elaboration and spec you`ve written down! In general I see a clear need for a namespaces mechanism. I am currently writing microservices that communicate using graphql. With microservices architecture each microservice represents a separate bounded context (in DDD terminology) and you can easily get type conflicts when there are many of them around. I.e. same name, different semantics, etc. Also - like you said - there will be a need for common (base) types to be defined. Your proposal certainly has its charms, especially the notation. Yet I also have a number of reservations:
In another issue I proposed a more general metadata mechanism, that is an extension and not breaking. See #200 Using this metadata proposal for namespaces, however, is far less powerful than what you propose. But it can be adjusted. What I like in this is the freedom it leaves to implementers. Finally, I would be in favour of having a lean and mean base spec, and then have an extension mechanism that allows you and others to offer the kind of cool stuff you propose. It could be a standard extension. And I could consult a server to see if it supports this feature before sending my query (Note this is similar to the extension mechanism in OASIS CMIS spec and others). Arnold Schrijver |
|
Just a note: I'm currently writing a wrapper around existing REST approach based on microservices (with plenty of endpoints) and namespaces are very wanted, otherwise all type names look like fact_reports_pp_campaigns_delivered |
|
I would also appreciate namespaces for all of the reasons stated above by @OlegIlyenko. @leebyron Given that Facebook has nearly 10,000 types, how does it keep track of type names and query/mutation fields (which I am assuming there are hundreds if not thousands of as well)? Are there any best practices for merging schemas from multiple sources? |
|
As our mutation root grows we've been asking the same questions internally.
Anyway you can share alternative solutions or insight on how you've been handling that problem @leebyron 🙏 ? |
|
This might be totally off the wall and possibly even a stupid comment showing my lack of understanding, but couldn't different URLs and a routing middleware be used like namespaces? One could split up a larger app among different endpoints that way. So, a bigger site would have https://some-site.com/user etc. And if things are getting too involved even with this "namespacing", you could also break it down more. https://some-site.com/user/profile (or register) I know, I know. We are heading towards something RESTy-like again with that idea, but it isn't really REST, right? This might not solve the microservice communication issue, which I believe this idea came from. But, I think it solves the "big schema" and "name collisions" issues, since each endpoint would have its own schema. You'd also get the decoupling, which was asked for. It would allow for better asynchronicity too, because you could hit different endpoints at the same time, if needed, which I don't think would be too often. It would allow for parallelism, because breaking up into separate endpoints, theoretically, would allow a system to be scaled out much more easily later on too. And, if you refine the URLs, it isn't a breaking change. The cons would be duplication. But really, if an app gets that big, I would imagine creating schema would be automated in some way anyway, right? Or does Facebook really have their devs go into the schema and alter or add to it all the time? I find that hard to believe. I'm sure this blows away some other general concept that makes GraphQL so great, which I am completely missing due to my own lack of understanding. So, please do give me hell. All I can do is learn. 😄 Scott |
|
I'd like to note that allowing namespaces to be optional as long as they're unambiguous may difficult future developments of the schema, since you cannot safely add new types that would add namespace ambiguity having already allowed clients to write unnamespaced queries. Regarding syntax, |
|
As @khamusa point out:
So you force all consumers of your API to bloat their queries by prefixing every type and field. And the biggest concern I have is that people starting to auto-generate one huge GraphQL proxy to expose a bunch of microservices without even try to reuse common types. And instead of solving communication problem in your organization you forcing your API clients to work around this by using prefixes and reading a ton of docs to understand the difference between: It certainly possible to do the same stuff right now by making Finally, as it was pointed out previously |
|
@IvanGoncharov illustrated a number of API design abuse patterns that worry me as well. I've still yet to hear a compelling argument for why namespaces are necessary. The only argument I've heard so far is naming collision. Frankly, that's been a non-issue for us at Facebook and our schema continues to grow well over 10,000 types. We avoid naming collisions in two ways:
We don't allow any commit to merge into our repository that would result in a broken GraphQL schema. This test is pretty simple and fast to run, we just boot the server and if it fails to boot with a GraphQL error, we fail the test. Two types or fields on a type of the same name would cause such a failure. This kind of test ensures our master branch isn't constantly broken, and protects against name collision problems. If someone accidentally choose the same name for a new type, they can resolve the problem. Often, resolving it actually means using the existing type rather than renaming the new one. That keeps our API internally consistent and avoids duplicate information.
We have common patterns for naming things which naturally avoid collision problems. For example, mutations often follow a "verbNoun" pattern such as "likeStory" assuming that the noun is the type it operates on and your types also don't have conflicts as well, this naturally avoids conflict. I suppose with namespaces you could have written "Story/like" but that doesn't offer clients anything they didn't already have, and it might force them to handle multi-part names when reading the result. For types, we try to generalize as much as possible so that we have types shared across products. That makes future product integrations easier as well. For products that shouldn't integrate, or have similar concepts that are rightfully different, like a Facebook Event and an advertising logging Event, we alter the name to clear the ambiguity for the reader. |
|
Say I'm looking at your API in graphiql, I'm either a new fb hire or some dev looking to integrate with a part of your API. I pick 1 of your 10,000 types and I want to dig into the mutations that fall under this type. How do I, as a new hire or third-party dev, easily consume this information? |
@leebyron How do you not end up with horrible caterpillar names like @xuorig said? I have not so very big schema and this is already a problem. I tried to look for examples of big schemas or best practices. Nothing. Every article I could find is based on a schema with ~3 simple types. If you have anything please consider answering this question. |
Typically our types do not correspond 1:1 with mutations. We typically do not have CRUD style mutations, instead we often have RPC style mutations that correspond to user events. In the cases that there is a closer relationship, the most common mutations are typically mentioned in the description of the type. For example the As I mentioned in the prior comment, naming conventions can help a lot. If you're looking at GraphiQL, the ideal experience is that you start typing what you expect to work and get typeaheads with helpful suggestions. In addition to this, both search in the documentation explorer, and helpful descriptions with recommendations for common mutations are all part of the strategy of providing information in the right places at the right time. |
|
@maciejkrol - our type system has many types, but with some clear and easy to follow naming conventions we balance between clarity, conciseness, and expandability. The primary goal when naming things in a type system expected to expand in the future is to have clear answers for these two questions:
For example at Facebook we have a type called |
|
@leebyron my only concern with your suggestions is that the Our schema has two entry points, which is really nice. Our mutations however are in the hundreds... and without being able to split them up a bit, the generated documentation becomes useless to our developer teams. |
|
@Cyberlane this issue might be related #252 :) |
|
The ideal situation is one in which you have complete control over the design of your schema and can justify a well-crafted set of type names. Unfortunately, many of us are in a different situation: we have an ever-growing and ever-changing set of disparate backend data sources described with something like Swagger and would love to be able to import them on the fly without curating them. Maybe namespaces aren't the best idea. But it would be great to have some kind of support for this scenario. |
|
@leebyron For cases where you know the object you would like to mutate, but don't know what cutesy name your colleagues decided to give the mutation (updateStory, changeStory, likeStory), I think this would get annoying. Think about this: why do we organize our functions into modules and namespaces as programmers? Don't those reasons also apply here? Also, what about allowing it only for top level fields? A lot of what I see in this thread looks messy/overkill, but allowing it just for the top level would solve most of the problem. Fields after the first level already have a context, so further namespacing after that may cause more problems than it solves. |
|
https://github.com/Quture/app/issues/1 This is exactly what I need for ^^ |
|
Hi, I'm pretty new to GraphQL, so please take my comments with a pinch of salt, but I see the need for namespaces for some usecases, and I think there are several distinct reasons to want them.
You might say why do we need portable clients? But we already have the need for one as the Namespace & module systems often allow importing a namespace as an alias, e.g. you could imagine something like the following (inspired by SPARQL), though I suspect you could find a prettier syntax: ALIAS myns: <http://foo.com/mynamespace>
ALIAS schema: <http://schema.org/>
{
schema/name
myns/name
}Unnamespaced names with the exception of @leebyron's idea of putting this data into the introspection system sounds like an interesting proposal, though I'm not yet sure if it would be equivalent to first class namespace support. |
|
This should happen. Lee may not support it but the standard is bigger than FB now. 👍 |
|
I don’t want to really double post and definitely don’t think my thoughts on the topic are crystallised well enough to actually partake in this debate, so for now I wanted to just link to some rough thoughts on this subject in the context of ‘stitching’ schemas from various services ardatan/graphql-tools#495 (comment) |
|
The field import idea that I introduced above does not work. Please ignore. |
|
I think we should start a working group to champion the namespaces. It is a big change that won't be done unless there is some organization to write the formal proposal. |
Funny you should say this. @zcourts and I decided several weeks ago to come up with a draft proposal. I'm waiting for his feedback, and I realized that I maybe should rearrange things to make them more clear. Right now it's a Google Doc, but I hope we can turn it into an organized proposal shortly. |
|
Hi everybody And it's not just me of course. I think this issue is LOOONG overdue, I am surprised to see it lingered for so long; it is clear from this and other posts that this is a huge pain. And simply from experience of working with BIG systems. Just wanna induce a sense of urgency. If we want GraphQL to live and prosper, we need to make it friendly for big systems. |
pinshen zhe li du you ni . |
I do agree. In my daily work, the lack of namespaces is a challenge. If you create an enterprise endpoint for a big company, or for a company which operates in many sectors, despite all your careful approach with naming, the clash of type is always there waiting for you. |
|
Another use-case can be seen in the emerging WPGraphQL ecosystem. similar to the microservices or enterprise use-cases, except users arent writing their own schema, but rather using essentially premade microservices written decentralized by a myriad of developers with an expectation that everything will work together. And unlike FB's approach, you cant realistically run integration tests against a decentralized ecosystem. (Yeah yeah, WordPress is for luddites, but considering it powers more than 1/3 of the internet, thats a lot of websites that would be better served with GraphQL). |
|
There are certain places where namespaces make sense and alternative solutions will not work or become so cumbersome that using GraphQL becomes painful. Our system allows users to create GraphQL schemas at runtime and it's also based on a plugin model. So as a backend framework developer, I have no idea what the types will look like on any given system. We had to introduce our own version of namespacing in order to prevent this problem. I can't rely on compilation, tests, etc to make sure there are no naming collisions. |
|
I'm currently designing a highly complex yet decoupled system and the lack of namespaces is a big hurdle we're currently facing, while naming conventions help to a certain degree, enforcing them is unpractical due to how hard it is when you have multiple unrelated parties involved |
|
Have we started a namespace-capable branch of the GraphQL reference
implementation (apollo?)? This branch might be a good way to start
identifying the to-dos to make this happen. I see GraphQL with namespaces
as the natural successor to SPARQL, and better implementation of LDP for
Linked Data.
Eric Jahn
CTO/Data Architect
Alexandria Consulting LLC
St. Petersburg, Florida
727.537.9474
alexandriaconsulting.com
…On Mon, Feb 14, 2022 at 9:06 AM Andrei Borisov ***@***.***> wrote:
I'm currently designing a highly complex yet decoupled system and the lack
of namespaces is a big hurdle we're currently facing, while naming
conventions help to a certain degree, enforcing them is unpractical due to
how hard it is when you have multiple unrelated parties involved
—
Reply to this email directly, view it on GitHub
<#163 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA7MVB2WGSK4TLMBJJFJVS3U3EDZZANCNFSM4CAP2ICA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
This is a fascinating proposal! I’ve been following it for a while. Glad to see more cases being made. The impact across many graphql ecosystems would be immense - but imagine what other features this could unlock? I have also seen this in large schemas, where type names become increasingly complex, people use underscores to delimit faux namespaces, etc @eric-jahn You can open a branch for What I found super helpful when working on the input union PRs was using TDD. Also noting that this proposal needs someone to enlist themselves as a champion still. |
|
All:
I feel like I should say why I've been so quiet.
Buttonsmith has decided that we will not move forward with GraphQL. I
remain very interested, and we'll be very happy to continue to host the
discussion.
The principal reason we will not be continuing with GraphQL is that some of
our client code needs to be written in statically typed languages (mainly
C#). GraphQL's query language design - and especially the client-side
caching design - aren't terribly friendly to statically typed languages.
Yes, it can be done, and yes, I understand how (among other things, I'm a
recovering PL architect), but I don't have time to do it and it doesn't
make sense for us to build a one-off query language.
From a PL design perspective, there are three challenges with any namespace
proposal:
1. There are several ways it might be done, but there is no way to sensibly
combine mutation (or query, or subscription) operations across
modules/namespaces without removing the dependency between the type name
and the semantics of the type.
The decision to make Query and Mutation and Subscription *types* rather
than declarations was a serious design mistake. If these are to be type
based, they should be expressed by a type qualifier (so mutation Foo { ...
}). The existing type names can be grandfathered.
This has consequences for server-side resolvers; it's not a small change.
2. You will need to make a decision about type equivalence. GraphQL
currently uses name equivalence, and I think that's the right call. But
when a type is renamed on import that should not change the equivalence
behavior of the type. Similarly, if it is subsequently renamed on export,
*that* shouldn't change the equivalence of the type either.
Conceptually, the "normative" name of a type is it's fully qualified name
in its defining module/namespace. All names created by import/export are
merely aliases.
3. In the IDL, there is a notion that *partial* type definitions that can
be introduced in multiple places and then merged. This breaks horribly if
module B can extend a type defined in module A, because you can have two
different consumers, one of whom consumes B and the other does not. When
this happens, they will see two different definitions of the type, and the
server-side resolver will not be able to distinguish what is happening.
Partial type merging should be restricted to occur in a single namespace.
The rest is syntax. I won't go so far as to say that all choices are
equally bad, but there are good models to choose from. Speaking for myself,
I like the way Typescript has handled this, mainly because they are
following the type equivalence rules that I outlined above.
Jonathan
…On Mon, Feb 14, 2022 at 9:39 AM Rikki Schulte ***@***.***> wrote:
This is a fascinating proposal! I’ve been following it for a while. Glad
to see more cases being made. The impact across many graphql ecosystems
would be immense - but imagine what other features this could unlock? I
have also seen this in large schemas, where type names become increasingly
complex, people use underscores to delimit faux namespaces, etc
@eric-jahn <https://github.com/eric-jahn> You can open a branch for
graphql-js to get started, which is used by apollo, relay and urql
clients, and is also used by many node.js graphql schema server
implementations as well, such as apollo server, helix, etc. Some which
don’t need AST like mercurius use graphql-jit.
What I found super helpful when working on the input union PRs was using
TDD. graphql-js has phenomenal test coverage, much of it using literal
graphql operations.
Also noting that this proposal needs someone to enlist themselves as a
champion still.
—
Reply to this email directly, view it on GitHub
<#163 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AQPXV7Q3OOTEEW7NZTMN6EDU3E44VANCNFSM4CAP2ICA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
@b-jsshapiro - I am very interested in what you said; can you please contact me directly at rivantsov-at-gmail.com, or thru post/issue here: https://github.com/rivantsov/ngraphql . I am in a quest to challenge the belief that c# and other strongly typed languages are not so fit for GraphQL (and especially clients), and I would like to hear more if you don't mind. thanks in advance |
|
Roman:
I'll be happy to take up the static typing question with you offline, but I
actually think it's worth talking about this briefly here. I had looked at
ngraphql a while back, and it looks like nice work.
We can clearly build static types for:
- Any type declared in the IDL
- Any argument or return type that is written in an IDL executable query.
- Consequently: any query, mutation, or subscription operation.
We can even generate static types for client-side caching. The easiest way
is to take every type T that is declared (or better: returned by an actual
query), and produce a type T' as follows: if a ; A is a field in T, then
a:cached<A> is the corresponding field of type T'. The type cached<T> is
conceptually similar to a maybe type, and with care it would be possible to
maybe<T>, but note that type A may *already* be a maybe type. For clarity,
it seems better to distinguish cached<T> from maybe<T>.
If this is done, then output types consist of getters/setters that
reference the values stored in the cache. I would argue that input type
fields should always be copies, but that's something that could reasonably
be debated.
Whenever a value arrives at the client, the cached value is updated at all
of the fields that have actually arrived.
So yes, it can be done, and as long as you don't look at the types used in
the cache, it isn't unspeakably ugly to use.
*But*...
1. There is no restriction in GraphQl saying that the server can't send
more fields than you requested. This complicates client-side demarshaling.
Offhand, I *think* this ends up meaning that objects in the cache want
to be represented by map<string, dynamic> rather than my hack above.
2. There is no restriction in GraphQL that the schema is static! It is
perfectly okay to implement a service that allows fields to be added to
types *on the fly*. a PIM system is one example where this would
actually make sense. *There is no natural way to express this in a
static type system*. If I twist my head backwards and barf preemptively
in self defense, I can see how to abuse reflection and type dynamic to pull
it off, but at that point we're actually implementing dynamic types rather
than static types.
And here's some personal irony: (1) I'm notoriously a static typing guy.
(2) My company is actively looking at building a system which, like a PIM
system, modifies the schema dynamically.
Jonathan
… Message ID: ***@***.***>
|
|
b-jsshapiro, I opened a new thread for continuing, I have a few more questions, but this subject is out of place here; |
Can you both publish here the branch as well? I do not see it (yet).
Not good at coding, but I can help championing this. I am sure there would be a value also for system dealing with federation like Apollo. Federation does not address the problem of a single namespace. I've seen and dealt already with types long 60+ chars; yes they are super clear, but also ugly to read. |
|
@LunaticMuch @acao What should we call the branch? Maybe "graphql-namespaces"? I don't know how much time I have to devote to this, but I can definitely help out. I see GraphQL as the new Sparql for Knowledge Graphs/RDF. |
Looking at other names maybe
It is a nice way to see it. You share meaningful data with GraphQL and this translates into information and knowledge (well I know, it's a kinda philosophical statement). BTW @acao should not this be first (or also) an update to GraphQL specifications? Are we going to think how to make it happen in |
Oh, there's some prior work here! Have a look at GraphQL-LD. It applies JSON-LD's concept of contexts—which tie globally unique IRIs to friendlier key names within the scope of a particular JSON document, thus implementing a kind of namespacing—to GraphQL queries. So it's literally built to query over RDF-style graphs. |
|
@benjie Will the issue of namespacing be covered under the new composite schema WG? I do feel strongly that it should be part of the discussion as this is a common pain point of the current integrations of schemas. |
|
Should it be determined at the composite schemas WG that namespacing is the desired solution to this problem, then namespacing would need to make its way through the regular spec process as part of the spec WG to enable the composite schemas spec to use it. I definitely imagine that the composite schemas WG will result in some changes in the GraphQL spec proper, though I suspect it'll be changes along the lines of schema metadata (e.g. #300) rather than namespacing. Who knows though? Only time will tell! |
|
I think we need to create a formal standalone recommendation for namespacing within the GraphQL Spec WG (referencing OWL ontologies, vocabularies, and even JSON and XML Schema namespaces). That way, we aren't trying to rapidly shoehorn it into other GraphQL specification efforts, and it can be fully vetted on its own. I'm willing to help with that effort, and to rope in others to support it. Does anyone here have the means to establish a recommendation workgroup within the GraphQL community? Admittedly, I'm not very familiar with how the GraphQL spec is governed. It looks like the GraphQL Foundation, hosted by the Linux Foundation governs it, but I need to learn more about how it works. |
|
Please have a read of the CONTRIBUTING guide, changes to the spec take place through RFCs. Currently this topic is at RFC0, the next step would be to try and advance it to RFC1. I advise that you find a champion (perhaps yourself) and have them work on an RFC document; RFC documents are typically filed here: https://github.com/graphql/graphql-wg/tree/main/rfcs . If you have a solution in mind then you can start making the spec edits in a PR against this repo, and then present it to the GraphQL Working Group for feedback. Please feel free to reach out to me ( |
|
To discuss this more informally, we have created a discord channel for graphql namespaces: https://discord.com/channels/625400653321076807/1001141142399750185 |
|
Interesting thread. I'm fairly new to GraphQL. Wrote a GitHub GraphQL query a few months ago to tabulate event data. In my own opinion, the Apollo Server docs nail this issue down with Tech Note 2: Namespacing by Separation of Concerns, where they note you can effectively create artificial namespaces:
{skip a bunch of example code} They then go on to say there is a key drawback:
{skip example code}
|
|
A lot more discussion recently in the Discord channel mentioned above, as well. Hmm ... resolving namespaces by Separation of Concerns sounds problematic to me, since the common use case for namespaces are to commingle data elements across namespaces in a single API request/response, XML complex element, RDF triple, etc.. The separation then has to exist at the namespace definition level (schema, ontology, etc.). |
|
Any movement? I'm just starting to use a large library API written with graphql and noticed that there are a very large amount of queries in root, and it seems like a complete mess. REST works nicely in the fact that you can make it modularized. Wanna find /users/* related methods in most frameworks? It's usually organized and you can find the controllers ready and each method builds off of the class defined route. Namespaces would essentially do similar as others find out quickly, but 8 years later makes me feel like it might not go forward. Perhaps a different approach could radically change graphql. Implementing different routes. Having a query like /users/all() followed by a second query /admin/settings/get(something) would be pretty nice. REST-ish but also graphQL. |
and others
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.
I tried to describe this feature in detail in following article (which also includes motivation and different use-cases):
GraphQL Namespaces Proposal
After 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.
I 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.
The text was updated successfully, but these errors were encountered: