Boto - A library to unify data sources through attribute modeling in a seamless graph

Boto is a library heavily inspired on Clojure/Clojurescript library called Pathom.

The idea here is to stop thinking of data inside entities and actually as a graph of relations between attributes. I’m using the word attribute here to differentiate it from just a key-value pair. An attribute has a unique meaning through your application, even if provided by different sources. Imagine an id of an external service that can be queried in a local storage(being it a cache or sql database).

For boto it doesn’t matter where you’re getting this data from, it can be an ecto query, an http request, grpc request. Anything that you can express with an elixir syncrhonous function that receives a set of attributes as parameter and returns a set of mapped attributes.

I understand that it’s not an easy thing to understand, so there is a livemd file showing some examples of how to use the library:

It’s worth mentioning that this is not a complete project and please don’t use it in production yet. I’m iterating over it to achieve a result that is more idiomatic to the erlang ecossystem. There are a lot of open issues on codeberg, and I’m more than happy to discuss good approaches with the community.

Actually, i’ve been iterating ideas around it for quite some time, for exemple:
https://elixirforum.com/t/ectoapi-a-library-to-use-ecto-to-describe-external-api-resources/
https://elixirforum.com/t/should-we-have-namespaced-atoms-in-elixir/

9 Likes

It’s fascinating! How a query from some input information got resolved (via the graph-like connection?) to get relevant output information remind me of prolog / Rule based, which the engine automatically infer output fact from basic set of input fact.

1 Like

it’s a graph for sure, I’m using erlang digraph implementation. the attributes are vertices, and the edges are the resolvers, directed from the input to the outputs.

and you can produce facts about the attributes. for the weather example in the livemd file, you can have a :locantion@is_cold? attribute that requires :location@temp, in the same way you can have a :location@is_hot?. since resolvers are just functions, and attributes are values with a meaning, you can model different ideas around it.

I’m currently thinking on how to handle failures while I finish improving the documentation and write tests.

1 Like