[IMPOSSIBLE] GraphQL interface for localized types

[arm1n]

Hi Sebastian,

I am adding a feature request in addition to this thread here: [IMPLEMENTED] GraphQL default language

I am fine with querying multiple languages in GraphQL as I need them all to build the corresponding translated pages from my static site generator. But what would be super convenient from a maintenance perspective is the ability to create GraqhQL fragments for the implemented languages.

Example: I am using de and en and would like to query like:

query {
  data {
    prop {
       ...Languages
    }
  }
}

fragment Languages on SquidexLanguages {
  de
  en
}

This would require that the server schema implements SquidexLanguages as interface. Thus, we could use such fragments client side and could reuse the fragment in all queries, which would be awesome! Outlined idea also here: https://stackoverflow.com/a/75681681

Thanks for taking the time to provide your thoughts!

[Sebastian]

But I guess we would need one interface per field type, right?

[arm1n]

If I got it correctly it would suffice to have one interface per app only, as the languages are defined globally as well, but all field types would need to implement it.

[Sebastian]

But interfaces properties need a type:

interface NameAndAddress {
  name: String
  address: Address
}

[Sebastian]

I think this is not possible.

[arm1n]

Hey Sebastian,

it would be like in the stackoverflow example:

interface Languages {
  de: String
  en: String
}

type SomeDto implements Languages {
  de: String
  en: String
}

Then we would be able to base fragments on that interface Languages which is app-wide, otherwise this would have to be done for all Dtos. Or am I missing something?

[Sebastian]

You would need one interface for each type, so it would look more like this:

query {
  data {
    string1 {
       ...StringLanguages 
    },
    string2 {
       ...StringLanguages 
    },
    number1 {
       ...NumberLanguages 
    },
    number2 {
       ...NumberLanguages 
    }
  }
}

fragment NumberLanguages on SquidexNumberLanguages {
  de
  en
}

fragment StringLanguages on SquidexStringLanguages {
  de
  en
}

and with nullable it would be even more complex:

query {
  data {
    string1 {
       ...NullableStringLanguages 
    },
    string2 {
       ...StringLanguages 
    },
    number1 {
       ...NullableNumberLanguages 
    },
    number2 {
       ...NumberLanguages 
    }
  }
}

fragment NumberLanguages on SquidexNumberLanguages {
  de
  en
}

fragment NullableNumberLanguages on SquidexNullableNumberLanguages {
  de
  en
}

fragment StringLanguages on SquidexStringLanguages {
  de
  en
}

fragment NullableStringLanguages on SquidexNullableStringLanguages {
  de
  en
}

And then you have no more advantages.

I would just use flatData and resolve the language on the Squidex server.

[arm1n]

I see, that’s indeed correct and makes sense. Then I’ll try to solve by constructing sites using multiple requests and using flatData - thanks for your feedback!