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 address → country), give me all films (which has a name → localized) 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