Can interfaces implement other interfaces in GraphQL?

Issues GraphQL
,
1

Eg

interface A {
    name: String
}

interface B implements A {
    id: String! @id
}
1 Like
2

Not yet.

2 Likes
3

Thanks! :slight_smile:

4

According to this RFC this functionality is available on the GQL spec.

Can we reopen this to track support by dgraph?

To give some more context why this should be important:

interface Timestamped {
  createdAt: DateTime! @search
}

type Foo implements Timestamped {
   bar: String!
}

using this schema I can filter all Foos by there createdAt Timestamp without issues. When I now want to add a 2nd abstraction layer with the current limitations:

interface Timestamped {
  createdAt: DateTime! @search
}

interface FooInterface {
   bar: String!
}

type Foo implements Timestamped & FooInterface {
   hi: String!
}

I cannot filter anymore by the createdAt timestamp (which is of course expected).

Of course I could work around this by using:

interface Timestamped {
  createdAt: DateTime! @search
}

interface FooInterface {
   createdAt: DateTime! @search
   bar: String!
}

type Foo implements FooInterface {
   hi: String!
}

But then I loose the ability to query all Foos with queryTimestamped.

1 Like
5

@graphql can this be re-opened please?

1 Like
6

Also bumping for reopen - this is very late coming to the GraphQL spec and has been a sticking point for a long time. Would like to see support ASAP…it just feels totally absurd to flatten well-designed data models to support the database schema.

1 Like
7

Also posting here for awareness.

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

Can we please have an update on this? Thanks!

8

Seems like it is still not supported, but doesn’t seem like a big problem to support. Nothing actually changes from the finally generated GraphQL schema for clients and queries are the same. The only advantage we’ll have is more flexibility in organizing and querying data.

Can you please share the ticket this is tracked in. Thank you.