pathom 2022-11-21 | Slack Archive

Parmijeanne11:11:36

Hello, I'm trying to consume a graphql endpoint but I'm a bi lost when it come to writing to eql for it. Here's the request I'm trying to replicate:

{
   "operationName":"SearchQuery",
   "variables":{
      "input":{
         "q":"*Eucalyptus*",
         "rows":50,
         "fq":[
            
         ],
         "page":1,
         "facetLimit":20,
         "facetField":[
            "taxonomic_status",
            "occurrence_status",
            "establishment_means",
            "degree_of_establishment",
            "taxon_rank",
            "family"
         ]
      }
   },
   "query":"query SearchQuery($input: SearchInput!) {
  search(input: $input) {
    docs {
      id
      taxonRank
      acceptedNameUsage
      acceptedNameUsageId
      acceptedNameUsageAuthorship
      preferredVernacularName
      scientificName
      scientificNameAuthorship
      family
      taxonomicStatus
      nameAccordingTo
      __typename
    }
    meta {
      params {
        q
        fq
        fl
        rows
        __typename
      }
      pagination {
        lastPage
        total
        currentPage
        __typename
      }
      __typename
    }
    facetFields {
      fieldName
      fieldLabel
      facets {
        value
        count
        fq
        __typename
      }
      __typename
    }
    __typename
  }
}"
}

That's the eql I'm trying to send so far... I just don't understand how to pass the "nested" params to the query.

[{(:herb.Query/search  {:herb.SearchParameters/q "*Euca*"})
  [{:herb.SearchResult/docs [:herb.SearchResultDocument/id]}]}]

The public endpoint is ""

souenzzo11:11:26

something like this:

[{`(~'SearchQuery {:q          "*Eucalyptus*"
                   :facetField ["taxonomic_status"]})
  [{:docs [:id :taxonRank :__typename]}
   {:meta [{:params [:q]}
           {:pagination [:lastPage]}
           :__typename]}
   {:facetFields [:fieldName
                  {:facets [:value]}
                  :__typename]}
   :__typename]}]

Parmijeanne11:11:16

Thanks mate, I got it working, thanks to pathom viz autocomplete and lots of try and error...

[{(:herb.Query/search {:input {:q          "*Eucalyptus*"
                               :facetField ["taxonomic_status"]}})
  [{:herb.SearchResult/docs [:herb.SearchResultDocument/id]}]}]

Panel21:11:52

Can you use wildcard when consuming graphql ?

wilkerlucio21:11:03

yes you can, but its important to understand what wildcard means. in Pathom, the wildcard means "expose all the data that was gathered for this entity during processing", and not "get me everything possible"

wilkerlucio21:11:51

this means that if you have something that depends on a graphql thing, and add the wildcard, you will see that data there, but Pathom will not ask for anything that's not part of (or a dependency of) your original query

Panel21:11:18

Thanks for making it clear, I was definitely expecting the « get me everything » scenario.

Eric Dvorsak21:11:43

I'm getting bit hard by aliases now, pathom is finding all kind of paths that are semantically incorrect for users, as I have a lot of one to one and one to many relationships involving user/id. I guess the remedy is to not keep things too flat after all

wilkerlucio21:11:20

its tradeoff, but in general is better to avoid multiple paths if you have a preferred one

wilkerlucio21:11:35

reducing OR nodes (by reducing the number of paths for a given attribute) in the planner will make things run smoother

Eric Dvorsak21:11:10

These are accidental (and wrong). I'll try to make a minimal example tomorrow. For instance trying to get the users that are in a course by course/id, one of the path in the OR node will do it through purchases by course/id since it outputs purchase.user/id aliased to user/id

Eric Dvorsak21:11:44

So it's semantically wrong since it's only the users that purchased a course not all the users in the course

wilkerlucio21:11:02

yeah, its an important detail to be aware, if you have ambiguity in the path, better to avoid it, but I think its an important detail that we should talk more about it when flatening things

wilkerlucio21:11:10

its good, but only when there is no ambiguity

wilkerlucio21:11:19

if there is, it becomes a tricky land

wilkerlucio21:11:10

lets think about the courses thing

wilkerlucio21:11:41

my idea there would be to implement :course/users for the users of a course, that depends on :course/id, whats the way you have it?

2022-11-21

Channels