@U01GXF0SQ48 So this is a pretty common problem to solve, and in the very beginning of using Datomic I struggled with similar things. The biggest mistake was thinking of it as a traditional database, where you had to shove the entire query into one request, and compose a huge complicated hairy mess, just because the database was "over there". One big difference with Datomic is that in both Peer and Ions, your code literally runs in memory with the data, and you really shouldn't limit yourself to writing giant hairballs like your current solution. It's not very maintainable and kind of orthogonal to the ideas behind Datomic of composability, and generally I find if my query is longer than 10 lines there's something going horribly wrong. Here's a couple of solutions: 1.) If you had the ability to introduce a direct counts attribute you could simplify your life a lot and cache these lookups - these could be guaranteed with transaction functions. Would be pretty simple to implement. Then your query would literally be 3 lines, a simple pull expression.

2.) Break the query down! Your solution may be technically correct, but there's no reason not to break the query down. The work done by the instance is almost the same, and if you break down the same logic into multiple queries, you get the additional benefit of more granular query caching. And reusability. And composability with more parts of your application. And readability. Consider a generic helper function that counts interactions:

(defn post-interaction-count 
  [interaction db post-id]
  (ffirst (d/q '[:find (sum ?likes)
                 :in $ ?post-id ?interaction
                 :where [?eid :post/id ?post-id]
                 [?likes :interaction/interactable-id ?eid]
                 [?likes :interaction/type ?interaction]])
          db post-id interaction))

This is pretty generic for posts, and you could then have:

(def post-likes (partial post-interaction-count :interaction.type/like))
(def post-dislikes (partial post-interaction-count :interaction.type/dislike))

And then your complete function is super simple, and very readable:

(defn post-by-id 
  [db post-id]
  (-> (d/q '[:find (pull ?eid [:post/id :post/title :post/content-url {:post/content-type [:db/ident]}])
             :in $ ?post-id
             :where [?eid :post/id ?post-id]]
           db post-id)
      first
      (merge {:post/likes (post-likes db post-id)
              :post/dislikes (post-dislikes db post-id)})))

If :post/id is registered as an identity attribute you could simplify the pull expression even further with the pull API, shaving off another 2-3 lines. Obviously I didn't have access to your setup/database etc., so the code above may not run as-is, and notably I changed the semantics a bit, like passing around a db instead of a conn. (reason: a lot of times in the context of one web request, you actually want to keep the database value the same, and only request it once on the connection per request. Every post lookup on potentially different databases kinda defeats the purpose of Datomic's ability to give you the db as-of, which solves lots of application bugs and other unwanted issues/race conditions). Hope this helps!

@UNRDXKBNY wow that was a blog post level reply. Thanks so much for the pointers.