Add support for Interfaces & Unions

[acron0]

We would like to be able to use Interfaces and Unions in GraphQL. It's not immediately obvious how we might implement this, and we don't currently have a solid use case, but I understand it's a deal-breaker for some people who have considered Leona.

[workshub]

@charliejrgower started working on this issue via WorksHub.

[tolgraven]

Thinking in earnest -> Whereas something like subscriptions is basically all about execution side, and in practice these two are also mainly about putting some additional requirements on field resolvers and request structure, that''s a bit insignificant compared to what direction you are modelling from in the first place.
If inheritance is saying "this, being an x, behaves like this", spec approach is surely saying "here's how it behaves, whatever it is - just keep it in line".

But of course you know that. Issue has obviously been up for a long time, but was the bounty as well? :O subtle in plain sight!!

In all seriousness though, and minding my whimsey and incorrect intuitions (see issue i opened) - what is the edge to trying to cover non-pred stuff more easily done in eg Lacinia straight, instead of stretching spec, which brings power but also limitations? Especially if several approaches can coexist :)

[tolgraven]

Definitely too neurotic about types being "defined" by their specs, in the end we're just talking keywords. With the unions themselves autocreated as needed for a query of that kind instead of explicitly, seems neat enough.

No children would be harmed because of an abstract mental dependency from resolver on own spec... haha. But the sorta passthrough any? specs likely for these queries, idunno.

[workshub]

@ztrz started working on this issue via WorksHub.

[workshub]

@Rastin2020 started working on this issue via WorksHub.

[workshub]

A user started working on this issue via WorksHub.