feature: Ability to disable automatic "interface labels"

[jorroll]

When I ran into bug #138, it caused me to notice that the auto-generated mutations (which are SUPER SUPER COOL btw) are automatically adding a label for each interface a type implements. This leads me to strongly suspect that these extra interface labels are also used as filters when traversing relationships involving interfaces.

i.e. for this schema:

CALL graphql.idl('
  interface Animal {
    id: ID!
  }
  
  type Dog implements Animal {
    id: ID!
  }

  type Cat implements Animal {
    id: ID!
  }

  type Person {
    id: ID!
    pet: Animal @relation(name: "PERSON_PET", direction: "OUT")
  }
')

When a Dog is created (using the auto-generated mutations), it is created with :Dog:Animal labels. Then when performing the following query

  person {
    pet {
      id
    }
  }

I'm guessing that the following cypher is generated?

MATCH (node_one :Person)-[:PERSON_PET]->(node_two :Animal)

I think I understand why neo4j-graphql has been designed this way and it seems like a sensible default: this format is more bullet proof if someone isn't as familiar with Cypher / Neo4j as relation names don't need to be unique.

In my app though, with 50+ unique labels, I'm not sure there's a single instance where this behavior is desired:

The :PERSON_PET relation is unique on :Person, :Dog and :Cat nodes making the :Animal filter

1. unnecessary
2. slower to read (because it's performing an additional filter operation)
3. slower to write (because it needs to add the second label/index)
4. takes up more space.

This example is trivial, but in a deeply nested example, there's going to be a lot of unnecessary filters in there.

Anyway, it'd be real nice to be able to turn this behavior off (though again, I can see that it makes sense as a default).

I've definitely made some assumptions here, so I definitely understand if this actually isn't the issue it appears to be. It also seems likely that this is something you're already aware of, and perhaps already plan on addressing at some point in the future.

[jorroll]

Also, I really want to emphasize how AmAZiNg I think this plugin has the potential to be! The ability to automatically provision CRUD operations with CRUD operations for relations and provision associated schema input & query types is SO. FREAKING. NICE.

I actually read the original neo4j blog post announcing the plugin maybe a year ago? I just didn't see the value at that time and I'm a perfect target for it: I was already using Neo4j to power a GraphQL API. I remember thinking "well why would I want to ditch cypher to query my database in graphql? I mean, graphql is nice, but I love cypher. It just didn't occur to me that I could basically skip a backend server entirely and send queries straight from the SPA to the database.

I probably didn't make this connection because I didn't know about schema stitching, and "not being able to authenticate requests / filter queries" seemed like a deal breaker. But with schema stitching, you can authenticate requests, filter requests, do whatever you want with requests, while still being able to forward 90% of them straight to the database!

I actually found out about this plugin when I heard about Prisma, and got really excited about the potential there. But prisma doesn't have interface, union, or really any support for relations in general. Then I heard about hasura, but it also doesn't have good relation support (and I really don't like the idea of going back to SQL). Meanwhile neo4j-graphql + the cypher directive combined with schema stitching allows for some really powerful user authorization options.

Anyway, this is a long way of saying I'm amazed this project only has 250 stars (when Hasura has over 3000 and Prisma 10,000). Though considering I read about the project a year ago, was a perfect candidate for it, and still didn't understand how useful it was, I certainly can't knock anyone else for their lack of awareness.

Anyway, thanks so much for your work on this!

I really feel like Neo4j + this plugin + apollo server (with schema stiching) + apollo client + any javascript framework is the start of another front end revolution. I mean, you can practically just do everything on the front end and let neo4j handle the rest (and end up with a super friendly API)....

Of course, you can't quite do this at the moment, given some of the bugs / outstanding issues. But I can see a glorious future!