ADR-30: Front and back end architecture for the Marketplace

More details about this document
Latest published version:
https://adr.decentraland.org/adr/ADR-30
Authors:
cazala
nachomazzara
nicosantangelo
Feedback:
GitHub decentraland/adr (pull requests, new issue, open issues)
Edit this documentation:
GitHub View commits View commits on githistory.xyz

Context and Problem Statement

The newest version of the Marketplace supports various sources for it's data.

We need to agreggate the blockchain, multiple graphs and data from our partners, which themselves are represented as API requests to different servers.

We don't only need to show the data to the user, but we should also provide different ways to interact with it, mainly buying and selling assets. We should also allow the user to filter the data in different ways.

To do this, assets from different sources have their own version of what it means to filter them, and we might also need to interact with different contracts, depending on the operation.

Considered Options

  1. Use the front-end as both an aggregator and data handler for the UI

All APIs we need to hit are public. The front-end could decide which one to hit, aggregate the data and show it to the user

  1. Write and use a server as a middle man which abstracts the APIs we manage (excluding partners) and aggregates the data with a single, generic type shared between both sides

The server would be in charge of putting up a generic interface to access and filter all the assets Decentraland knows about

  1. Write and use a server as a middle man which abstracts all APIs away, aggregates the data with a single, generic type shared between both sides and handles contract interactions

The server would be in charge of putting up a generic interface to access and filter all assets and the interaction with them, having to know also each contract and how to access it

Decision Outcome

We choose option 2 because it gives us many advantages over centralizing the logic in the front-end, like:

but allowing us to keep parts that are Marketplace-centric in the front end, like the interaction with partners and with contracts.

License

Copyright and related rights waived via CC0-1.0. Living