Model for composites?

Devtools ComposeDB
1

Hi,

So, an indexer receives a composite, derives the models and when requested starts indexing. Info on the models is stored in postgres. Its the user(dapp)'s responsibility to store the composite that is required to interact with the data. The composite is most often hardcoded as there is most often a fixed relationship between dapp and indexer.

There may however be use cases in which this relationship is more dynamic, for example in a distributed database as a service, where a dapp/user can re-create, and augment composites from models on offer ( by a cluster of indexers).

Where then do we store a users composites? There is an obvious candidate called ComposeDB. You may have heard about it :wink:

So, should we have a standard model to store composite information? Might this be something you are already working on? If so, would there be something i could use already?

Thanks, Joera

3 Likes
2

Hi,

As you wrote, composites are mainly designed to represent the data model of a given app for an associated indexer. Composites also need to be network-independent so that for example a composite created and tested on Clay can easily be deployed to mainnet.

So a composite could be stored in a dedicated document using ComposeDB, but that would make it network-specific. We’ll likely work on better discovery primitives and services over the coming months to make it easier to share and discover composites, and using ComposeDB to do so could be a solution, but it will mostly depend on how well it can integrate with the necessary usage flows.

In the meantime, if you have specific needs for representing composites, I’d suggest working on a solution that fits your needs on top of the existing APIs.