This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-02-15
Channels
- # adventofcode (13)
- # aleph (5)
- # announcements (8)
- # beginners (87)
- # calva (9)
- # cider (102)
- # cljs-dev (71)
- # cljsrn (2)
- # clojure (198)
- # clojure-dev (28)
- # clojure-europe (3)
- # clojure-italy (27)
- # clojure-nl (3)
- # clojure-spec (1)
- # clojure-uk (43)
- # clojurescript (121)
- # component (11)
- # cursive (20)
- # data-science (13)
- # datascript (2)
- # datomic (102)
- # dirac (4)
- # duct (5)
- # emacs (14)
- # figwheel-main (7)
- # fulcro (37)
- # hoplon (11)
- # jackdaw (3)
- # jobs (2)
- # leiningen (16)
- # nrepl (2)
- # off-topic (51)
- # pathom (34)
- # pedestal (12)
- # perun (10)
- # portkey (1)
- # re-frame (6)
- # reitit (1)
- # shadow-cljs (21)
- # spacemacs (8)
- # tools-deps (2)
- # vim (2)
has anyone tried to push resolver-level timing information (probably from taking data from the tracing plugin) to prometheus? How would that look like?
@thenonameguy we do exactly that at nubank, to prometheus, I have a plugin for it, let me get it for you 🙂
@thenonameguy I removed some specifics, but most of it is there ☝️
one more question then: how do you debug a Fulcro application that is using Pathom Connect in stg/prod? It would be nice if you could just attach the Fulcro Inspector query tab / bundle it with the app
we are using it over websockets so that could also be a problem. There have been times when I wanted to run arbitrary queries inside the app, but I don’t want to reimplement the query/tracing functionality myself / hook it up with Fulcro, unless it’s necessary
glad to help, about the run query, are you using workspaces?
because if you are, you can easely hook a card to a parser: https://github.com/wilkerlucio/pathom-viz#workspaces-pathom-card
it is, but we like to deploy it for operational things as well 🙂
this is kind of a replacement for the old OgE (the pathom viz stuff)
@thenonameguy another thing that might interest you is the one idea we apply using workspaces, in our setup here the user can switch (using the card toolbar) which remote he wants to hit, so the same card can be run against generative data, local running service or cloud running service, this gets a nice flexible way to try out each component
this setup is a bit more complicated, but I think its totally worth to make it, you do once and use it a lot
we started integrating https://github.com/gnl/ghostwheel here and there
yes, also pathom has support functions to generate data from components or queries
and the combination of pathom + ghostwheel with autogenerated resolvers based on clojure.spec’s
you can make auto generated resoulvers if you have some consistent way to grab it, well, thats a big topic 🙂
here is how you can generate from a query: https://cljdoc.org/d/com.wsscode/pathom/2.2.9/api/com.wsscode.pathom.gen#query-%3Eprops
this returns actual test.check generators, so you can compose with test.check stuff (supporting cool things like shrinking if you use on a test)
this is how you get a generator out: https://cljdoc.org/d/com.wsscode/pathom/2.2.9/api/com.wsscode.pathom.gen#query-props-generator
thanks for showing this! If you could put this somewhere a bit more public (pathom wiki?) it would inspire many more people
@wilkerlucio out of curiosity how is your new Pathom explorer going?
I had a pretty busy week so it didn't moved much, but its on my top personal priority 🙂
shower thought: could an approach like Pathom be useful not just to fullfill the data needs of a client, but also within an application? It seems like the model of “computational graph” where you can request pieces of information and derive them on the fly using a sequence of computations could be useful within a codebase :thinking_face: