Customize Node interface assumptions

[Quart3z]

Hi first time here, just wanna ask about the issue I've faced when running houdini generate.

Your project defines a Node interface but it does not conform to the Global Identification Spec.

If you are trying to provide the Node interface and its field, they must look like the following:

interface Node {
        id: ID!
}

extend type Query {
        node(id: ID!): Node
}

For reference, I am using type of UUID as id for each of my query and custom nodeId for globally unique identifier, for example

type Address implements Node {
.
id: UUID!
.
nodeId: ID!
.
.

and this is the interface for Node:

interface Node {
  nodeId: ID!
}

Sorry for the dumb question, am I missing something or Houdini requires NodeId strictly in the name of id? Thanks in forward

[jycouet]

👋 welcome, it's a good question that can help other.

Having the interface Node is the first part, do you have also the second part with the resolver? Something like:

extend type Query {
  node(id: ID!): Node
}

I'm not sure about the UUID type as it's not part of the 5 default SCALAR provided by GraphQL. (Int, Float, String, Boolean, ID).

Do you have a public repo to play with this a bit? If not, let me know and I will test something on my end.

[AlecAivazis]

Ah damn. This is the one situation the API doesn't cover 😦 The issue you are running into is that you have a Node interface but it doesn't match our expectations - is that something you can fix on your end? If you have a Node interface, houdini expects it to look like this:

interface Node {
  id: ID!
}

Unfortunately, it'll probably be awhile before we can find some time to address.

[Quart3z]

@jycouet @AlecAivazis thanks for the replies guys, much appreciate. I've solved the issue by modifying my own schema so it's now compatible with Houdini

[AlecAivazis]

I'm going to close this as Won't Fix. I know it'll probably bother some people but at this point Node has pretty universal semantic meaning so unless there is an overwhelming desire to fix this, I don't think it's worth the effort

[AlecAivazis]

Just wanted to remind anyone running into this issue that in v3 hasura now supports the standard id field!!! 🥳

[KyleFontenot]

I'd like to open this up for reconsideration. If the expected Node interface is id, instead of nodeId, that essentially means for automated schemas that use nodeId we have to manually edit the whole schema, and we can't use the watchSchema feature at all.

In addition to manually changing interface Node {}, this also means that each table type cannot have a id column because they're duplicates. I think it's a very tall ask to expect everyone to not have a column named id in any database table, especially because primary keys are often named id, and renaming primary keys is a big mess.

Here's an example:

type bookmark_table implements Node {
  id: ID!     // <- forced to use id for Houdini to work.
  id: BigInt!   // <- Db table primary key. Am forced to rename this 
  some_column: String
  date: Datetime
}

I'd be interested to see how Hasura prevents this from happening without preventing someone from creating a id column in the tables or transcribing it for the sake of the graphql node interfaces.

I have not dived into the code to offer a pull request, but I think having the option to name the Node interface would be very valuable for flexibility.

[jycouet]

If I'm not mistaken, you can still do defaultKeys in houdini.config.js.

/** @type {import('houdini').ConfigFile} */
export default {
  // ...
  defaultKeys: ['nodeId']
}

---

I don't know the solution of Hasura, but in postgraphile, I know that the id in db is exposed as idRow in GraphQL and id in GraphQL is the node id. Nice trick. ^^

[KyleFontenot]

If I'm not mistaken, you can still do defaultKeys in houdini.config.js.

/** @type {import('houdini').ConfigFile} */
export default {
  // ...
  defaultKeys: ['nodeId']
}

I don't know the solution of Hasura, but in postgraphile, I know that the id in db is exposed as idRow in GraphQL and id in GraphQL is the node id. Nice trick. ^^

Sorry took a while to get back to this, but yes I can confirm that defaultKeys works beautifully 👍 Didn't know it existed until your comment. Might be good to add to documentation. Thank you