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?

The other alternative would be GraphQL via Lacinia

but I really prefer the approach taken by EQL+Pathom

@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

we are 100% clojure

then I find no reasons for not using EQL

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

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

@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

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

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?

both

the first for backward compatibility

but we want to do the latter

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

with a merged graph

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

similar to how Pathom integrates with GraphQL today

yes, I saw some tickets on Github

I would be happy to contribute

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

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

for the index explorer that can be easy

yeah that would be the first step

there is pc/merge-indexes you can use

to let stakeholders have greater visibility what is available

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

making a monolithic/microservices architecture possible

exciting stuff 🙂

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

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

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

HTTP+(not pathom)

I want to do HTTP + Pathom

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

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]}]}]

[{[:user/id 42] {:expensive/user-name "Expensive Name"}]}]

[{[:user/id 42] {:cache/user-name "Cheap Name"}]}]

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

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

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

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)

there is

to save COGS

COGS?

https://www.investopedia.com/terms/c/cogs.asp

to save 💸

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)

that would be sufficient I think

would this be a static thing?

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

given these resolvers different contexts might want the middle first

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

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

@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}}