Fork me on GitHub
#pathom
<
2019-02-15
>
kszabo15:02:37

has anyone tried to push resolver-level timing information (probably from taking data from the tracing plugin) to prometheus? How would that look like?

wilkerlucio15:02:57

@thenonameguy we do exactly that at nubank, to prometheus, I have a plugin for it, let me get it for you 馃檪

馃憣 10
wilkerlucio15:02:57

@thenonameguy I removed some specifics, but most of it is there 鈽濓笍

kszabo15:02:37

awesome! thanks

kszabo15:02:51

I love code that I don鈥檛 have to write 馃檪

kszabo15:02:02

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

kszabo15:02:31

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鈥檛 want to reimplement the query/tracing functionality myself / hook it up with Fulcro, unless it鈥檚 necessary

wilkerlucio15:02:55

glad to help, about the run query, are you using workspaces?

wilkerlucio15:02:27

because if you are, you can easely hook a card to a parser: https://github.com/wilkerlucio/pathom-viz#workspaces-pathom-card

kszabo15:02:01

I thought workspaces was mainly a development time tool

kszabo15:02:08

we are not using it currently

wilkerlucio15:02:13

it is, but we like to deploy it for operational things as well 馃檪

wilkerlucio15:02:26

this is kind of a replacement for the old OgE (the pathom viz stuff)

kszabo15:02:59

haha, okay, I will take a stab at integrating it then 馃檪

kszabo15:02:03

thanks again!

wilkerlucio16:02:32

@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

wilkerlucio16:02:54

this setup is a bit more complicated, but I think its totally worth to make it, you do once and use it a lot

kszabo16:02:00

ohh, that sounds nice

kszabo16:02:29

are you using clojure.spec鈥檚 as well to facilitate generating data?

kszabo16:02:59

we started integrating https://github.com/gnl/ghostwheel here and there

wilkerlucio16:02:09

yes, also pathom has support functions to generate data from components or queries

kszabo16:02:17

and the combination of pathom + ghostwheel with autogenerated resolvers based on clojure.spec鈥檚

kszabo16:02:18

was on my mind

wilkerlucio16:02:49

you can make auto generated resoulvers if you have some consistent way to grab it, well, thats a big topic 馃檪

5
wilkerlucio16:02:22

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)

wilkerlucio16:02:35

this is what a card looks like in our fulcro setup (for inspiration)

5
kszabo16:02:32

damn, if only we had the story points for doing this 馃槃

kszabo16:02:49

thanks for showing this! If you could put this somewhere a bit more public (pathom wiki?) it would inspire many more people

馃憤 5
hmaurer21:02:25

@wilkerlucio out of curiosity how is your new Pathom explorer going?

wilkerlucio21:02:28

I had a pretty busy week so it didn't moved much, but its on my top personal priority 馃檪

馃憣 5
hmaurer21:02:26

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 鈥渃omputational 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:

馃憤 10