GraphQL aliases not possible due to dgraph internal graphql+-

I’ve designed the schema in such a way to exploit the relation to traverse almost every kind of enttity:

type Text implements Metadata {
  text: String! @search(by: [trigram, term, fulltext])
  localization: [Localization!]!
}

type Country implements Metadata {
  ISO_3166_1_ALPHA_2: String! @search(by: [term])
  ISO_3166_1_ALPHA_3: String! @search(by: [term])
}

type Language implements Metadata {
  ISO_639_1: String! @search(by: [hash])
  ISO_639_3: String! @search(by: [hash])
}

type Localization implements Metadata {
  """
  en-US, ...
  """
  tag: String! @search(by: [hash])
  country: Country!
  language: Language!
}

type Address implements Metadata {
  formattedAddress: String! @search(by: [hash])
  addressLine1: String! @search(by: [hash])
  addressLine2: String! @search(by: [hash])
  administrativeAreaLevel1: String! @search(by: [hash])
  administrativeAreaLevel2: String! @search(by: [hash])
  country: Country!
  locality: String! @search(by: [hash])
  postalCode: String! @search(by: [hash])
  route: String! @search(by: [hash])
  streetNumber: String! @search(by: [hash])
  lat: Float! @search
  lng: Float! @search
  googleMapsPlaceId: String! @search
}

Those are some examples of the “core” entities od my schema.
I’ll not post the entire schema because it is 700 lines long, but long short from what I could understand dgraph performs the best when the data is inserted in a node-driven way instead of attribute-driven.
Having the localization as a node instead of a facet or an attribute, for example, allows to traverse the graph (using graphql±) in order to answer query like:

Given a person (which has an addresscountry), give me all films (which has a namelocalized) which do not have the name translated in the language spoken in the the person’s address country AND which has not yet distributed (distribution node → has localization link) in such country

The question seems artificial, but I’m building an open data enciclopedia which should allow the user to bend the data as he pleases.

I know the thread is going off topic, and I wouldn’t mind open another. but since dgraph works better with nodes rather than attributes, I need to find a clean way to filter node based on nested node’s attributes.

Alternatively, if the core team, or whoever knows better than me how dgraph should be used, could give a “best practice guideline” about how to design a schema which is both suitable for graphql but do not lose query answering power I would be more than happy to confront with it