Pathom is a Clojure/script library to model attribute relationships.
Pathom 3 uses a new and different algorithm to process information, different from Pathom 2, that has been tested in many production apps, the algorithm of Pathom 3 is still under experimentation stage, so consider that if you intend to use Pathom in production code.
When you read code from the examples in this documentation they will use alias to reference namespaces, here you can find what the aliases point to:
General attribute modeling view
Attribute modeling is a way to think and design information systems.
Consider the question: What's the temperature in the city of Recife now?
Using my attribute modeler hat, I can break this description into two attributes and one
value. The demand is for a
:temperature, and the available information is the
:city with the value of
Recife. Or we can express it as a Clojure map:
Note we left
? for the unknown attributes. In a way, this map expresses the same thing
as the question we had before.
Now, to realize the
:temperature from the
city, we write a resolver
establishing this relationship.
A resolver looks like a function but with some constraints:
- The resolver input must be a map, so the input information is labeled.
- A resolver must return a map, so the output information is labeled.
- A resolver may also receive another map, containing the environment information.
The next step is to create the indexes:
Pathom uses the indexes to traverse the attribute relationships.
Now to make the original question to Pathom, we are going to use the Smart Map interface:
Note that in this example, we only mention the indexes and the attributes, the resolver names get abstracted from the user and left for Pathom to figure when to call then.
Now consider a slightly different question: Is it cold in
To compute the
:cold? attribute, we can write a resolver that depends on the
Update the indexes definition to also include the
Now, back to the question: Is it cold in
Recife now? This time we will use a different
interface, the EQL interface.
Note that our "lookup code" remains the same size, although we have to run more operations now. This ability to abstract the function call chain is the primary utility you should look for in Pathom.
In this getting started, we talked a bit about attribute modeling, how to write a few resolvers and how to trigger the Pathom engine to fulfill attribute questions.
You can find a complete tutorial playing with weather API's at the Pathom Tutorial page.
Here is a list of the main concepts in Pathom that can help you navigate the documentation.
Resolvers are building blocks that establish relationships between attributes. Pathom secret sauce is the ability to traverse a graph of attribute relationships, defined by resolvers, given some user request.
Is a map containing all the necessary context required to process a request. Data for Pathom internals uses Pathom-specific namespaced keys, and you will typically add your own entries (database connections, etc.) such that all these data are available to your resolvers.
Given the environment, some initial data and a request, the planner is responsible for figuring what resolvers to call, in what order.
Once the plan is ready the runner executes the plan, by traversing and executing resolvers, then responses are coming as expected and chooses the path when multiple options shaping the results to satisfy the request. It handles errors as well as potential conflicts are available.(e.g. multiple resolvers can handle a given request).
To bundle the process together, you interact using one of the Pathom interfaces: