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.

This is my first time writing some code in Erlang(besides very small contributions to other libraries), if you think my coding skills are bad, please open an issue, I’ll try to improve the code :slight_smile: . I usually code in Elixir, but since this library doesn’t require anything special from Elixir, I tried to do it with pure Erlang.

8 Likes

The name is a bit unfortunate due to the existence of a rather popular Python library with the same name.

3 Likes

I’m not that worried with the naming of the library. the python library has a scope that doesn’t correlate in anything with what the erlang library does.

2 Likes

This sounds interesting, but do you have a motivating example? Should add one to the readme! :slight_smile:

1 Like

it’s difficult to express a “motivating example”.
my main use case is simplify data gathering in external services, mainly in a microservices architecture scenario. But the library is not limited to that, you can relate data that comes from different sources not only APIs.
In practical terms, I see it as a way of decoupling “business logic” from data sources. Let’s say you’re refactoring the data modeling in a monolithic application, it doesn’t matter how the data is stored or retrieved, just that you can reach it based on a set of given attributes

2 Likes