Join egghead, unlock knowledge.

Want more egghead?

This lesson is for members. Join us? Get access to all 3,000+ tutorials + a community with expert developers around the world.

Unlock This Lesson
Become a member
to unlock all features

Level Up!

Access all courses & lessons on egghead today and lock-in your price for life.


    Query GraphQL Interface Types in GraphQL Playground

    Eve PorcelloEve Porcello

    Interfaces are similar to Unions in that they provide a mechanism for dealing with different types of data. However, an interface is more suited for data types that include many of the same fields. In this lesson, we will query different types of pets.

    To follow along with these queries, go to the Pet Library GraphQL Playground.



    Become a Member to view code

    You must be a Member to view code

    Access all courses and lessons, track your progress, gain confidence and expertise.

    Become a Member
    and unlock code for this lesson




    Instructor: If we sum the AllPets query for ID and name, we are going to see ID and name returned to us, just as we expect, but in the funded pet library, these data relationships are designed pretty differently.

    Let's open up the AllPets query in our schema and we'll see that the pet is no longer a type, but instead it's an interface.

    An interface is an abstract type that includes a set of fields. These fields must be used when creating new instances of that interface. We have an interface called pet. This is the base class. It has certain fields on it.

    We have several different implementations of that interface. Remember, our numerator from before that had cat, dog, rabbit, and stingray, these are now implementations of this interface.

    If we scroll down to the cat, we'll see that cat is a separate type that implements the pet interface. It has all of the different fields that are part of that interface, but then we can extent the cat to have a couple of different ones, so sleep amount and curious are now available on that cat.

    Let's click on stingray. That's another type. We have a couple of extra fields defined on that as well. Same with the rabbit and the dog. AllPets returns a list of pets, but all of these pets are different types, different implementations of the pet interface.

    If I want to see which one is which, I can query the _ _ type name field, this will give me the data about what type of pet we're querying. The way that we write a query for an interface is also a little bit different.

    Remember those extra fields that we had on the cat. I can use an inline fragment, ...onCat, and then I can query that field. Whenever there is a cat in the response, we're going to see a sleep amount value for the cat. For all other types, we're not going to see that extra field.

    We can do this for any additional fields that we'd like to. I can say onStingray and get how chill the stingray is on a scale of 1 to 10. This will be provided in the response only for stingrays.

    An interface gives us a little bit more flexibility when we're designing our domain's objects. We have a pet, that is an interface. Some base fields on that pet interface, and then we can create implementations of that interface and then create custom fields for each additional pet type.