Feature Request | Interface implements Interface

Issues GraphQL
1

As the GraphQL Standard just added the capability of an Interface to implement other Interface I would hear your mind about the possibility of Dgraph to align to the standard.

By my side, I can bring some use-case and opinion about the topic, since I felt from the first moment I used Dgraph that the ability of interfaces to implement other interfaces would bring a big value to developers and schema designers.

Use case:

I want all the types of my only-append database to implement an interface which carries metainformation like custom id, creation date, visibility, deletion time, …
I then want to create an interface Product to expose common information, like name, description, price about the products sold in my E-Commerce.
I then want to implement some actual product like Skirt and Shoes.
Finally i want to have a Chart type holding all the products an user is about to purchase.

interface Metadata {
   id: String! @id @search
   crationDate: DateTime!
   deletionDate: DateTime!
   visible: Boolean! 
}

interface Product {
    price: Int!
    name: String!
    description: String!
}

type Shoes implements Metadata & Product {
   size: Int!
   ....
}

type Skirt implements Metadata & Product {
   height: Int!
   width: Int!
   ....
}

type Metadata & Chart {
    items: [Product!]!
}

Since Chart.items is an array of Product the mutation generated by dgraph won’t include the setter for the item field, since it can’t generate the getter of the interface Product (because it doesn’t have any searchable field) so i lose quite some functionalities.
Direct side effect of this is that it is quite difficult to add @hasInverse to those properties which implements an interface that is not searchable because it is not possible to create Chart → Product edge but mutating the Product itself eg:

interface Product {
    price: Int!
    name: String!
    description: String!
    inCharts: [Chart!]! 
}

type Metadata & Chart {
    items: [Product!]! @hasInverse(field: inCharts)
}

Dgraph does not generate the queryProduct as well, since it has not a searchable field, leaving the developer to either query the actual types separately, or to use queryMetadata and spread the Product fragment.

Allowing interface to inherit fields for other interfaces will lead to more customizable and manageable schemas, relieving quite some pain to developers.

Opinion

Most of database or framework can work without this feature, because in the above scenario someone could just create a resolver queryProduct and perform a custom query on the underlying database and manually manage all resolutions (which is something he has to do anyway).
Dgraph gives the power of an autogenerated GraphQL interface, but makes it quite difficult to implement basic custom queries or mutation like queryProduct by hand, leading to workarounds and limitations.

4 Likes
2

@graphql have you considered this? Seems like something that should be supported.

3

Also marking this as a feature request

2 Likes
4

Hi,

are there any updates on this?

I have another issue which I cannot solve currently, which would be possible when interfaces of interfaces would be implemented.

I have a list of foos and some of them should have inverse edges to another type. This is currently not possible (also not with union types).

Here is what I try to achieve (names are random and follow now inherent logic):

type Bar {
  foos: [Foo!]!
}

interface Foo {
   id: String! @id
}

interface Callable implements Foo {
   callback: Callback! @hasInverse(field: callable)
}

type Callback {
  callable: Callable!
}
5

I’m really pulling my hair out because this feature is still missing.

Can we please have an update on this? Thanks!

1 Like
6

Also waiting for this…

3 Likes
7

@mrjn @chewxy @aman-bansal @dmai is there any progress on this?