In Ocean Protocol, marketplaces and publishers play different roles (outlined in the Terminology page), but both roles can be played by the same person or organization. Initially, we anticipate that will be the most common setup. As a result, this guide explains how to set up and run a combined marketplace/publisher (for now).
- Have assets to offer in your marketplace.
- Prepare those assets to work with Ocean Protocol.
- Develop a marketplace/publisher app.
- Run everything you need to run in production.
At the time of writing, the following kinds of assets were supported:
- data sets stored in Azure Storage (i.e. with “core.windows.net” in their URL). See the tutorial about setting up Azure Storage to work with Ocean Protocol.
- data sets stored in Amazon S3 storage (i.e. with “s3://” in their URL). See the tutorial about setting up Amazon S3 storage to work with Ocean Protocol.
- data sets stored in on-premise storage. See the tutorial about setting up on-premise storage to work with Ocean Protocol.
You can use all of the above. You aren’t restricted to using only one storage provider.
Support for other kinds of assets (e.g. computing in Azure) is coming.
At the time of writing, we recommend the following steps to develop a marketplace/publisher app:
- Do the React App Tutorial.
- Grow your app from there.
For more examples and inspiration, check out the source code for Pleuston and the the source code for the Commons Marketplace. Both have an Apache v2 open source license. Both use React and squid-js. Both are “serverless” apps: they run entirely in the browser and have no server-side component.
🦄 Web app for consumers to explore, download, and publish data assets. ⛲️ Commons Marketplace client & server to explore, download, and publish open data sets in the Ocean Network.
🦄 Web app for consumers to explore, download, and publish data assets.
⛲️ Commons Marketplace client & server to explore, download, and publish open data sets in the Ocean Network.
A marketplace/publisher app could have both a back-end component and a front-end component. The main consideration is that you should probably use a programming language with an existing Squid library:
There are examples of how to use squid-py in the Tutorials. squid-py is to Ocean like boto3 is to AWS.
Of course, you could always write your own Squid library in the language of your choice.
When developing your marketplace/publisher app, you will probably use Barge to run all the Ocean Protocol components on your local machine. When it comes time to go to production, you will have to run some of those components in production:
- Your marketplace/publisher app
- A database to go with Aquarius, e.g. Elasticsearch or MongoDB
- Recommended: a keeper node with the keeper contracts deployed to it, connected to an Ocean network
- Optional: your own Secret Store nodes (for a more advanced setup)
Before running all of that in production, you will want to test it with an Ocean Protocol testnet.
Of course, there are many other things that must be handled in production:
- Security of the infrastructure where the software is running
- Log aggregation, storage and search
- Handling crashes or other faults
Each of those is a big topic beyond the scope of these docs.