OpenMinter is dApp framework for enabling the creation and collection of non-fungible tokens (NFTs) on Tezos. The dApp enables anyone to create an NFT by filling in just a few fields, create new collection contracts, see their NFTs across contracts, and enable marketplace capabilities to trade them.
Current version supports the following:
π Beacon support
βοΈ The latest FA2 spec
- Tezos sandbox: Flextesa
- Blockhain indexer: Better Call Dev Backend
- Database: PostgreSQL
- InterPlanetary File System: IPFS
To install and build the dependences required for local development, run:
$ yarn installThe installation process will fetch toplevel NPM dependences and build
the minter-ui-dev and minter-api-dev Docker images. Subsequent runs of
yarn install will rebuild these images without checking for cached versions.
The Minter can be configured to run on three different networks: sandbox,
testnet (currently set to delphinet), and mainnet.
Each network has its own configuration file in the config folder under
minter.<network>.json. The schema of these files can be defined as this
TypeScript type:
type Config = {
rpc: string,
network: string,
bcd: {
api: string,
gui: string
},
admin: {
address: string,
secret: string
},
pinata?: {
apiKey: string,
secretKey: string
},
contracts?: {
nftFaucet?: string
}
}For example, the following minter.sandbox.json configuration defines the RPC
url for the local sandbox node and the default alice address as the
administrator during contract origination:
{
"rpc": "http://localhost:8732",
"admin": {
"address": "tz1YPSCGWXwBdTncK2aCctSZAXWvGsGwVJqU",
"secret": "edsk3RFgDiCt7tWB2oe96w1eRw72iYiiqZPLu9nnEY23MYRp2d8Kkx"
}
}Note: Since sandbox keys don't represent sensitive accounts, the
config/folder includes default configurations withadminwallets. To configure Minter for thetestnetormainnetnetworks, update the definitions inconfig/minter.<network>.example.jsonand copy it to the proper path for the application to read it. For:
cp config/minter.mainnet.example.json config/minter.mainnet.json
If the contracts key or its children nftFaucet or nftFactory keys are not
specified, these contracts will be originated and their addresses saved in the
configuration file when starting the Minter devleopment environment.
Testnet and Mainnet instances of OpenMinter can include Pinata API keys in order to direct all file uploads through their service. This allows for ease of use while working with IPFS as running OpenMinter without Pinata will rely on using and maintaining a local IPFS node.
Note: The example
testnetandmainnetconfigurations in theconfig/folder have placeholder Pinata API keys. If you want to use OpenMinter on these networks without Pinata, remove thepinatakey from the configuration.
During its start process, Minter will create or update Docker services for its specified environment and also bootstrap the required contracts if their addresses are not defined in the environment's configuration file.
To start Minter on a sandbox network, run:
$ yarn start:sandboxThis command will start the following services:
flextesasandbox container- Better Call Dev indexer API, GUI, and its required backend services
- Minter UI
- Minter API
- IPFS Node
To stop and teardown these services, run:
$ yarn stop:sandboxTo start Minter on a testnet network, run:
$ yarn start:testnetThis command will start the following services:
- Minter UI
- Minter API
- IPFS Node
To stop and teardown these services, run:
$ yarn stop:testnetTo start Minter on a mainnet network, run:
$ yarn start:mainnetThis command will start the following services:
- Minter UI
- Minter API
- IPFS Node
To stop and teardown these services, run:
$ yarn stop:mainnetAfter starting Minter, you can now open:
- http://localhost:9000 to view the Minter application.
- http://localhost:9000/graphql to open the GraphQL playground.
- http://localhost:5001/webui to open the IPFS Web UI
To see a list of services running after you've started the system, run:
$ docker service lsTo view each service's logs, the bin/log command is available. It can be run
using yarn scripts yarn log or directly. It's a small wrapper around
docker service logs that matches the first service you provide
it:
$ yarn log:api...which is a shorter way of doing the following:
$ docker service logs minter-dev-sandbox_api-server --follow --rawTo view the UI output, for example, run:
$ yarn log:uiYou may also override the script's default docker service logs arguments
(--follow and --raw) by passing them at the end of the command. For example:
$ yarn log:api --since 5mDocker development images are set up to reload server and web ui on source code changes.
To setup this project for an IDE, you will want to install NPM dependencies
outside of Docker. Make sure you have Yarn
(version 1.22.x or above) installed:
$ pushd client; yarn; popd
$ pushd server; yarn; popdIndividual services in docker stack can be restarted like so:
$ docker service scale minter-dev-sandbox_api-server=0
$ docker service scale minter-dev-sandbox_api-server=1Or with a helper shell function
$ svc-restart api-serverwhere svc-restart is defined as
$ svc-restart(){docker service scale minter-dev-sandbox_$1=0 && docker service scale minter-dev-sandbox_$1=1}Development ui and api server builds can be swapped out for release builds:
$ bin/build-release-imagesand then
STACK_API_SERVER_DEF=api-server STACK_UI_DEF=ui bin/start