Fork me on GitHub
#pathom
<
2019-10-28
>
henrik08:10:24

@wilkerlucio What do you think of this (hypothetically)? Query:

[{(:zd/articles_selection_2
   {:filter_expr 'filter-expr})
  [{(:zd.ArticlesSelection/articles_sel_top_subject_categories_distribution
     {:n_results 'n-results})
    […]}
   {(:zd.ArticlesSelection/articles_sel_top_journals_distributions
     {:n_results 'n-results})
    […]}]}]
Then in load!,
(defn load-filters [filter-bar-id filter-expr n-results]
  (load! app :zd/articles_selection_2 Filters
    {:params {'filter-expr filter-expr
              'n-results n-results}}))
The idea would be to have Pathom slot in the values from params in any sub- queries. It would 1) make the composition of queries that require multiple levels of arguments more straightforward, 2) be quite easy to throw meaningful exceptions or warnings when values for parameters are missing (on load!), 3) minimize the amount of data on the wire when Pathom is running on the backend, and arguments are repeated in the query, and 4) be more or less trivial to pass on to GraphQL (if it is the ultimate destination) as a query and variables combo.

wilkerlucio17:10:34

considering that this is more a problem of building the query than runnign it, to me this feels more like a client issue (on building the query), given queries compose and can go very large I would avoid trying to do a replace like this, but you can totally do it locally and use as a :update-query, so you can implement this "templaing", but to be honest, one you do that, you can realize havign a function with params do pretty much the same, makes sense?

henrik08:11:50

Well, that’s mostly an incidental side-effect. What it really would do is deduplicate repeating args. Consider, for example, the argument,

{:should
 [{:must
   [{:terminal_exprs {:matches_text "water"}}
    {:terminal_exprs {:author_name_matches "Andersson"}}],
   :filter
   [{:terminal_exprs
     {:article_subject_categories_match "Chemistry"}}
    {:terminal_exprs {:is_oa_equals true}}]}
  {:must [{:terminal_exprs {:matches_text "soil"}}],
   :filter
   [{:terminal_exprs
     {:article_subject_categories_match
      "Agricultural and Biological Sciences"}}
    {:terminal_exprs
     {:article_subject_categories_match
      "Agronomy and Crop Science"}}
    {:terminal_exprs
     {:publisher_name_matches "Springer Nature"}}]}]}
This is a very average argument in our case, neither small nor large. This can be repeated up to three times in a single query (often dwarfing the actual query itself). Transit will shrink this a tiny bit, but not meaningfully so. This’ll be repeated three times frontend to backend (where Transit will help a little), and then three times again backend to API (which is GraphQL, and Transit won’t be there to help at all). The primary attraction of the above is that it could cut a lot of unnecessary network overhead.

Brian17:10:55

I'm getting an "invalid expression" error when running the following mutation and I can't figure out why:

(pc/defmutation add-hash [env artifact]
  {::pc/sym `ab.threat-intelligence.artifact/add-hash
   ::pc/params [:artifact/note]
   ::pc/output [:artifact/note2]}
  {:artifact/note2 (get artifact :artifact/note)})
(<!! (parser {} [{(ab.threat-intelligence.artifact/add-hash {:artifact/note "hello"}) [:artifact/note2]}]))

wilkerlucio17:10:17

you have to quote the symbol name when you call the expression:

(<!! (parser {} [{(list 'ab.threat-intelligence.artifact/add-hash {:artifact/note "hello"}) [:artifact/note2]}]))

Brian17:10:47

Lets GOOOOO thank you!