Fork me on GitHub
#pathom
<
2019-10-17
>
kszabo09:10:26

Hey @wilkerlucio. I’m proposing to my company that we should use EQL/Pathom for aggregating our microservice graphs/general RPC mechanism. Do you have any comments on this approach/any pitfalls?

kszabo09:10:27

The other alternative would be GraphQL via Lacinia

kszabo09:10:38

but I really prefer the approach taken by EQL+Pathom

Mark Addleman13:10:02

Would you summarize your thoughts on why you prefer EQL + Pathom?

kszabo14:10:50

It’s mainly it’s attribute focus compared to entity-orientation. Also that the query language is data is a big plus, since you can trivially concat/merge/dissoc queries when you are building them up. The lack of type system is also a plus as I don’t believe that type systems capture enough meaning that they are useful outside of the most trivial cases (oh I expected an int for :user/age and got a float or whatever), the web isn’t built with typed attributes but with dynamic adapting systems.

myguidingstar14:10:52

@thenonameguy if Clojure is not your company's main language, then it's hard to adopt EQL as the interface language. But even in that case, you can disguise as GraphQL :)) https://github.com/denisidoro/graffiti

kszabo14:10:06

we are 100% clojure

myguidingstar14:10:08

then I find no reasons for not using EQL

kszabo14:10:54

nice library though, thanks for putting it on my radar! I had similar iffy feelings towards lacinia when reading it’s readme

kszabo14:10:50

the ecosystem support for GraphQL seems like a safer choice, but I woulnd’t mind developing tools as I got time from my employer working on things like this

wilkerlucio14:10:44

@thenonameguy considering you are all Clojure, I think Pathom is a good one, IME people tend to get quickly how to write resolvers. one common pitfall I see people doing sometimes is trying to make a resolver do too much, in those cases is good to instruct the use of smaller resolvers, adding more names to the system, as each name turns into an entry point for re-use, having more smaller resolvers is preferable

kszabo14:10:31

yup, I got this embraced by most devs, we are already reimplemented 2 microservice’s all REST endpoints of ours with Pathom parsers + exposing Pathom

wilkerlucio14:10:54

cool, just to clarify, are you using pathom on each service, and making endpoints by calling the parser, or just regular rest services and a separated service with pathom connecting them?

kszabo14:10:46

the first for backward compatibility

kszabo14:10:51

but we want to do the latter

kszabo14:10:06

have a set of microservices which are connected by Pathom in the customer-facing service

kszabo14:10:12

with a merged graph

wilkerlucio14:10:35

yeah, I ask because I have though a couple times about how would work to do Pathom <-> Pathom integrations, I mean, is theoretically possible to make one pathom parser pulls the index of another pathom parser, and "auto-connect" them, I just didn't had the opportunity to try that out, but if that's something you are looking for we could progress on that idea

wilkerlucio14:10:52

similar to how Pathom integrates with GraphQL today

kszabo14:10:54

yes, I saw some tickets on Github

kszabo14:10:19

I would be happy to contribute

kszabo14:10:48

also I’m working on a tool where you can use the Index/Graph explorer without multiple remotes

kszabo14:10:06

and if it’s possible merge the supporting datastructures to create a hollistic view

wilkerlucio14:10:18

for the index explorer that can be easy

kszabo14:10:26

yeah that would be the first step

wilkerlucio14:10:37

there is pc/merge-indexes you can use

kszabo14:10:41

to let stakeholders have greater visibility what is available

kszabo14:10:37

my final goal would be that our services communicate with strong keyword names, and the remote/local part of the computations is configuration dependent

kszabo14:10:52

making a monolithic/microservices architecture possible

wilkerlucio14:10:46

exciting stuff 🙂

kszabo14:10:32

it is, but if IIRC you posted a plugin where the parser chose a different server based on something. So I assumed you are doing something similar

kszabo14:10:14

but I guess you are just doing microservices/DB -> REST/DB -> frontendserver -> Pathom -> UI

wilkerlucio14:10:23

in my case I'm doing just HTTP calls to other services

kszabo14:10:18

HTTP+(not pathom)

kszabo14:10:26

I want to do HTTP + Pathom

kszabo14:10:59

with the possibility of removing the HTTP part if the remote query can be fulfilled locally

kszabo14:10:27

Also one pattern that will be important in our queries is a sense of ordering. Ie. I want my: Query:

[{[:user/id 42] [{:non-existing-pathom-feature/ordered-shortcircuit [:cache/user-name :expensive/user-name]}]}]
Response A:
[{[:user/id 42] {:expensive/user-name "Expensive Name"}]}]
Response B:
[{[:user/id 42] {:cache/user-name "Cheap Name"}]}]

kszabo14:10:00

Is this something that could be included as a Pathom utility instead of rolling our own impl? (Once we do this)

kszabo14:10:31

of course we could implement all of the combinations with separate resolver, but that blows up the resolver count with query resolver details

kszabo14:10:23

we are doing the latter currently btw, so we have a :cache->expensive/user-name resolver

wilkerlucio14:10:22

humm, for caching I think would make sense to just overload the name, because this is a implementation detail, the user should not care if that comes from cache or not (unless there is a business value on switching between them)

kszabo14:10:55

to save COGS

kszabo14:10:57

to save 💸

wilkerlucio14:10:02

about ordering, this is a current problem, because you can't guarantee that the cache one will run before, but the good news is that I'm currently working to make something like that possible, I want to be able to say: always run resolver X before resolver Y (in terms of priority, given they respond for the same attr)

kszabo14:10:22

that would be sufficient I think

kszabo14:10:18

would this be a static thing?

kszabo14:10:59

[:fast-but-inaccurate :moderate-but-more-accurate :slow-but-precise]

kszabo14:10:12

given these resolvers different contexts might want the middle first

kszabo14:10:21

it’s fine if you can define a default order at parser creation time, but there should be an escape hatch for cases like this

kszabo14:10:55

otherwise plain declarative queries won’t suffice for more advanced use-cases

wilkerlucio16:10:41

@thenonameguy yes, I wanna make it a static thing, but I was thinking something that's not so global, there is no "one priority list", but instead would be relative definitions, not sure about the final interface yet, but something like {'some/resolver {::pc/run-before 'some/other-resolver}}