@dansudol hello, so, your guess it has all the things is true, that's the connect index, attribute resolution is done in this layer, there is also the map reader layer, so in case you already had that loaded you may get it, but that can be an accident, its important to have the possibilities in the index (which comes from the inputs/outputs), this allows for introspection and smarter processing, you can read more about connect indexes at: https://wilkerlucio.github.io/pathom/#_understanding_the_indexes

I'm trying to understand GraphQL and Pathom. What I don't understand is how does it compares with Lacinia, except that we can use it in ClojureScript too. Pathom seems superset of functionality that Lacinia provides.

@ahmed1hsn the biggest difference is that graphql/lacinia are entity-level, whereas Pathom is attribute-level

thanks @wilkerlucio I think i get it .. the thing attributes have to be laid out by at least one ( in this case "get me the thing" resolver ) and now pathom/connnect knows the attributes of thing and can use that anywhere else you ask for things

@ahmed1hsn hello, both GraphQL and Pathom try to fix the same problem of structured requests, TBH is more fair to compare GraphQL and EQL, in the same way you have multiple GraphQL processors (Apollo, Lacinia, Relay...) you may have multiple EQL processor (although currently Pathom is the only impl of eql that I know of). You can find more details on how they compare in EQL docs: https://github.com/edn-query-language/eql#graphql-comparison

please let me know if you need more clarification

also is worth knowing that Pathom has some support for GraphQL integration (which can be confusing for new people trying to understand the relationship)