Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2022-03-10

Channels

#pathom
<
2022-03-10
>
Drew Verlee02:03:26

In order to resolve an attribute, will pathom walk up the tree and across to a sibling tree then down it? e.g I declare an input to my resolver [:a {:c [:d]} {:b [:e]}] and :d requires :e to be resolved. Will pathom do that? does the question make sense?

wilkerlucio02:03:40

:d and :e are at different levels, and you can never look up (only down), does that help?

wilkerlucio03:03:44

if you get a more concrete example we can talk over it

Drew Verlee03:03:24

I suppose I had been thinking of Pathom as a "graph language" but i'm realizing that might be not a good mental model. in datalog you could do a join across. In pathom assume i need to pull the information i need (at level :e) using a query inside my resolver and then inject it at the other level (:d) to get the desired effect. Yep thats exactly what were doing in other places in our codebase. Ok i understand.

wilkerlucio13:03:05

it is a graph in the sense you navigate the entities, but not in the sense of datalog that you do this kind of disparate joins, Pathom doesn't optimize for query in that sense, instead of about entities and how they relate to each other, the resolvers allow the navigation, but something like a search is more suited to just be given a name, and use some underlying language (like datalog, sql, etc...) to do the find and return the entities to be further navigated by Pathom, makes sense?

👍 1
Stefan14:03:33

Hi all! We’re doing our first Pathom (3) steps in our code. We’re now considering how to do pagination. We can see two alternatives. One is this: 

(pco/defresolver user-resolver
  [env _]
  {::pco/output [{:user/all [:user/id :user/name]}
                 :users/all-count]}
  (let [limit (get (pco/params env) :pagination/limit)
        offset (get (pco/params env) :pagination/offset)
        users (query-users)]
    {:users/all (take limit (drop offset users))
     :users/all-count (count users)}))
The other is this: 
(pco/defresolver user-resolver
  [env _]
  {::pco/output [{:user/all
                  [:pagination/total
                   {:pagination/items [:user/id :user/name]}]}
                 :users/all-count]}
  (let [limit (get (pco/params env) :pagination/limit)
        offset (get (pco/params env) :pagination/offset)
        users (query-users)]
    {:users/all {:pagination/total (count users)
                 :pagination/items (take limit (drop offset users))}}))
We’re not sure which to choose, we lack the experience to understand the trade-offs. Can somebody shine their light on this for us? Thanks!

jmayaalv14:03:50

for pagination we have opted for a cursor based approach instead of an offset based approach. Mostly because we want to avoid the count. This of course depends in your backend and how you load the data.

jmayaalv14:03:44

but in general the implementation is pretty similar to the second one.

kendall.buchanan16:03:12

You’re welcome to look at how we’ve implemented it…

kendall.buchanan16:03:20

(pco/defresolver notifications-app
  [{sql :db/sql}
   {user-id     :user/id
    page-size   :page/size
    page-number :page/number}]
  {::pco/input  [:user/id
                 (pco/? :page/size)
                 (pco/? :page/number)]
   ::pco/output [{: [:page [:page/previous
                                             :page/current
                                             :page/next]
                                      : notification-app-attributes
                                      : notification-app-attributes]}]}
  (let [page-size (or page-size 20)
        page-number (or page-number 1)
        limit page-size
        offset (- (* limit page-number) limit)
        notifications (->> (store/get-notification-app-notifications-by-recipient-user sql user-id (inc limit) offset)
                           (map transform-notification))
        page-previous (if (= page-number 1) nil (- page-number 1))
        next-notification? (= (inc limit) (count notifications))
        page-next (when next-notification? (+ page-number 1))
        notifications (take limit notifications)            ;; adjust for over-fetching
        new-notifications (filter #(= :unread (:notification.app.status/status %)) notifications)
        prv-notifications (filter #(= :read (:notification.app.status/status %)) notifications)]
    {: {:page                       {:page/previous page-previous
                                                      :page/current  page-number
                                                      :page/next     page-next}
                         :      new-notifications
                         : prv-notifications}}))

🙏 1
wilkerlucio18:03:47

@U0HJA5ZQT looking at your source it seems the :page attribute is missing a map around it to place the :page/previous and others as children of them

wilkerlucio18:03:54

:page [:page/previous :page/current :page/next] vs {:page [:page/previous :page/current :page/next]}