-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The Node interface and globally unique IDs #112
Comments
@zth Thanks for the above input. I think your suggested approach is very reasonable and wouldn't be too difficult to implement. If we were to use a directive, I think something like the
Customizing the id via the That said, I also kind of like your idea of having a global setting for this. That would make for better DX, and might also simplify the implementation a bit. I would imagine wanting to enable global ids for only some of the types in the schema would be quite an edge case. |
Hi!
I'm interested in exploring and discussing what it'd take to implement the
Node
interface (and with that globally unique IDs) in Sqlmancer. This + connection based pagination would ultimately mean that Sqlmancer will be compatible with Relay, which would be a very nice thing 😀Below are some initial thoughts from me (https://graphql.org/learn/global-object-identification/ is recommended reading if the reader is unfamiliar with globally unique IDs and the Node interface in GraphQL):
The Node interface
For illustrative purposes, let's say we're implementing the
Node
interface as a directive@nodeInterface
you can use onOBJECT
. This is probably a bad idea (a better idea is likely some form of global setting to enable "Relay mode"), but let's use it as a way of exploring implementing theNode
interface and globally unique IDs in Sqlmancer:Now,
id
defined in the model will be a database ID, which probably won't be globally unique, or contain enough information to decipher what type it's representing (which theNode
interface needs). However, my thinking is that the@nodeInterface
directive could do something like this;The
id
field that's changed could then be implemented to just change the resolution of itself to somethingNode
-interface friendly:This could then be re-used in the
node
field onQuery
:I believe this would accomplish what's needed for the
Node
interface and globally unique IDs.Here's a few issues and things I've thought about that needs consideration:
id
in input positions - if the IDs are now globally unique, they'll need decoding before being used in SQL etc.id
in relations and similar things - same as above, will need decoding.This was a quick write up of my thoughts, I hope it's not terrible to read. What are your initial thoughts about something like this? Do you see any immediate blockers or issues?
I'm btw very willing to spend time implementing this if there's interest for it!
The text was updated successfully, but these errors were encountered: