Joining on scalars rather than objects about join-monster HOT 3 CLOSED

GraphQL args are now the third parameter for sqlJoin. Publish in v0.9.4.

from join-monster.

Hello @kamek-pf. I like learning about these use cases. It certainly helps me improve the project.

This stumped me for a while. I would've taken the same approach for your first point. We've found that relying on views rather than the actual tables is the best way to accommodate SQL schemas.

To your second point, what if you made a slight change to the schema...

{
    someTable {
       someValue # -> GraphQLInt
       someString # -> GraphQLString
       someStringIntl(language: "en") {
           someString # -> GraphQLString
       }
}

By making the language a parameter rather than a field, it might work. You could put the language into the where condition. Or better yet, I could add another parameter to the sqlJoin function which receives the GraphQL args. Then the JOIN condition could include the language.

{
    someTable {
       someValue # -> GraphQLInt
       someString # -> GraphQLString
       en: someStringIntl(language: "en") {
           someString # -> GraphQLString
       }
       fr: someStringIntl(language: "fr") {
           someString # -> GraphQLString
       }
}

You could call the someStringIntl field multiple times using GraphQL aliases.

Would this fulfill your use case?

P.S. It looks like GitHub has added flavored markdown support for GraphQL!

from join-monster.

Hi @acarl005,

I spent some time thinking about all this and I came up with similar ideas.

I don't think being implicit about the language (like I wanted to with someString) is such a good idea anymore. If the client application needs to let the user choose a different language, then a GraphQL client lib like Relay would have no way to tell what fields need to change.

I'll probably go for a new TranslatedString object type :

TranslatedString(lang: String):
    language: String,
    text: String

Every string that has to be translated could be an array of TranslatedString. It could be filtered with the lang parameter, or return the whole list if the parameter isn't specified.

{
    someTable {
        someString(lang: "en") { text } # as a regular client
        someString { language, text } # as a CMS user
    }
}

This would cover all my use cases.
someString(lang: "en") { text } would always return an array with exactly one element, a bit awkward, but still a decent trade off.

This can already be implemented in the current state of Join Monster (by filtering from within the resolver), but as you said, having the args accessible from sqlJoin would be even better. I imagine this could be useful in many different situations.

Thanks again for taking the time to look at this @acarl005 :D

from join-monster.