DEV Community: Nader Dabit

Introduction to Execution Machine (EXM) - Permanent Serverless Functions

Nader Dabit — Wed, 26 Oct 2022 20:25:25 +0000

Introduction to Execution Machine (EXM)

The code for this tutorial is located here

EXM is a language-agnostic serverless environment powered by Arweave, and enables developers to create permanent, serverless functions on the blockchain.

EXM eliminates the need to understand smart contracts, transactions, or blocks to leverage blockchain technology.

EXM / Arweave provide something that most traditional data stores do not - permanence. Once the data / transactions are stored, they can be retrieved and consumed forever (or as long as the network exists).

Some interesting use cases might be registries, games, CMSs, permanent data protocols, general data processing, and possibly even building a permanent NoSQL database.

Under the hood, EXM utilizes SmartWeave

Lazy Evaluation

The Smartweave (and therefore EXM) execution layer is based on what's known as "Lazy Evaluation".

In most blockchains, the computation and current state is executed by the blockchain nodes. With lazy evaluation, the burden of execution is shifted to either the client or a middle layer (like EXM) that implements a processor and conveyor that essentially re-evaluates and caches the latest state of the contract so that the client does not need to process all previous transactions in order to calculate the current state.

CLI vs SDK

You can interact with EXV either via their CLI or their SDK. In this tutorial we'll be interacting with the platform using the JavaScript SDK.

Hello World tutorial

Let's explore how to build, deploy, and test an EXM app.

In this example we'll create a basic CMS that will allow a user to create, update, and delete posts. This example will enable us to implement a basic CRUD app which is the basis for most real-world applications.

Prerequisites

To be successful with this tutorial you must have:

An EXM API key. You can get one here
Node.js installed on your machine. I recommend installing Node.js either via NVM or FNM
Mocha installed globally (if you want to run tests)

Getting started

To get started, we'll create a new Node.js project in an empty directory:

npm init --y

Next, we'll install the dependencies we'll need for our app:

npm install @execution-machine/sdk uuid chai

Finally, update package.json to add this configuration to enable ES Modules:

"type": "module",

Basic setup

For a basic EXM app you need these basic components:

Initial state for the program
A handler function to manage state updates. This function is the entry point for your EXM function. For a write operation to be considered valid as well as able to change the state of the function, it needs to return an object with state property in it. (more on this later)
A script to deploy the program
Scripts to read and update the state of the program

Configuring EXM

To interact with the platform we'll need some basic configuration that we can set up and reuse.

First, make sure you've created an EXM API key here.

Next, create and set an environment variable either in your local config file, or from your terminal:

export EXM_PK=<your-api-key>

Now, create a new file named exm.js and add the following code:

/* exm.js */
import { Exm } from '@execution-machine/sdk'

const APIKEY = process.env.EXM_PK
export const exmInstance = new Exm({ token: APIKEY })

Now we'll be able to interact with EXM by importing exmInstance.

Initial State

As mentioned previously, the app we'll be creating will allow users to create, edit, and delete posts. A post will be an object with the following fields:

type Post {
  id: string
  title: string
  content: string
  author: string
}

To hold the posts, we can create some data structure to hold a list of posts. I will be using an object but you could also use an array.

To set up this initial state, create a new file named state.js and add the following code:

/* state.js */
export const state = {
  "posts": {}
}

Handler function

Now that we have the initial state defined we'll create the handler function.

Create a new file named handler.js and add the following code:

/* handler.js */
export async function handle(state, action) {
  const { input } = action
  if (input.type === 'createPost' || input.type === 'updatePost') {
    state.posts[input.post.id] = input.post
  }
  if (input.type === 'deletePost') {
    delete state.posts[input.postId]
  }
  return { state }
}

This function will accept three different types of actions:

createPost - Creates a new post
updatePost - Updates an existing post with new data
deletePost - Deletes a post

If the input type does not match any of these, then the state is just returned without any update.

Deploy script

Now that we have the state and the handler function defined, we can create the deploy script.

This script will deploy our function to EXM and make it available for us to start using.

Create a new file named deploy.js and add the following code:

/* deploy.js */
import { ContractType } from '@execution-machine/sdk'
import fs from 'fs'
import { exmInstance } from './exm.js'
import { state } from './state.js'

const contractSource = fs.readFileSync('handler.js')
const data = await exmInstance.functions.deploy(contractSource, state, ContractType.JS)

console.log({ data })

/* after the contract is deployed, write the function id to a local file */
fs.writeFileSync('./functionId.js', `export const functionId = "${data.id}"`)

Creating a new post

Next let's look at how to make a state update.

The first thing we'll want to try to do is to create a new post. Create a new file named createPost.js and add the following code:

/* createPost.js */
import { exmInstance } from './exm.js'
import { functionId } from './functionId.js'
import { v4 as uuid } from 'uuid'

const id = uuid()

/* the inputs array defines the data that will be available in the handler function as action.input */
const inputs = [{
  type: 'createPost',
  post: {
    id,
    title: "Hello world",
    content: "My first post",
    author: "Nader Dabit"
  }
}]

const data = await exmInstance.functions.write(functionId, inputs)
console.log({ data })

As commented in the code above, the most important thing to recognize is the structure of the array of inputs, and how they correlate to the arguments received in the handler function.

In createPost.js, the type will determine the type of state update that is made in the handler, and the post is the data used in the state update.

Reading the current state

Now that we have a way to deploy the function and create a post, let's look at how to read the state.

To do so, create a file named read.js and add the following code:

/* read.js */
import { exmInstance } from './exm.js'
import { functionId } from './functionId.js'

const data = await exmInstance.functions.read(functionId)
console.log("data: ", JSON.stringify(data))

You can also read the state of any function ID by calling or visiting https://api.exm.dev/read/<function-id>

Trying it out

Now that everything is set up, let's give it a spin!

From your terminal, run the deploy script:

node deploy.js

Once the function has been deployed, you should see a new file written to the project named functionId.js.

Next, read the current state of the program:

node read.js

The return value of the state should be an empty posts object.

Now, create a new post:

node createPost.js

Then read the state of the app again:

node read.js

The return value should now include the new post that was just created.

Reminder that you can also read the state of any function ID by calling or visiting https://api.exm.dev/read/<function-id>

Updating and deleting posts

Let's now create the scripts for updating and deleting posts.

For deleting a post, create a file named deletePost.js and add the following code:

/* deletePost.js */
import { exmInstance } from './exm.js'
import { functionId } from './functionId.js'

const inputs = [{
  type: 'deletePost',
  postId: process.argv[2]
}];

await exmInstance.functions.write(functionId, inputs)

This script takes a post ID as input from the user running the script, and uses it to call the deletePost input, passing in the postId as an argument.

To update a post, create a new file named updatePost.js and add the following code:

/* updatePost.js */
import { exmInstance } from './exm.js'
import { functionId } from './functionId.js'

const inputs = [{
  type: 'updatePost',
  post: {
    id: process.argv[2],
    title: "Hello world V2",
    content: "My updated post!",
    author: "Nader Dabit"
  }
}]

const data = await exmInstance.functions.write(functionId, inputs)

console.log({ data })

Now, you should be able to update and delete posts by running these two scripts, passing in the post ID:

node deletePost.js <post-id>

Testing

EXM also comes built in with testing functions in their SDK to facilitate testing in a way that can be readable & efficient.

Let's create a test script that will check that all of our action types work as we expect.

Create a new file named test.js and add the following code:

import fs from 'fs'
import { TestFunction, createWrite, FunctionType } from "@execution-machine/sdk"
import { state } from './state.js'
import { v4 as uuid } from 'uuid'
import { expect } from 'chai'

const id = uuid()
const functionSource = fs.readFileSync('./handler.js')

const createPost = {
  type: 'createPost',
  post: {
    id,
    title: "Hello world",
    content: "My first post",
    author: "Nader Dabit"
  }
}

const updatePost = {
  type: 'updatePost',
  post: {
    id,
    title: "Hello world V2",
    content: "My updated post!",
    author: "Nader Dabit"
  }
}

const deletePost = {
  type: 'deletePost',
  postId: id
}

describe("Testing EXM", function () {
  it("Should create a post", async function () {
    const testAttempt = await TestFunction({
      functionSource,
      functionType: FunctionType.JAVASCRIPT,
      functionInitState: state,
      writes: [createWrite(createPost)]
    })
    const value = testAttempt.state.posts[id]

    expect(value.id).to.equal(id)
    expect(value.title).to.equal("Hello world")
  })

  it("Should update a post", async function () {
    const testAttempt = await TestFunction({
      functionSource,
      functionType: FunctionType.JAVASCRIPT,
      functionInitState: state,
      writes: [createWrite(createPost), createWrite(updatePost)]
    })
    const value = testAttempt.state.posts[id]
    expect(value.title).to.equal("Hello world V2")
  })

  it("Should delete a post", async function () {
    const testAttempt = await TestFunction({
      functionSource,
      functionType: FunctionType.JAVASCRIPT,
      functionInitState: state,
      writes: [createWrite(createPost), createWrite(deletePost)]
    })
    const value = testAttempt.state.posts
    const length = Object.keys(value).length
    expect(length).to.equal(0)
  })
})

To test, run the following command:

mocha test.js

Next steps

To learn more about EXM, check out the EXM Discord.

To learn more about the Arweave Developer Ecosystem, check out learn.arweave.dev.

Building Full Stack Permanent Applications with Arweave, Smartweave, and Next.js

Nader Dabit — Sat, 10 Sep 2022 19:12:27 +0000

The code for this tutorial can be found here

In this tutorial you'll learn how to build full stack dapps on Arweave with Smarweave, Warp, and Next.js.

Smartweave TLDR

Code smart contracts in JS, TS, or Rust
Execute arbitrary amounts of compute without additional fees
Never have to worry about gas optimizations
No state bloat
Can directly process rich content / large files
Warp offers enhancements (speed, caching, sdks)

The application we'll be building is a full stack blog, meaning that you will have an open, public, and composable back end that can be transferred and reused anywhere (not only in this app).

Unlike most blockchain applications working with large or arbitrary amounts of data, Smartweave enables all of the state for this app to be stored directly on-chain.

I think this is a good example as it's not too basic as to be boring, but not too complex as to be confusing. It shows how to do most of the basic things you'll need and want to understand in order to build more complex and sophisticated applications going forward.

About Arweave

Arweave is a web3 protocol that allows developers to permanently store files like images, videos, and pdfs as well as single page web applications.

Arweave introduced the idea of the permaweb - a permanent, global, community-owned web that anyone can contribute to or get paid to maintain.

Smartweave

Arweave also introduced SmartWeave: a smart contract protocol that allows developers to build permanent applications on top of Arweave.

When you publish a Smartweave contract, the program’s source code and its initial state is stored in an Arweave transaction.

When a user writes an update to a SmartWeave program, they write their inputs as a new Arweave transaction.

To calculate the state of the contract, a SmartWeave client uses the contract source code to execute the history of inputs sequentially. Invalid transactions are ignored.

In doing so, SmartWeave pushes the responsibility of validating transactions onto the users.

Warp

Warp (https://warp.cc/) is a protocol built on top of Arweave meant to facilitate a better DX/UX for Smartweave application development.

Warp consists of 3 main layers:

The Core Protocol layer is the implementation of the original SmartWeave protocol and is responsible for communication with the SmartWeave smart contracts deployed on Arweave
The Caching layer - is build on top of the Core Protocol layer and allows caching results of each of the Core Protocol modules separately.

This allows you to quickly retrieve data from contracts with a large number of state updates, but also offers instant transactions and contracts availability and finality.
Extensions layer - a CLI, Debugging tools, different logging implementations, so called "dry-runs" (i.e. actions that allow to quickly verify the result of given contract interaction without writing anything on Arweave).

Getting started

Now that we know a little bit about the underlying technology, let's start building.

Prerequisites

To be successful in this tutorial, you should have Node.js 16.17.0 or greater installed on your machine.

I recommend using either nvm or fnm to manage Node.js versions.

Creating and configuring the project

To get started, let's first create the Next.js application, configure it, and install the dependencies.

npx create-next-app full-stack-arweave

Change into the new directory and install the following dependencies:

npm install warp-contracts react-markdown uuid

Configuring the Next.js app

Open package.json and add the following configuration:

"type": "module",

Then update next.config.js to use ES Modules to export the nextConfig:

/* replace */
module.exports = nextConfig

/* with this*/
export default nextConfig

This will enable the Next.js app to use ES Modules.

Next, add the following to the .gitignore file:

wallet.json
testwallet.json
transactionid.js

Never push wallet information to any public place like GitHub. In this tutorial we'll only be working with testnet, but we'll have the code available for you to push to mainnet. Just in case, we're adding wallet.json to .gitignore.

Warp Contracts

Next, let's create and test out the smart contracts.

About Smartweave contracts

Smartweave contracts work like this.

1. An initial state for the application is defined as a JSON object.

Some basic initial state might look something like this for a counter application that increments and decrements a number:

{
"counter" : 0
}

2. The logic of a Smartweave contract is written in a function named handle.

This function defines different actions that can be called on the contract, which manipulate the state. Actions are similar to functions in a normal smart contract or program. Each action will update the state in some way.

A basic handler for a counter that uses the above state might look something like this:

export function handle(state, action) {
  if (action.input.function === 'increment') {
    state.counter += 1
  }
  if (action.input.function === 'decrement') {
    state.counter -= 1
  }
  return { state }
}

In this handler, there are two actions - increment or decrement. The logic here is pretty straightforward.

3. To update the state of the contract, we can call writeInteraction from the Warp SDK.

Here's a basic example of how this might look when calling this function on the server:

import { WarpFactory } from 'warp-contracts'
const transactionId = "BA3EIfkKvlPXLk5sEN8loAmp2zr0MezSPhwaujTNli8"
import wallet from './wallet.json'

let warp = WarpFactory.forLocal()
const contract = warp.contract(transactionId).connect(wallet)
await contract.writeInteraction({
  function: "decrement"
})

Then, we can read the state at any time:

const contract = warp.contract(transactionId).connect();
const { cachedValue } = await contract.readState();

Writing the contract

Now that we have a basic understanding of how contracts work, let's start writing some code.

In the root of the project, create a new folder named warp.

In this folder, create a new file named contract.js:

/* warp/contract.js */
export function handle(state, action) {
  /* address of the caller is available in action.caller */
  if (action.input.function === 'initialize') {
    state.author = action.caller
  }
  if (action.input.function === 'createPost' && action.caller === state.author) {
    const posts = state.posts
    posts[action.input.post.id] = action.input.post
    state.posts = posts
  }
  if (action.input.function === 'updatePost' && action.caller === state.author) {
    const posts = state.posts
    const postToUpdate = action.input.post
    posts[postToUpdate.id] = postToUpdate
    state.posts = posts
  }
  if (action.input.function === 'deletePost' && action.caller === state.author) {
    const posts = state.posts
    delete posts[action.input.post.id]
    state.posts = posts
  }
  return { state }
}

This is the contract for our blogging app.

We have functions to create, update, and delete a post (CRUD). We also have an initialize function which adds a basic authorization rule that only allows the blog owner to call any of these functions by setting the contract deployer as the owner.

Next, create a file in the warp directory named state.json and add the following JSON:

{
  "posts": {},
  "author": null
}

Here, we have an initial state of posts set to an empty object, and author set to null.

We're done with our contract, now let's write the code to deploy, update, and read the state of the contract.

Deploy, update, and read

Next, create a new file named configureWarpServer.js in the warp directory.

import { WarpFactory } from 'warp-contracts'
import fs from 'fs'

/*
*  environment can be 'local' | 'testnet' | 'mainnet' | 'custom';
*/

const environment = process.env.WARPENV || 'testnet'
let warp

if (environment === 'testnet') {
  warp = WarpFactory.forTestnet()
} else if (environment === 'mainnet') {
  warp = WarpFactory.forMainnet()
} else {
  throw Error('environment not set properly...')
}

async function configureWallet() {
  try {
    if (environment === 'testnet') {
      /* for testing, generate a temporary wallet */
      try {
        return JSON.parse(fs.readFileSync('../testwallet.json', 'utf-8'))
      } catch (err) {
        const { jwk } = await warp.generateWallet()
        fs.writeFileSync('../testwallet.json', JSON.stringify(jwk))
        return jwk
      }
    } else if (environment === 'mainnet') {
      /* for mainnet, retrieve a local wallet */
      return JSON.parse(fs.readFileSync('../wallet.json', 'utf-8'))
    } else {
      throw Error('Wallet not configured properly...')
    }
  } catch (err) {
    throw Error('Wallet not configured properly...', err)
  }
}

export {
  configureWallet,
  warp
}

In this file we're configuring warp server based on whether we're in a testing or mainnet (production) environment.

We then have a function that configures the wallet we'll be using to deploy the contract. If we're testing, we can just spin up a test wallet automatically using generateWallet. If we're in production, we have the option of importing a wallet locally.

Now that we have the ability to configure a wallet and a Warp server, let's create the function for deploying the contracts.

Deploying the contract

Create a new file named deploy.js in the warp directory with the following code:

import fs from 'fs'
import { configureWallet, warp } from './configureWarpServer.js'

async function deploy() {
  const wallet = await configureWallet()
  const state = fs.readFileSync('state.json', 'utf-8')
  const contractsource = fs.readFileSync('contract.js', 'utf-8')

  const { contractTxId } = await warp.createContract.deploy({
    wallet,
    initState: state,
    src: contractsource
  })
  fs.writeFileSync('../transactionid.js', `export const transactionId = "${contractTxId}"`)

  const contract = warp.contract(contractTxId).connect(wallet)
  await contract.writeInteraction({
    function: 'initialize'
  })
  const { cachedValue } = await contract.readState()

  console.log('Contract state: ', cachedValue)
  console.log('contractTxId: ', contractTxId)
}

deploy()

The deploy function will deploy the contract to Arweave and write the transaction id to the local file system.

Reading the state

Next, let's create a file named read.js with the following code:

import { warp, configureWallet } from './configureWarpServer.js'
import { transactionId } from '../transactionid.js'

async function read() {
  let wallet = await configureWallet()
  const contract = warp.contract(transactionId).connect(wallet);
  const { cachedValue } = await contract.readState();

  console.log('Contract state: ', JSON.stringify(cachedValue))
}
read()

Writing an update

The last function we'll write is for creating a new post.

In the warp directory, create a new file named createPost.js with the following code:

import { warp, configureWallet } from './configureWarpServer.js'
import { transactionId } from '../transactionid.js'
import { v4 as uuid } from 'uuid'

async function createPost() {
  let wallet = await configureWallet()
  const contract = warp.contract(transactionId).connect(wallet)
  await contract.writeInteraction({
    function: "createPost",
    post: {
      title: "Hi from first post!",
      content: "This is my first post!",
      id: uuid()
    }
  })
}

createPost()

Testing it out

Now we can test everything out.

To deploy the contract, run the following command from the warp directory:

node deploy

This should deploy the contract to testnet.

Once the contract has been deployed, you can use the Sonar block explorer to view the contract and the current state of it. The contract transaction ID will be available in transactionid.js. Be sure to switch to testnet to view the contract from this deployment.

Next, let's read the current state:

node read

The returned state of the contract should look something like this:

{"state":{"posts":{},"author":"-YzqAM_VDCqFZEk6iZ3B8Y-b6SxHoh0F1SvjOCW49nY"},"validity":{"36CmMGSlrGNvvCCfldtiUza4ZnQ9_bFW0YoEh8NCVe0":true},"errorMessages":{}}

Now, let's create a post:

node createPost

Now, when we read the updated state, we should see the new post in the updated state:

node read

Building out the web app

Now that we understand how to deploy and test out a Smartweave contract with Warp, let's build out a front-end application that will interact with it and use it.

Since the application we're building is a blog, we'll need to create two basic views:

A view to see the posts created by the user.
A view to allow users to create posts.

We'll also need a file to hold a function we'll be using to configure warp for the client (similar to how we configured warp for the server previously).

Create a new file named configureWarpClient.js in the root of the app and add the following code:

import { WarpFactory } from 'warp-contracts'
import { transactionId } from './transactionid'
import wallet from './testwallet'

/*
*  environment can be 'local' | 'testnet' | 'mainnet' | 'custom';
*/

const environment = process.env.NEXT_PUBLIC_WARPENV || 'testnet'
let warp
let contract

async function getContract() {
  if (environment == 'testnet') {
    warp = WarpFactory.forTestnet()
    contract = warp.contract(transactionId).connect(wallet)
  } else if (environment === 'mainnet') {
    warp = WarpFactory.forMainnet()
    contract = warp.contract(transactionId).connect()
  } else {
    throw new Error('Environment configured improperly...')
  }
  return contract
}

export {
  getContract
}

Creating a post

Next, in the pages directory create a new file named create-post.js and add the following code:

import { useState } from 'react'
import { getContract } from '../configureWarpClient'
import { v4 as uuid } from 'uuid'
import { useRouter } from 'next/router'

export default function createPostComponent() {
  const [post, updatePost] = useState({
    title: '', content: ''
  })
  const router = useRouter()

  async function createPost() {
    if (!post.title || !post.content) return
    post.id = uuid()
    const contract = await getContract()
    try {
      const result = await contract.writeInteraction({
        function: "createPost",
        post
      })
      console.log('result:', result)
      router.push('/')
    } catch (err) {
      console.log('error:', err)
    }
  }
  return (
    <div style={formContainerStyle}>
      <input
        value={post.title}
        placeholder="Post title"
        onChange={e => updatePost({ ...post, title: e.target.value})}
        style={inputStyle}
      />
      <textarea
        value={post.content}
        placeholder="Post content"
        onChange={e => updatePost({ ...post, content: e.target.value})}
        style={textAreaStyle}
      />
      <button style={buttonStyle} onClick={createPost}>Create Post</button>
    </div>
  )
}

const formContainerStyle = {
  width: '900px',
  margin: '0 auto',
  display: 'flex',
  flexDirection: 'column',
  alignItems: 'flex-start'
}

const inputStyle = {
  width: '300px',
  padding: '8px',
  fontSize: '18px',
  border: 'none',
  outline: 'none',
  marginBottom: '20px'
}

const buttonStyle = {
  width: '200px',
  padding: '10px 0px'
}

const textAreaStyle = {
  width: '100%',
  height: '300px',
  marginBottom: '20px',
  padding: '20px'
}

Reading and displaying posts

Next, update pages/index.js with the following code:

import { useEffect, useState } from 'react'
import { getContract } from '../configureWarpClient'
import ReactMarkdown from 'react-markdown'

export default function Home() {
  const [posts, setPosts] = useState([])
  useEffect(() => {
    readState()
  }, [])
  async function readState() {
    const contract = await getContract()
    try {
      const data = await contract.readState()
      console.log('data: ', data)
      const posts = Object.values(data.cachedValue.state.posts)
      setPosts(posts)
      console.log('posts: ', posts)
    } catch (err) {
      console.log('error: ', err)
    }
  }

  return (
    <div style={containerStyle}>
      <h1 style={headingStyle}>PermaBlog</h1>
      {
        posts.map((post, index) => (
          <div key={index} style={postStyle}>
            <p style={titleStyle}>{post.title}</p>
            <ReactMarkdown>
              {post.content}
            </ReactMarkdown>
          </div>
        ))
      }
    </div>
  )
}

const containerStyle = {
  width: '900px',
  margin: '0 auto'
}

const headingStyle = {
  fontSize: '64px'
}
const postStyle = {
  padding: '15px 0px 0px',
  borderBottom: '1px solid rgba(255, 255, 255, .2)'
}

const titleStyle = {
  fontSize: '34px',
  marginBottom: '0px'
}

Navigation

Next, update pages/_app.js

import '../styles/globals.css'
import Link from 'next/link'

function MyApp({ Component, pageProps }) {
  return (
    <div>
      <nav style={navStyle}>
        <Link href="/" style={linkStyle}>
          Home
        </Link>
        <Link href="/create-post" style={linkStyle}>
          Create Post
        </Link>
      </nav>
      <Component {...pageProps} />
    </div>
  )
}

const navStyle = {
  padding: '30px 100px'
}

const linkStyle = {
  marginRight: '30px'
}

export default MyApp

Testing it out

Now let's run the app and test it out:

npm run dev

When the app loads, the post created on the server should be rendered in the UI.

Next, create a post. If the post is successfully created, it should show up in the list of posts on the home page.

Next Steps

Deploying to mainnet

If you'd like to deploy and connect to Arweave mainnet, follow these steps:

Download ArConnect wallet
Request AR tokens from faucet, purchase them from an exchange, or swap at an exchange like changeNOW
Download new wallet into a file named wallet.json. Be sure to add this file to your .gitignore and never ever make public or push to Git.
Set local environment variable to mainnet in the terminal session you will be deploying from :
```
export WARPENV=mainnet
```
Create .env.local file in the root of the app and add the following environment variable:
```
NEXT_PUBLIC_WARPENV=mainnet
```
Deploy the contract from the warp directory:
```
node deploy
```
Run the app
```
npm run dev
```

Learning resources

If you'd like to dive deeper and learn more about Warp, Smartweave, and Arweave, check out Warp Academy

The Complete Guide to Full Stack Web3 Development

Nader Dabit — Thu, 10 Feb 2022 12:33:58 +0000

Building a full stack web3 app with Next.js, Polygon, Solidity, The Graph, IPFS, and Hardhat

The video for this tutorial is also available here

In this in depth tutorial you'll learn the tools, protocols, and frameworks for building full stack web3 apps, and most importantly - how to put everything together to lay the groundwork for building out any of your own ideas in the future.

The codebase for this app is located here

The main network we'll be deploying to is Polygon. I chose Polygon because of its low transaction cost, fast block times, and current network adoption.

That being said, we're going to be building on the Ethereum Virtual Machine (EVM), so you can apply these skills to build for dozens of other blockchain networks as well, including Ethereum, Celo, Avalanche, and many others.

The app we'll be building is a full stack blog as well as a content management system (CMS), meaning that you will have an open, public, and composable back end that can be transferred and reused anywhere.

By the end of this tutorial you should have a good understanding of the most important pieces of a modern web3 stack and how to build performant, scalable, full stack decentralized blockchain applications.

This is the fourth guide in my "Full Stack" web3 series. Also be sure to check out:

The web3 stack

In Defining the web3 stack I wrote about my interpretation of the current state of the web3 tech stack from a developer's perspective using a combination of my own personal experience as well as research that was done over the past year on my team at Edge & Node.

We will be using pieces of this stack for this application:

Blockchain - Polygon (with optional RPC provider)
Ethereum development environment - Hardhat
Front end framework - Next.js & React
Ethereum web client library - Ethers.js
File storage - IPFS
Indexing and querying - The Graph Protocol

Learning how to use these building blocks we can build out many types of applications, so the goal with this tutorial is to show how they each work and how they all fit together.

Let's get started!

Prerequisites

Node.js installed on your local machine
MetaMask Chrome extension installed in your browser

Project setup

Here we will create the application boilerplates, install all of the necessary dependencies, and configure the project.

The code will be commented to give you insight as to what is happening, and I'll describe some of what is going on throughout the tutorial as well.

To get started, create a new Next.js application and change into the new directory:



npx create-next-app web3-blog

cd web3-blog

Next, change into the new directory and install the following dependencies using either npm, yarn, or pnpm:



npm install ethers hardhat @nomiclabs/hardhat-waffle \
ethereum-waffle chai @nomiclabs/hardhat-ethers \
web3modal @walletconnect/web3-provider \
easymde react-markdown react-simplemde-editor \
ipfs-http-client @emotion/css @openzeppelin/contracts

An overview of some of these dependencies:

hardhat - Ethereum development environment
web3modal - An easy-to-use library that allows users to connect their wallets to your app
react-markdown and simplemde - Markdown editor and markdown renderer for the CMS
@emotion/css - A great CSS in JS library
@openzeppelin/contracts - Open source implementations of useful smart contract standards and functionality

Next, we'll initialize the local smart contract development environment.



npx hardhat

? What do you want to do? Create a basic sample project
? Hardhat project root: <Choose default path>

If you get an error referencing your README.md, delete README.md and run npx hardhat again.

This should scaffold out the basic Solidity development environment that we will use. You should see a few new files and folders created, including contracts, scripts, test, and hardhat.config.js.

Next, let's update the hardhat configuration at hardhat.config.js.

Update this file with the following code:



require("@nomiclabs/hardhat-waffle");

module.exports = {
  solidity: "0.8.4",
  networks: {
    hardhat: {
      chainId: 1337
    },
    // mumbai: {
    //   url: "https://rpc-mumbai.matic.today",
    //   accounts: [process.env.pk]
    // },
    // polygon: {
    //   url: "https://polygon-rpc.com/",
    //   accounts: [process.env.pk]
    // }
  }
};

Here, we've configured the local hardhat development environment as well as set up (and commented out) the Polygon mainnet and Mumbai testnet environments that we'll be using to deploy to Polygon.

Next, let's add some basic global CSS that we'll be needing to style the markdown editor for the CMS.

Open styles/globals.css and add the following code below the existing css:



.EasyMDEContainer .editor-toolbar {
  border: none;
}

.EasyMDEContainer .CodeMirror {
  border: none !important;
  background: none;
}

.editor-preview {
  background-color: white !important;
}

.CodeMirror .cm-spell-error:not(.cm-url):not(.cm-comment):not(.cm-tag):not(.cm-word) {
  background-color: transparent !important;
}

pre {
  padding: 20px;
  background-color: #efefef;
}

blockquote {
  border-left: 5px solid #ddd;
  padding-left: 20px;
  margin-left: 0px;
}

Next, we'll create a couple of SVG files for the app images, one for the logo and one as an arrow button.

Create logo.svg and right-arrow.svg in the public folder and copy the linked SVG code into each of those files.

The smart contract

Next, let's create the smart contract that will be powering our blog and CMS.

Create a new file in the contracts folder named Blog.sol.

Here, add the following code:



// contracts/Blog.sol
//SPDX-License-Identifier: Unlicense
pragma solidity ^0.8.0;

import "hardhat/console.sol";
import "@openzeppelin/contracts/utils/Counters.sol";

contract Blog {
    string public name;
    address public owner;

    using Counters for Counters.Counter;
    Counters.Counter private _postIds;

    struct Post {
      uint id;
      string title;
      string content;
      bool published;
    }
    /* mappings can be seen as hash tables */
    /* here we create lookups for posts by id and posts by ipfs hash */
    mapping(uint => Post) private idToPost;
    mapping(string => Post) private hashToPost;

    /* events facilitate communication between smart contractsand their user interfaces  */
    /* i.e. we can create listeners for events in the client and also use them in The Graph  */
    event PostCreated(uint id, string title, string hash);
    event PostUpdated(uint id, string title, string hash, bool published);

    /* when the blog is deployed, give it a name */
    /* also set the creator as the owner of the contract */
    constructor(string memory _name) {
        console.log("Deploying Blog with name:", _name);
        name = _name;
        owner = msg.sender;
    }

    /* updates the blog name */
    function updateName(string memory _name) public {
        name = _name;
    }

    /* transfers ownership of the contract to another address */
    function transferOwnership(address newOwner) public onlyOwner {
        owner = newOwner;
    }

    /* fetches an individual post by the content hash */
    function fetchPost(string memory hash) public view returns(Post memory){
      return hashToPost[hash];
    }

    /* creates a new post */
    function createPost(string memory title, string memory hash) public onlyOwner {
        _postIds.increment();
        uint postId = _postIds.current();
        Post storage post = idToPost[postId];
        post.id = postId;
        post.title = title;
        post.published = true;
        post.content = hash;
        hashToPost[hash] = post;
        emit PostCreated(postId, title, hash);
    }

    /* updates an existing post */
    function updatePost(uint postId, string memory title, string memory hash, bool published) public onlyOwner {
        Post storage post =  idToPost[postId];
        post.title = title;
        post.published = published;
        post.content = hash;
        idToPost[postId] = post;
        hashToPost[hash] = post;
        emit PostUpdated(post.id, title, hash, published);
    }

    /* fetches all posts */
    function fetchPosts() public view returns (Post[] memory) {
        uint itemCount = _postIds.current();

        Post[] memory posts = new Post[](itemCount);
        for (uint i = 0; i < itemCount; i++) {
            uint currentId = i + 1;
            Post storage currentItem = idToPost[currentId];
            posts[i] = currentItem;
        }
        return posts;
    }

    /* this modifier means only the contract owner can */
    /* invoke the function */
    modifier onlyOwner() {
      require(msg.sender == owner);
    _;
  }
}

This contract allows the owner to create and edit posts, and for anyone to fetch posts.

To make this smart contract permissionless, you could remove the onlyOwner modifier and use The Graph to index and query posts by owner.

Next, let's write a basic test to test out the most important functionality we'll be using.

To do so, open test/sample-test.js and update it with the following code:



const { expect } = require("chai")
const { ethers } = require("hardhat")

describe("Blog", async function () {
  it("Should create a post", async function () {
    const Blog = await ethers.getContractFactory("Blog")
    const blog = await Blog.deploy("My blog")
    await blog.deployed()
    await blog.createPost("My first post", "12345")

    const posts = await blog.fetchPosts()
    expect(posts[0].title).to.equal("My first post")
  })

  it("Should edit a post", async function () {
    const Blog = await ethers.getContractFactory("Blog")
    const blog = await Blog.deploy("My blog")
    await blog.deployed()
    await blog.createPost("My Second post", "12345")

    await blog.updatePost(1, "My updated post", "23456", true)

    posts = await blog.fetchPosts()
    expect(posts[0].title).to.equal("My updated post")
  })

  it("Should add update the name", async function () {
    const Blog = await ethers.getContractFactory("Blog")
    const blog = await Blog.deploy("My blog")
    await blog.deployed()

    expect(await blog.name()).to.equal("My blog")
    await blog.updateName('My new blog')
    expect(await blog.name()).to.equal("My new blog")
  })
})

Next, run the test by opening your terminal and running this command:



npx hardhat test

Deploying the contract

Now that the contract has been written and tested, let's try to deploy it to a local test network.

To start the local network, open your terminal at least two separate windows. In one window, run the following script:



npx hardhat node

When we run this command, you should see a list of addresses and private keys.

These are 20 test accounts and addresses created for us that we can use to deploy and test our smart contracts. Each account is also loaded up with 10,000 fake Ether. In a moment, we'll learn how to import the test account into MetaMask so that we can use it.

Next, we need to deploy the contract to the test network. First update the name of scripts/sample-script.js to scripts/deploy.js.

Next, update the file with this new deploy script:



/* scripts/deploy.js */
const hre = require("hardhat");
const fs = require('fs');

async function main() {
  /* these two lines deploy the contract to the network */
  const Blog = await hre.ethers.getContractFactory("Blog");
  const blog = await Blog.deploy("My blog");

  await blog.deployed();
  console.log("Blog deployed to:", blog.address);

  /* this code writes the contract addresses to a local */
  /* file named config.js that we can use in the app */
  fs.writeFileSync('./config.js', `
  export const contractAddress = "${blog.address}"
  export const ownerAddress = "${blog.signer.address}"
  `)
}

main()
  .then(() => process.exit(0))
  .catch((error) => {
    console.error(error);
    process.exit(1);
  });

Now in a separate window (while the local network is still running) we can run the deploy script and give a flag to the CLI that we would like to deploy to our local network:



npx hardhat run scripts/deploy.js --network localhost

When the contract is deployed, you should see some output in your network terminal 🎉.

Importing the test account into your wallet

To send transactions to the smart contract, we will need to connect our MetaMask wallet using one of the accounts created when we ran npx hardhat node. In the list of contracts that the CLI logs out, you should see both an Account number as well as a Private Key:



➜  react-dapp git:(main) npx hardhat node
Started HTTP and WebSocket JSON-RPC server at http://127.0.0.1:8545/

Accounts
========
Account #0: 0xf39fd6e51aad88f6f4ce6ab8827279cfffb92266 (10000 ETH)
Private Key: 0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80

...

We can import this account into MetaMask in order to start using some of the fake Eth available there.

To do so, first open MetaMask and enable test networks:

Next, update the network to be Localhost 8545:

Next, in MetaMask click on Import Account from the accounts menu:

Copy then paste the very first Private Key logged out by the CLI and click Import. Once the account is imported, you should see the Eth in the account:

Be sure you imported the first account in the list of accounts (Account #0) as this will be the account used by default when the contract is deployed and therefore the contract owner.

Now that we have a smart contract deployed and an account ready to use, we can start interacting with it from the Next.js app.

The Next.js app

Next, let's write the code for the app.

The first thing we'll do is set up a couple of environment variables that we'll use to switch between a local testing environment, Mumbai testnet, and Polygon mainnet.

Create a new file named .env.local in the root of your project and add the following configuration to start with:



ENVIRONMENT="local"
NEXT_PUBLIC_ENVIRONMENT="local"

We will be able to switch these variables between local, testnet, and mainnet to switch between

This will allow us to reference our environment both on the client as well as the server. To learn more about how environment variables work in Next.js, check out the documentation here.

context.js

Next, let's create the app context. Context will give us an easy way to share state throughout the app.

Create a file named context.js and add the following code:



import { createContext } from 'react'

export const AccountContext = createContext(null)

Layout and Nav

Next, let's open up pages/_app.js. Here we will update the code to include navigation, wallet connection, context, and some basic styling.

This page serves as a wrapper or layout for the rest of the app.



/* pages/__app.js */
import '../styles/globals.css'
import { useState } from 'react'
import Link from 'next/link'
import { css } from '@emotion/css'
import { ethers } from 'ethers'
import Web3Modal from 'web3modal'
import WalletConnectProvider from '@walletconnect/web3-provider'
import { AccountContext } from '../context.js'
import { ownerAddress } from '../config'
import 'easymde/dist/easymde.min.css'

function MyApp({ Component, pageProps }) {
  /* create local state to save account information after signin */
  const [account, setAccount] = useState(null)
  /* web3Modal configuration for enabling wallet access */
  async function getWeb3Modal() {
    const web3Modal = new Web3Modal({
      cacheProvider: false,
      providerOptions: {
        walletconnect: {
          package: WalletConnectProvider,
          options: { 
            infuraId: "your-infura-id"
          },
        },
      },
    })
    return web3Modal
  }

  /* the connect function uses web3 modal to connect to the user's wallet */
  async function connect() {
    try {
      const web3Modal = await getWeb3Modal()
      const connection = await web3Modal.connect()
      const provider = new ethers.providers.Web3Provider(connection)
      const accounts = await provider.listAccounts()
      setAccount(accounts[0])
    } catch (err) {
      console.log('error:', err)
    }
  }

  return (
    <div>
      <nav className={nav}>
        <div className={header}>
          <Link href="/">
            <a>
              <img
                src='/logo.svg'
                alt="React Logo"
                style={{ width: '50px' }}
              />
            </a>
          </Link>
          <Link href="/">
            <a>
              <div className={titleContainer}>
                <h2 className={title}>Full Stack</h2>
                <p className={description}>WEB3</p>
              </div>
            </a>
          </Link>
          {
            !account && (
              <div className={buttonContainer}>
                <button className={buttonStyle} onClick={connect}>Connect</button>
              </div>
            )
          }
          {
            account && <p className={accountInfo}>{account}</p>
          }
        </div>
        <div className={linkContainer}>
          <Link href="/" >
            <a className={link}>
              Home
            </a>
          </Link>
          {
            /* if the signed in user is the contract owner, we */
            /* show the nav link to create a new post */
            (account === ownerAddress) && (
              <Link href="/create-post">
                <a className={link}>
                  Create Post
                </a>
              </Link>
            )
          }
        </div>
      </nav>
      <div className={container}>
        <AccountContext.Provider value={account}>
          <Component {...pageProps} connect={connect} />
        </AccountContext.Provider>
      </div>
    </div>
  )
}

const accountInfo = css`
  width: 100%;
  display: flex;
  flex: 1;
  justify-content: flex-end;
  font-size: 12px;
`

const container = css`
  padding: 40px;
`

const linkContainer = css`
  padding: 30px 60px;
  background-color: #fafafa;
`

const nav = css`
  background-color: white;
`

const header = css`
  display: flex;
  border-bottom: 1px solid rgba(0, 0, 0, .075);
  padding: 20px 30px;
`

const description = css`
  margin: 0;
  color: #999999;
`

const titleContainer = css`
  display: flex;
  flex-direction: column;
  padding-left: 15px;
`

const title = css`
  margin-left: 30px;
  font-weight: 500;
  margin: 0;
`

const buttonContainer = css`
  width: 100%;
  display: flex;
  flex: 1;
  justify-content: flex-end;
`

const buttonStyle = css`
  background-color: #fafafa;
  outline: none;
  border: none;
  font-size: 18px;
  padding: 16px 70px;
  border-radius: 15px;
  cursor: pointer;
  box-shadow: 7px 7px rgba(0, 0, 0, .1);
`

const link = css`
  margin: 0px 40px 0px 0px;
  font-size: 16px;
  font-weight: 400;
`

export default MyApp

Entrypoint

Now that we have the layout set up, let' create the entrypoint to the app.

This page will fetch the list of posts from the network and render the post titles in a listview. When the user clicks on a post, we will navigate them to another page for a detail view (page will be created next).



/* pages/index.js */
import { css } from '@emotion/css'
import { useContext } from 'react'
import { useRouter } from 'next/router'
import { ethers } from 'ethers'
import Link from 'next/link'
import { AccountContext } from '../context'

/* import contract address and contract owner address */
import {
  contractAddress, ownerAddress
} from '../config'

/* import Application Binary Interface (ABI) */
import Blog from '../artifacts/contracts/Blog.sol/Blog.json'

export default function Home(props) {
  /* posts are fetched server side and passed in as props */
  /* see getServerSideProps */
  const { posts } = props
  const account = useContext(AccountContext)

  const router = useRouter()
  async function navigate() {
    router.push('/create-post')
  }

  return (
    <div>
      <div className={postList}>
        {
          /* map over the posts array and render a button with the post title */
          posts.map((post, index) => (
            <Link href={`/post/${post[2]}`} key={index}>
              <a>
                <div className={linkStyle}>
                  <p className={postTitle}>{post[1]}</p>
                  <div className={arrowContainer}>
                  <img
                      src='/right-arrow.svg'
                      alt='Right arrow'
                      className={smallArrow}
                    />
                  </div>
                </div>
              </a>
            </Link>
          ))
        }
      </div>
      <div className={container}>
        {
          (account === ownerAddress) && posts && !posts.length && (
            /* if the signed in user is the account owner, render a button */
            /* to create the first post */
            <button className={buttonStyle} onClick={navigate}>
              Create your first post
              <img
                src='/right-arrow.svg'
                alt='Right arrow'
                className={arrow}
              />
            </button>
          )
        }
      </div>
    </div>
  )
}

export async function getServerSideProps() {
  /* here we check to see the current environment variable */
  /* and render a provider based on the environment we're in */
  let provider
  if (process.env.ENVIRONMENT === 'local') {
    provider = new ethers.providers.JsonRpcProvider()
  } else if (process.env.ENVIRONMENT === 'testnet') {
    provider = new ethers.providers.JsonRpcProvider('https://rpc-mumbai.matic.today')
  } else {
    provider = new ethers.providers.JsonRpcProvider('https://polygon-rpc.com/')
  }

  const contract = new ethers.Contract(contractAddress, Blog.abi, provider)
  const data = await contract.fetchPosts()
  return {
    props: {
      posts: JSON.parse(JSON.stringify(data))
    }
  }
}

const arrowContainer = css`
  display: flex;
  flex: 1;
  justify-content: flex-end;
  padding-right: 20px;
`

const postTitle = css`
  font-size: 30px;
  font-weight: bold;
  cursor: pointer;
  margin: 0;
  padding: 20px;
`

const linkStyle = css`
  border: 1px solid #ddd;
  margin-top: 20px;
  border-radius: 8px;
  display: flex;
`

const postList = css`
  width: 700px;
  margin: 0 auto;
  padding-top: 50px;  
`

const container = css`
  display: flex;
  justify-content: center;
`

const buttonStyle = css`
  margin-top: 100px;
  background-color: #fafafa;
  outline: none;
  border: none;
  font-size: 44px;
  padding: 20px 70px;
  border-radius: 15px;
  cursor: pointer;
  box-shadow: 7px 7px rgba(0, 0, 0, .1);
`

const arrow = css`
  width: 35px;
  margin-left: 30px;
`

const smallArrow = css`
  width: 25px;
`

Creating posts

Next, create a new file in the pages directory named create-post.js.

This will hold the route that will allow us to create posts and save them to the network.

We'll also have the option to upload and save a cover image to IPFS, with the hash of the ipfs upload anchored on chain with the rest of the most data.

Add the following code to this file:



/* pages/create-post.js */
import { useState, useRef, useEffect } from 'react' // new
import { useRouter } from 'next/router'
import dynamic from 'next/dynamic'
import { css } from '@emotion/css'
import { ethers } from 'ethers'
import { create } from 'ipfs-http-client'

/* import contract address and contract owner address */
import {
  contractAddress
} from '../config'

import Blog from '../artifacts/contracts/Blog.sol/Blog.json'

/* define the ipfs endpoint */
const client = create('https://ipfs.infura.io:5001/api/v0')

/* configure the markdown editor to be client-side import */
const SimpleMDE = dynamic(
  () => import('react-simplemde-editor'),
  { ssr: false }
)

const initialState = { title: '', content: '' }

function CreatePost() {
  /* configure initial state to be used in the component */
  const [post, setPost] = useState(initialState)
  const [image, setImage] = useState(null)
  const [loaded, setLoaded] = useState(false)

  const fileRef = useRef(null)
  const { title, content } = post
  const router = useRouter()

  useEffect(() => {
    setTimeout(() => {
      /* delay rendering buttons until dynamic import is complete */
      setLoaded(true)
    }, 500)
  }, [])

  function onChange(e) {
    setPost(() => ({ ...post, [e.target.name]: e.target.value }))
  }

  async function createNewPost() {   
    /* saves post to ipfs then anchors to smart contract */
    if (!title || !content) return
    const hash = await savePostToIpfs()
    await savePost(hash)
    router.push(`/`)
  }

  async function savePostToIpfs() {
    /* save post metadata to ipfs */
    try {
      const added = await client.add(JSON.stringify(post))
      return added.path
    } catch (err) {
      console.log('error: ', err)
    }
  }

  async function savePost(hash) {
    /* anchor post to smart contract */
    if (typeof window.ethereum !== 'undefined') {
      const provider = new ethers.providers.Web3Provider(window.ethereum)
      const signer = provider.getSigner()
      const contract = new ethers.Contract(contractAddress, Blog.abi, signer)
      console.log('contract: ', contract)
      try {
        const val = await contract.createPost(post.title, hash)
        /* optional - wait for transaction to be confirmed before rerouting */
        /* await provider.waitForTransaction(val.hash) */
        console.log('val: ', val)
      } catch (err) {
        console.log('Error: ', err)
      }
    }    
  }

  function triggerOnChange() {
    /* trigger handleFileChange handler of hidden file input */
    fileRef.current.click()
  }

  async function handleFileChange (e) {
    /* upload cover image to ipfs and save hash to state */
    const uploadedFile = e.target.files[0]
    if (!uploadedFile) return
    const added = await client.add(uploadedFile)
    setPost(state => ({ ...state, coverImage: added.path }))
    setImage(uploadedFile)
  }

  return (
    <div className={container}>
      {
        image && (
          <img className={coverImageStyle} src={URL.createObjectURL(image)} />
        )
      }
      <input
        onChange={onChange}
        name='title'
        placeholder='Give it a title ...'
        value={post.title}
        className={titleStyle}
      />
      <SimpleMDE
        className={mdEditor}
        placeholder="What's on your mind?"
        value={post.content}
        onChange={value => setPost({ ...post, content: value })}
      />
      {
        loaded && (
          <>
            <button
              className={button}
              type='button'
              onClick={createNewPost}
            >Publish</button>
            <button
              onClick={triggerOnChange}
              className={button}
            >Add cover image</button>
          </>
        )
      }
      <input
        id='selectImage'
        className={hiddenInput} 
        type='file'
        onChange={handleFileChange}
        ref={fileRef}
      />
    </div>
  )
}

const hiddenInput = css`
  display: none;
`

const coverImageStyle = css`
  max-width: 800px;
`

const mdEditor = css`
  margin-top: 40px;
`

const titleStyle = css`
  margin-top: 40px;
  border: none;
  outline: none;
  background-color: inherit;
  font-size: 44px;
  font-weight: 600;
  &::placeholder {
    color: #999999;
  }
`

const container = css`
  width: 800px;
  margin: 0 auto;
`

const button = css`
  background-color: #fafafa;
  outline: none;
  border: none;
  border-radius: 15px;
  cursor: pointer;
  margin-right: 10px;
  font-size: 18px;
  padding: 16px 70px;
  box-shadow: 7px 7px rgba(0, 0, 0, .1);
`

export default CreatePost

Viewing a post

Now that we have the ability to create posts, how do we navigate and view posts? We want to have the ability to view a post in a route that looks something like myapp.com/post/some-post-id.

We can do this in a couple of different ways with next.js dynamic routes.

We will be leveraging server-side data fetching using getStaticPaths and getStaticProps which will create these pages at build time using the array of posts queried from the network.

To make this happen, create a new folder in the pages directory named post and a file in that folder named [id].js. There, add the following code:



/* pages/post/[id].js */
import ReactMarkdown from 'react-markdown'
import { useContext } from 'react'
import { useRouter } from 'next/router'
import Link from 'next/link'
import { css } from '@emotion/css'
import { ethers } from 'ethers'
import { AccountContext } from '../../context'

/* import contract and owner addresses */
import {
  contractAddress, ownerAddress
} from '../../config'
import Blog from '../../artifacts/contracts/Blog.sol/Blog.json'

const ipfsURI = 'https://ipfs.io/ipfs/'

export default function Post({ post }) {
  const account = useContext(AccountContext)
  const router = useRouter()
  const { id } = router.query

  if (router.isFallback) {
    return <div>Loading...</div>
  }

  return (
    <div>
      {
        post && (
          <div className={container}>
            {
              /* if the owner is the user, render an edit button */
              ownerAddress === account && (
                <div className={editPost}>
                  <Link href={`/edit-post/${id}`}>
                    <a>
                      Edit post
                    </a>
                  </Link>
                </div>
              )
            }
            {
              /* if the post has a cover image, render it */
              post.coverImage && (
                <img
                  src={post.coverImage}
                  className={coverImageStyle}
                />
              )
            }
            <h1>{post.title}</h1>
            <div className={contentContainer}>
              <ReactMarkdown>{post.content}</ReactMarkdown>
            </div>
          </div>
        )
      }
    </div>
  )
}

export async function getStaticPaths() {
  /* here we fetch the posts from the network */
  let provider
  if (process.env.ENVIRONMENT === 'local') {
    provider = new ethers.providers.JsonRpcProvider()
  } else if (process.env.ENVIRONMENT === 'testnet') {
    provider = new ethers.providers.JsonRpcProvider('https://rpc-mumbai.matic.today')
  } else {
    provider = new ethers.providers.JsonRpcProvider('https://polygon-rpc.com/')
  }

  const contract = new ethers.Contract(contractAddress, Blog.abi, provider)
  const data = await contract.fetchPosts()

  /* then we map over the posts and create a params object passing */
  /* the id property to getStaticProps which will run for ever post */
  /* in the array and generate a new page */
  const paths = data.map(d => ({ params: { id: d[2] } }))

  return {
    paths,
    fallback: true
  }
}

export async function getStaticProps({ params }) {
  /* using the id property passed in through the params object */
  /* we can us it to fetch the data from IPFS and pass the */
  /* post data into the page as props */
  const { id } = params
  const ipfsUrl = `${ipfsURI}/${id}`
  const response = await fetch(ipfsUrl)
  const data = await response.json()
  if(data.coverImage) {
    let coverImage = `${ipfsURI}/${data.coverImage}`
    data.coverImage = coverImage
  }

  return {
    props: {
      post: data
    },
  }
}

const editPost = css`
  margin: 20px 0px;
`

const coverImageStyle = css`
  width: 900px;
`

const container = css`
  width: 900px;
  margin: 0 auto;
`

const contentContainer = css`
  margin-top: 60px;
  padding: 0px 40px;
  border-left: 1px solid #e7e7e7;
  border-right: 1px solid #e7e7e7;
  & img {
    max-width: 900px;
  }
`

Editing a post

The final page we need to create is a way to edit existing posts.

This page will carry over some functionality from both pages/create-post.js as well as pages/post/[id].js. We will be able to toggle between viewing and editing a post.

Create a new folder in the pages directory named edit-post and a file named [id].js there. Next, add the following code:



/* pages/edit-post/[id].js */
import { useState, useEffect } from 'react'
import { useRouter } from 'next/router'
import ReactMarkdown from 'react-markdown'
import { css } from '@emotion/css'
import dynamic from 'next/dynamic'
import { ethers } from 'ethers'
import { create } from 'ipfs-http-client'

import {
  contractAddress
} from '../../config'
import Blog from '../../artifacts/contracts/Blog.sol/Blog.json'

const ipfsURI = 'https://ipfs.io/ipfs/'
const client = create('https://ipfs.infura.io:5001/api/v0')

const SimpleMDE = dynamic(
  () => import('react-simplemde-editor'),
  { ssr: false }
)

export default function Post() {
  const [post, setPost] = useState(null)
  const [editing, setEditing] = useState(true)
  const router = useRouter()
  const { id } = router.query

  useEffect(() => {
    fetchPost()
  }, [id])
  async function fetchPost() {
    /* we first fetch the individual post by ipfs hash from the network */
    if (!id) return
    let provider
    if (process.env.NEXT_PUBLIC_ENVIRONMENT === 'local') {
      provider = new ethers.providers.JsonRpcProvider()
    } else if (process.env.NEXT_PUBLIC_ENVIRONMENT === 'testnet') {
      provider = new ethers.providers.JsonRpcProvider('https://rpc-mumbai.matic.today')
    } else {
      provider = new ethers.providers.JsonRpcProvider('https://polygon-rpc.com/')
    }
    const contract = new ethers.Contract(contractAddress, Blog.abi, provider)
    const val = await contract.fetchPost(id)
    const postId = val[0].toNumber()

    /* next we fetch the IPFS metadata from the network */
    const ipfsUrl = `${ipfsURI}/${id}`
    const response = await fetch(ipfsUrl)
    const data = await response.json()
    if(data.coverImage) {
      let coverImagePath = `${ipfsURI}/${data.coverImage}`
      data.coverImagePath = coverImagePath
    }
    /* finally we append the post ID to the post data */
    /* we need this ID to make updates to the post */
    data.id = postId;
    setPost(data)
  }

  async function savePostToIpfs() {
    try {
      const added = await client.add(JSON.stringify(post))
      return added.path
    } catch (err) {
      console.log('error: ', err)
    }
  }

  async function updatePost() {
    const hash = await savePostToIpfs()
    const provider = new ethers.providers.Web3Provider(window.ethereum)
    const signer = provider.getSigner()
    const contract = new ethers.Contract(contractAddress, Blog.abi, signer)
    await contract.updatePost(post.id, post.title, hash, true)
    router.push('/')
  }

  if (!post) return null

  return (
    <div className={container}>
      {
      /* editing state will allow the user to toggle between */
      /*  a markdown editor and a markdown renderer */
      }
      {
        editing && (
          <div>
            <input
              onChange={e => setPost({ ...post, title: e.target.value })}
              name='title'
              placeholder='Give it a title ...'
              value={post.title}
              className={titleStyle}
            />
            <SimpleMDE
              className={mdEditor}
              placeholder="What's on your mind?"
              value={post.content}
              onChange={value => setPost({ ...post, content: value })}
            />
            <button className={button} onClick={updatePost}>Update post</button>
          </div>
        )
      }
      {
        !editing && (
          <div>
            {
              post.coverImagePath && (
                <img
                  src={post.coverImagePath}
                  className={coverImageStyle}
                />
              )
            }
            <h1>{post.title}</h1>
            <div className={contentContainer}>
              <ReactMarkdown>{post.content}</ReactMarkdown>
            </div>
          </div>
        )
      }
      <button className={button} onClick={() => setEditing(editing ? false : true)}>{ editing ? 'View post' : 'Edit post'}</button>
    </div>
  )
}

const button = css`
  background-color: #fafafa;
  outline: none;
  border: none;
  border-radius: 15px;
  cursor: pointer;
  margin-right: 10px;
  margin-top: 15px;
  font-size: 18px;
  padding: 16px 70px;
  box-shadow: 7px 7px rgba(0, 0, 0, .1);
`

const titleStyle = css`
  margin-top: 40px;
  border: none;
  outline: none;
  background-color: inherit;
  font-size: 44px;
  font-weight: 600;
  &::placeholder {
    color: #999999;
  }
`

const mdEditor = css`
  margin-top: 40px;
`

const coverImageStyle = css`
  width: 900px;
`

const container = css`
  width: 900px;
  margin: 0 auto;
`

const contentContainer = css`
  margin-top: 60px;
  padding: 0px 40px;
  border-left: 1px solid #e7e7e7;
  border-right: 1px solid #e7e7e7;
  & img {
    max-width: 900px;
  }
`

Testing it out

We can now test it out.

To do so, be sure you have already deployed the contract to the network in the previous steps and you still have the local network running.

Open a new terminal window and start the Next.js app:



npm run dev

When the app starts, you should be able to connect your wallet and interact with the app.

You should also be able to create a new post.

You may notice that the app is not as fast as it could be, but Next.js is blazingly fast in production.

To run a production build, run the following commands:



npm run build && npm start

Deploying to Polygon

Now that we have the project up and running and tested locally, let's deploy to Polygon. We'll start by deploying to Mumbai, the Polygon test network.

The first thing we will need to do is set one of our private keys from our wallet as an environment variable.

To get a private key, you can export them directly from MetaMask.

Private keys are never meant to be shared publicly under any circumstance. It is advised never to hardcode a private key in a file. If you do choose to do so, be sure to use a testing wallet and to never under any circumstances push a file containing a private key to source control or expose it publicly.

If you are on a Mac, you can set an environment variable from the command line like so (be sure to run the deploy script from this same terminal and session):



export pk="your-private-key"

Configuring the network

Next, we need to switch from the local test network to the Mumbai Testnet.

To do so, we need to create and set the network configuration.

First, open MetaMask and click on Settings.

Next, click on Networks and then Add Network:

Here, we will add the following configurations for the Mumbai test network as listed here:

Network Name: Mumbai TestNet
New RPC URL: https://rpc-mumbai.matic.today
Chain ID: 80001
Currency Symbol: Matic

Save this, then you should be able to switch to and use the new network!

Finally, you will need some testnet Polygon tokens in order to interact with the applications.

To get these, you can visit the Polygon Faucet, inputting the address of the wallets that you would like to request the tokens.

Deploying to the Polygon network

Now that you have some tokens, you can deploy to the Polygon network!

To do so, be sure that the address associated with the private key you are deploying your contract with has received some tokens in order to pay the gas fees for the transaction.

Next, uncomment the mumbai configuration in hardhat.config.js:



mumbai: {
  url: "https://rpc-mumbai.matic.today",
  accounts: [process.env.pk]
},

To deploy to Polygon testnet, run the following command:



npx hardhat run scripts/deploy.js --network mumbai

If you run into this error: ProviderError: RPCError, the public RPC may be congested. In production, it's recommended to use an RPC provider like Infura, Alchemy, or Quicknode.

Next, update the environment variables in .env.local to be testnet:



ENVIRONMENT="testnet"
NEXT_PUBLIC_ENVIRONMENT="testnet"

Next, restart the server to register the change in environment variables:



npm run dev

You should now be able to test the app on the new network 🎉!

If you have any issues connecting to the public Mumbai RPC endpoint, consider replacing the endpoints in your app using endpoints from an RPC provider like Infura, Alchemy, or Quicknode.

Creating a subgraph API

By default the only data access patterns we have are the two functions we've written into the contract, fetchPost and fetchPosts.

This is a fine place to start, but as your app starts to scale you'll probably find yourself needing a more flexible and scalable API.

For instance, what if we wanted to give the user the ability to search posts, fetch posts created by a certain user, or to sort posts by the date which they were created?

We can build all of this functionality into an API by using The Graph protocol. Let's see how to do this.

Creating the project in The Graph

To get started, visit The Graph hosted service and either sign in or create a new account.

Next, go to the dashboard and click on Add Subgraph to create a new subgraph.

Configure your subgraph with the following properties:

Subgraph Name - Blogcms
Subtitle - A subgraph for querying post data
Optional - Fill the description and GITHUB URL properties

Once the subgraph is created, we will initialize the subgraph locally using the Graph CLI.

Initializing a new subgraph using the Graph CLI

Next, install the Graph CLI:



$ npm install -g @graphprotocol/graph-cli

# or

$ yarn global add @graphprotocol/graph-cli

Once the Graph CLI has been installed you can initialize a new subgraph with the Graph CLI init command.

Since we've already deployed our contract to the network, we can initialize from that contract address by passing in the contract address using the --from-contract flag.

This address is available for reference in config.js as contractAddress.



$ graph init --from-contract your-contract-address \
--network mumbai --contract-name Blog --index-events

? Protocol: ethereum
? Product for which to initialize › hosted-service
? Subgraph name › your-username/blogcms
? Directory to create the subgraph in › blogcms
? Ethereum network › mumbai
? Contract address › your-contract-address
? ABI file (path) › artifacts/contracts/Blog.sol/Blog.json
? Contract Name › Blog

This command will generate a basic subgraph based off of the contract address passed in as the argument to --from-contract. By using this contract address, the CLI will initialize a few things in your project to get you started (including fetching the abis and saving them in the abis directory).

By passing in --index-events the CLI will automatically populate some code for us both in schema.graphql as well as src/mapping.ts based on the events emitted from the contract.

The main configuration and definition for the subgraph lives in the subgraph.yaml file. The subgraph codebase consists of a few files:

subgraph.yaml: a YAML file containing the subgraph manifest
schema.graphql: a GraphQL schema that defines what data is stored for your subgraph, and how to query it via GraphQL
AssemblyScript Mappings: AssemblyScript code that translates from the event data in Ethereum to the entities defined in your schema (e.g. mapping.ts in this tutorial)

The entries in subgraph.yaml that we will be working with are:

description (optional): a human-readable description of what the subgraph is. This description is displayed by the Graph Explorer when the subgraph is deployed to the Hosted Service.
repository (optional): the URL of the repository where the subgraph manifest can be found. This is also displayed by the Graph Explorer.
dataSources.source: the address of the smart contract the subgraph sources, and the abi of the smart contract to use. The address is optional; omitting it allows to index matching events from all contracts.
dataSources.source.startBlock (optional): the number of the block that the data source starts indexing from. In most cases we suggest using the block in which the contract was created.
dataSources.mapping.entities : the entities that the data source writes to the store. The schema for each entity is defined in the the schema.graphql file.
dataSources.mapping.abis: one or more named ABI files for the source contract as well as any other smart contracts that you interact with from within the mappings.
dataSources.mapping.eventHandlers: lists the smart contract events this subgraph reacts to and the handlers in the mapping — ./src/mapping.ts in the example — that transform these events into entities in the store.

Defining the entities

With The Graph, you define entity types in schema.graphql, and Graph Node will generate top level fields for querying single instances and collections of that entity type. Each type that should be an entity is required to be annotated with an @entity directive.

The entities / data we will be indexing are the Token and User. This way we can index the Tokens created by the users as well as the users themselves.

To do this, update schema.graphql with the following code:



type _Schema_
  @fulltext(
    name: "postSearch"
    language: en
    algorithm: rank
    include: [{ entity: "Post", fields: [{ name: "title" }, { name: "postContent" }] }]
  )

type Post @entity {
  id: ID!
  title: String!
  contentHash: String!
  published: Boolean!
  postContent: String!
  createdAtTimestamp: BigInt!
  updatedAtTimestamp: BigInt!
}

Now that we have created the GraphQL schema for our app, we can generate the entities locally to start using in the mappings created by the CLI:



graph codegen

In order to make working smart contracts, events and entities easy and type-safe, the Graph CLI generates AssemblyScript types from a combination of the subgraph's GraphQL schema and the contract ABIs included in the data sources.

Updating the subgraph with the entities and mappings

Now we can configure the subgraph.yaml to use the entities that we have just created and configure their mappings.

To do so, first update the dataSources.mapping.entities field with the User and Token entities:



entities:
  - Post

Next we'll need to find the block which the contract was deployed (optional). We need this so that we can set the start block for the indexer to begin syncing so that it does not need to sync from the genesis block. You can find the start block by visiting https://mumbai.polygonscan.com/ and pasting in your contract address.

Finally, update the configuration to add the startBlock :



source:
  address: "your-contract-adddress"
  abi: Blog
  startBlock: your-start-block

Assemblyscript mappings

Next, open src/mappings.ts to write the mappings that we defined in our subgraph subgraph eventHandlers.

Update the file with the following code:



import {
  PostCreated as PostCreatedEvent,
  PostUpdated as PostUpdatedEvent
} from "../generated/Blog/Blog"
import {
  Post
} from "../generated/schema"
import { ipfs, json } from '@graphprotocol/graph-ts'

export function handlePostCreated(event: PostCreatedEvent): void {
  let post = new Post(event.params.id.toString());
  post.title = event.params.title;
  post.contentHash = event.params.hash;
  let data = ipfs.cat(event.params.hash);
  if (data) {
    let value = json.fromBytes(data).toObject()
    if (value) {
      const content = value.get('content')
      if (content) {
        post.postContent = content.toString()
      }
    }
  }
  post.createdAtTimestamp = event.block.timestamp;
  post.save()
}

export function handlePostUpdated(event: PostUpdatedEvent): void {
  let post = Post.load(event.params.id.toString());
  if (post) {
    post.title = event.params.title;
    post.contentHash = event.params.hash;
    post.published = event.params.published;
    let data = ipfs.cat(event.params.hash);
    if (data) {
      let value = json.fromBytes(data).toObject()
      if (value) {
        const content = value.get('content')
        if (content) {
          post.postContent = content.toString()
        }
      }
    }
    post.updatedAtTimestamp = event.block.timestamp;
    post.save()
  }
}

These mappings will handle events for when a new post is created and when a post is updated. When these events fire, the mappings will save the data into the subgraph.

Running a build

Next, let's run a build to make sure that everything is configured properly. To do so, run the build command:



$ graph build

If the build is successful, you should see a new build folder generated in your root directory.

Deploying the subgraph

To deploy, we can run the deploy command. To deploy, you will first need to copy the Access token for your account, available in the Graph Dashboard:

Next, run the following command:



$ graph auth
✔ Product for which to initialize · hosted-service
✔ Deploy key · ********************************

The deploy the subgraph:



$ yarn deploy

Once the subgraph is deployed, you should see it show up in your dashboard.

When you click on the subgraph, it should open the subgraph details:

Querying for data

Now that we are in the dashboard, we should be able to start querying for data. Run the following query to get a list of posts:



{
  posts {
    id
    title
    contentHash
    published
    postContent
  }
}

We can also configure the order direction by creation date:



{
  posts(
    orderBy: createdAtTimestamp
    orderDirection: desc
  ) {
    id
    title
    contentHash
    published
    postContent
  }
}

We can also do full text search on the post title or content:



{
  postSearch(
    text: "Hello"
  ) {
    id
    title
    contentHash
    published
    postContent
  }
}

Congratulations, you have now build out a more flexible API that you can use to query your app!

To learn how to use the API endpoint in your app, check out the documentation here or the video here

Next steps

If you'd like a challenge, consider adding some functionality that will allow you to update the cover image in pages/edit-post/[id].js.

If you'd like to deploy your code to a web3 / decentralized git hosting protocol, check out this video on Radicle.

If you'd like to deploy your app and make it live, check out Vercel.

If you enjoyed this tutorial, be sure to check out my other three comprehensive guides:

The Complete Guide to Full Stack Ethereum Development
Building a Full Stack NFT Marketplace on Ethereum with Polygon
The Complete Guide to Full Stack Solana Development with React, Anchor, Rust, and Phantom https://dev.to/dabit3/the-complete-guide-to-full-stack-solana-development-with-react-anchor-rust-and-phantom-3291

Defining the web3 stack

Nader Dabit — Thu, 23 Dec 2021 16:07:22 +0000

This post was originally published on the Edge & Node blog

I transitioned into web3 in April 2021 after being a traditional full-stack developer for around 10 years. While diving into all of these new technologies and ideas, the first thing I wanted to know was “what is the web3 stack?”.

When building a traditional web or mobile application, I often depend on a handful of building blocks to get the job done.

API / app servers (REST or GraphQL)
Authentication layer (managed or hand-rolled)
Database
Client-side frameworks, platforms, and libraries
File storage

Using these core components, I can build out most of the types of applications I would like to, or at least get most of the way there. So what did this look like in web3?

It turns out, the answer to this is not so straightforward because:

The paradigm is completely different in many ways
The web3 tools, technologies, and ecosystem are less mature than web2

It was also harder for me to understand how to get up and running with, and build out, web3 applications because I was approaching the problems in the same way that I was in the web2 world.

After working, researching, experimenting, and building things over the past 8 months or so I’d like to share what I’ve learned.

What is web3?

Before we define the web3 stack, let’s attempt to define web3. There are countless definitions depending on who you ask, but to me I find this definition spot on:

Web3 is the stack of protocols that enable fully decentralized applications.

With this decentralized tech stack, we can begin building out decentralized applications which have their own set implications and characteristics.

Some of the characteristics enabled by web3 are:

Decentralized web infrastructure
Ownership (of data, content, and platform)
Native digital payments
Self-sovereign identity
Distributed, trust-less, & robust infrastructure
Open, public, composable back ends

While some of the applications built on decentralized tech stacks will replace their predecessors, a new paradigm of apps have also been made possible by the new primitives enabled by blockchains.

Native digital payments and public back end infrastructure – like machine learning, mobile devices, virtual reality, and other technological primitives, platforms, and building blocks – enable entirely new types of applications to be built, some that have yet to be imagined.

Does this mean that everything is going to be replaced by web3? Not necessarily. While I do think that building on a decentralized tech stack is a much better choice for certain types of applications – like almost any technical decision, it depends on what you are building.

Let’s now start diving into the web3 stack, broken into this set of categories:

Blockchain
Blockchain development environment
File storage
Off chain data protocols
API (indexing & querying)
Identity
Client (frameworks and libraries)
Oracles
Other protocols

Blockchain

There are countless blockchains that you can choose to build on. There is no single one that is "the best", instead you should consider the various tradeoffs between them.

One thing that is often important to me when learning something new is the idea of applying the Pareto principle to what I’m learning. i.e., what is the most efficient way to get the most out of that amount of time and effort. Following this idea I can gain the most traction and momentum while learning something new in the shortest amount of time.

In the Blockchain world, learning Solidity and the EVM (or Ethereum Virtual Machine) might be the best bet when getting started as a blockchain developer. Using this skillset (and tech stack), you can build not only for Ethereum, but other Ethereum Layer 2s, sidechains, and even other blockchains like Avalanche, Fantom, and Celo.

That being said, Rust is beginning to become more and more popular in the blockchain world, with Solana, NEAR, Polkadot, and others having first class Rust support. You probably can’t really go wrong learning either, but for the beginner I’d say that Solidity will still be the better choice if someone asked me today.

Beyond that advice, here is an incomplete sample of blockchains that have a solid combination of technology, utility, community, momentum, and future viability:

Ethereum - original smart contract platform
ZK rollups: ZKSync, Starknet, Hermez - High throughput Ethereum layer 2s, but not natively EVM compatible
Optimistic rollups: Arbitrum & Optimism - Ethereum layer 2s, EVM compatible (learn more about the differences between optimistic and ZK rollups here)
Polygon - Ethereum sidechain
Solana - high throughput, inexpensive transactions, fast block times, but harder to learn than EVM (Rust)
NEAR - Layer 1 blockchain, can write smart contracts in Rust or Assemblyscript
Cosmos - an ecosystem of interoperate blockchains
Polkadot - blockchain-based computing platform that enables blockchains built on top of it to execute transactions between themselves, creating an interconnected internet of blockchains
Fantom - EVM compatible layer 1
Avalanche - EVM compatible Layer 1
Celo - EVM compatible layer 1, designed to make it easy for anyone with a smartphone to send, receive, and store crypto
Tezos - Non EVM compatible layer 1, a lot of NFT projects are using it

When interacting with a network, you'll need to use an RPC endpoint.

There are a few ways you can do this:

Access a public RPC endpoint
Running your own nodes
Accessing a node provider as a service
Accessing a decentralized node provider as a service

Public RPC endpoints are often provided by the network, but for most production dapps you'll want to leverage your own endpoints as they are not stable or recommended for production.

There are a handful of RPC service providers out there, here are a few:

There is also a web3 / decentralized solution, Pocket Network that seems to be gaining traction.

Any of these options are probably a good bet for interacting directly with your network.

Blockchain development environments

For EVM development, there are a few good development environments available:

Hardhat (JavaScript) is a newer option, but one that is gaining more and more popularity. Their docs are great, the tooling and developer experience is polished, and it’s what I’ve personally been using to build dapps.
Truffle (JavaScript) is a suite of tools for building and developing applications on the EVM. It’s mature, battle tested, and well documented. It’s been around for a while and many developers use it.
Foundry is a new Solidity development environment from Paradigm that shows a lot of promise. Key standouts are the ability to write tests in Solidity, support for fuzzing, and speed (it's written in Rust). I wrote a separate introduction to it here.
Brownie is a Python-based development and testing framework for smart contracts for Solidity / EVM development.

For Solana development, Anchor is quickly becoming the entry-point for new developers. It provides a CLI for scaffolding out, building, and testing Solana programs as well as client libraries that you can use for building out front ends. It also includes a DSL that abstracts away a lot of the complexities that developers often run into when they get started with Solana and Rust development.

File storage

Where do we store images, videos, and other files in web3? Storing anything that large on-chain is usually prohibitively expensive, so we probably don’t want to store them there.

Instead, we can use one of a handful of file storage protocols:

IPFS - peer-to-peer file system protocol
- pros: it’s reliable, well documented with a large ecosystem
- cons: if data is not pinned it can be lost
Arweave - allows you to store data permanently, paying a single transaction fee. I’m a fan of Arweave and wrote a blog post about it here.
Filecoin - from Protocol Labs, the same team that build IPFS, it is a protocol designed to provide a system of persistent data storage. There are a handful of ways for developers to build on Filecoin, including web3.storage which is pretty nice.
Skynet - I have not yet used it in production, but have tried it out and it seems to work nicely. The API here looks great. I have questions like how long is the data persisted, and Skynet's interoperability with other protocols.

Off chain data protocols

In addition to file storage and on-chain storage, you may also need to store data off-chain. You might use these types of solutions similarly to how you might use a database in a traditional tech stack, but instead they are replicated across n number of nodes on a decentralized network, and therefore more reliable (at least in theory).

A few options are:

Ceramic Network - a decentralized, open source platform for creating, hosting, and sharing data. Ceramic also has a nice identity protocol that I’ll talk about later. Probably my favorite off-chain storage solution at the moment. Here’s a pretty nice demo.
Textile ThreadDB - a multi-party database built on IPFS and Libp2p. If I understand correctly, it may be going through a big API change at the moment. I’ve tried it and it shows some promise, but the docs and DX need some improvement.
GunDB - a decentralized, peer-to-peer database. Gun has been around for quite sometime and some pretty interesting applications have been built with it.

In terms of maturity, my take is that the ecosystem of off-chain storage solutions is not yet where it needs to be to build out some of the more advanced use cases some developers might want. Some challenges here are real-time data, conflict detection and conflict resolution, write authorization, documentation, and general developer experience.

Integrating offchain data solutions with blockchain protocols is one of the last big hurdles we need to cross before we have a fully decentralized protocol stack capable of supporting any kind of application.

API (indexing & querying)

There are a lot of differences in the way that we interact with and build on top of blockchains versus databases in the traditional tech stack. With blockchains, data isn’t stored in a format that can efficiently or easily be consumed directly from other applications or front ends.

Blockchains are optimized for write operations. You often hear the innovation happening centered around transactions per second, block time, and transaction cost. Blockchain data is written in blocks over the course of time, making anything other than basic read operations impossible.

In most applications, you need features like relational data, sorting, filtering, full text search, pagination and many other types of querying capabilities. In order to do this, data needs to be indexed and organized for efficient retrieval.

Traditionally, that’s the work that databases do in the centralized tech stack, but that indexing layer was missing in the web3 stack.

The Graph is a protocol for indexing and querying blockchain data that makes this process much easier and offers a decentralized solution for doing so. Anyone can build and publish open GraphQL APIs, called subgraphs, making blockchain data easy to query.

To learn more about The Graph, check out the docs here or my tutorial here.

Identity

Identity is a completely different paradigm in web3.
In web2, authentication is almost always based on a user’s personal information. This information is usually gathered either via a form or an OAuth provider that asks the user to hand over in exchange for access to the application.

In web3, identity revolves completely around the idea of wallets and public key cryptography.

While the name “wallet” serves its purpose, I’ve found that people new to web3 find the terminology confusing as it relates to authentication and identity. I hope that in the future we can figure out some other way to convey what a wallet is, as it combines aspects of finance but also identity and reputation.

As a developer, you will need to understand how to access and interact with the user’s wallet and address in various ways.

At a very basic level (and a very common requirement), you might want to request access to the user’s wallet. To do this, you’ll usually be able to access the user’s wallet in the window context (web browser) or using something like WalletConnect or Solana’s Wallet Adapter.

For instance, if they have an Ethereum wallet available, you’ll be able to access window.ethereum. The same for Solana (window.solana), Arweave (window.arweaveWallet), and a handful of others. WalletConnect is good for mobile web and React Native as it allows users to authorize using their mobile wallets directly from the device.

If you want to handle authentication yourself, you can allow the user to sign a transaction and then decode it somewhere to authenticate the user, but this usually requires a server. Here is an example of how that might look using an EVM wallet, and here is an example of how to do this with Solana / Phantom.

What about managing user profiles in a decentralized way? Ceramic Network offers the most robust protocol and suite of tools for managing decentralized identity. They recently released a blog post outlining some of their most recent updates and giving some guidelines around how all of the tools work together. I’d start there and then explore their docs to gain an understanding of how to start building, and consider checking out my example project here that uses Ceramic self.id.

If you want to fetch a user’s ENS text records, the ensjs library offers a nice API for fetching user data:

const ens = new ENS({ provider, ensAddress: getEnsAddress('1') })
const content = await ens.name('sha.eth').getText('avatar')

SpruceID is also something that looks promising but I’ve yet to try it out.

Ceramic and Spruce both implement the W3C DID specificiation, which itself is also something that I would consider as a building block of web3. With that being said, any centralized implementation of DIDs goes against the idea of what the specification is trying to accomplish.

Client

As far as JavaScript frameworks go, you can really build with anything you’d like, as the client-side blockchain SDKs are mostly framework-agnostic. That being said, an overwhelming number of projects and examples are built in React. There are also a handful of libraries like Solana Wallet Adapter that offer additional utilities for React, so I’d say that learning or being familiar with React is going to probably be a smart move.

For client-side SDKs in Ethereum there’s web3.js and ethers.js. To me Ethers is more approachable and has better documentation, though web3.js has been around longer.

In Solana, you’ll probably be working with @solana/web3.js and / or Anchor. I’ve found Anchor client libraries to be my go-to for building Solana programs since I’m using Anchor framework anyway, and I’ve found it much easier to understand then @solana/web3.js.

Oracles

Oracles allow developers access to read real-world data & external systems from within a smart contract.

For example, the majority of financial applications require knowledge of real-world data & events happening off-chain, so Oracles are especially important in DeFi.

Chainlink is an Oracle that enables access to real-world data and off-chain computation while maintaining the security and reliability guarantees inherent to blockchain technology.

Flux is a cross-chain oracle that provides smart contracts with access to economically secure data feeds.

Other protocols

Radicle is a decentralized code collaboration protocol built on Git. It could be thought of as a decentralized version of GitHub.

Livepeer is a decentralized video streaming network. It is mature and widely used with over 70,000 GPUs live on the network.

Wrapping up

This post will be a living document that I keep up with as I learn, experiment, and gather feedback from developers building in web3.

If you have any feedback or ideas around something I’m missing here, please reach and share your thoughts with me.
It’s exciting to see all the activity happening around web3 as developers are jumping in and getting involved. While the infrastructure is still evolving, the vision of building truly decentralized protocols and applications that allow people to coordinate without having to give power and control to large companies is an important one and we’re close to making this vision a reality.

Building and Testing Smart Contracts with Foundry by Paradigm

Nader Dabit — Mon, 20 Dec 2021 19:53:22 +0000

This post was originally published on Mirror

One of the things I really like about Paradigm is that they seem to be very focused on helping builders and developers, and are not afraid to get their hands dirty with code (people like Anish Agnihotri and Georgios Konstantopoulos are some of the best engineers in web3 or maybe anywhere). They also share an enormous amount of some of the highest quality blockchain / web3 / crypto related content in existence. They definitely don't seem like the the typical VC firm.

They recently created and open sourced Foundry, a new Solidity development environment.

Since it came out I've been wanting to try it out, and finally had the chance to this week.

In this post I want to give you a quick rundown of what I learned and how to get started with it.

Foundry Overview

Paradigm's description of Foundry is that Foundry is a portable, fast and modular toolkit for Ethereum application development.

It fits into the stack the same way that Hardhat, Truffle, and Dapp Tools do.

The main differences / selling points of Foundry are:

1. It allows you to write your tests in Solidity instead of JavaScript.

They make a great case about why writing tests in Solidity VS JavaScript is better, and they are spot on with most of their points.

There is just a lot less boilerplate and a lot less mental overhead. Once you write a few tests in Solidity you feel the difference.

2. It's fast.

Foundry is written in Rust and it is fast. They've documented a few benchmarks here, but it's hard to do it justice until you use it (especially after using an alternative).

Foundry is made up of 2 CLI tools - forge and cast.

Forge is the Ethereum development and testing framework.

Cast is a CLI that allows you to interact with EVM smart contracts, send transactions, and read data from the network.

Drawbacks

While Foundry is fantastic for hardcore smart contract development, as an avid Hardhat user and enthusiast, I have to also outline some of the tradeoffs.

At the time of this writing I feel like Hardhat wins for full stack developers because it offers better tooling for switching between and deploying to various networks.

Hardhat also has a robust plugin ecosystem that allows you to extend the project with a lot of additional functionality.

Finally, Hardhat is fairly mature at this point and just works, whereas Foundry is still building out its base feature set.

Now that we've had an overview of Foundry, let's look at how to use it to build and test a smart contract.

Building & testing a smart contract with Foundry

To install Foundry, you must first have Rust installed on your machine.

To get started, we'll install forge

cargo install --git https://github.com/gakonst/foundry --bin forge --locked

Next, in an empty directory, we can use the init command to initialize a new project:

forge init

The forge CLI will create two directories, lib and src.

The lib directory contains the testing contract (lib/ds-test/src/test.sol) as well as a demo test contract implementing some various tests (lib/ds-test/demo/demo.sol).

The src directory contains a barebones smart contract and test.

Let's create a basic smart contract to test out. Rename Contract.sol to HelloWorld.sol and update it with the following:

// SPDX-License-Identifier: MIT
pragma solidity 0.8.10;

contract HelloWorld {
  string private greeting;
  uint public version = 0;

  constructor (string memory _greeting) {
    greeting = _greeting;
  }

  function greet() public view returns(string memory) {
    return greeting;
  }

  function updateGreeting(string memory _greeting) public {
    version += 1;
    greeting = _greeting;
  }
}

Next, we can run a build and compile the ABIs:

forge build

This should create an out directory containing the ABIs for both the main contract as well as the test.

Next, let's update the name of test/Contract.t.sol to test/HelloWorld.t.sol and add the following code:

// SPDX-License-Identifier: MIT
pragma solidity 0.8.10;

import "ds-test/test.sol";
import 'src/HelloWorld.sol';

contract HelloWorldTest is DSTest {
    HelloWorld hello;
    function setUp() public {
      hello = new HelloWorld("Foundry is fast!");
    }

    function test1() public {
        assertEq(
            hello.greet(),
            "Foundry is fast!"
        );
    }

    function test2() public {
        assertEq(hello.version(), 0);
        hello.updateGreeting("Hello World");
        assertEq(hello.version(), 1);
        assertEq(
            hello.greet(),
            "Hello World"
        );
    }
}

Forge comes built in with some really great testing features like assertions and gas cost snapshots.

In our test we've asserted equality using the assertEq utility.

To run the test, we can run:

forge test

When the test is run, we'll see output for not only the success of the test, but also the gas cost:

There are also utilities for:

truthiness - assertTrue

decimal equality - assertEqDecimal

greater than, less than - assertGt, assertGe, assertLt, assertLe

You can view the assertions in the testing contract at lib/ds-test/src/test.sol. These are all of the available functions that we can use in our tests.

Fuzzing

Foundry also supports fuzzing.

This allows us to define function parameter types and the testing framework will populate these values at runtime.

If it does find an input that causes the test to fail, it will return it so you can create a regression test.

For instance, we can update the test2 function to receive a function argument, and use the value in our test without ever having to define what it is:

function test2(string memory _greeting) public {
    assertEq(hello.version(), 0);
    hello.updateGreeting(_greeting);
    assertEq(hello.version(), 1);
    assertEq(
        hello.greet(),
        _greeting
    );
}

Now when we run the test, Foundry will automatically populate the _greeting variable when the test is run.

Conclusion

Foundry is a welcome addition to the web3 stack, bringing improved tooling and performance for smart testing and development.

I'm excited to see this project mature and already would recommend developers looking to quickly build and test non-trivial smart contracts to try it out today.

Huge shout out and thank you to Paradigm for their work building developer tooling like Foundry, it is much appreciated.

The Cloud is Your Development Environment

Nader Dabit — Mon, 04 Oct 2021 17:00:47 +0000

As a developer, one of the things I've grown accustomed to is constantly moving between various projects, their required dependencies, and versions of those dependencies.

Here is a typical workflow that you may be familiar with:

Select project
Check dependencies
Checkout branch
View readme
Install tools and dependencies
Run build
Run test
Start coding

We are seeing a rise in cloud developer environments that abstract and automate these steps away, removing friction, improving developer experience, and speeding up development time by just making things easier.

In contrast with the above workflow, what if it was this simple?

Select project 👩‍💻
Start coding 🚀

Over the years we've seen the iteration and maturation of this idea, with projects like Replit, StackBlitx, CodeSandbox, JSFiddle, and countless others improving over the course time.

The obvious end goal here was to make it so that anyone, on any machine, anywhere in the world, could jump in and start building, contributing, and collaborating on production codebases without having to go through monotonous, time consuming, and often complex environment setup and from any machine in the world that had a browser.

This vision is finally starting to come to fruition with projects like Gitpod and GitHub Codespaces being used in real production codebases, and as the case with Gitpod, free and accessible to anyone in the world today.

In this post, I want to show you how you can move your development environment to the cloud with Gitpod.

Gitpod Overview

Gitpod lets you automate the deployment of Github projects and start coding them directly in any browser with a complete VSCode setup.

You can spin up pre-configured, standardized dev environments from any git context when you need them and close them down (and forget about them) when you are done with your task. Dev environments become fully ephemeral.

The value proposition is this: I have a project that I want to work on, or see a project in a Github repo I want to try out. With Gitpod, you can click a button, or append the GitHub repo with gitpod.io/# and open it up in Gitpod.

Gitpod will read the Gitpod configuration file and run the steps to automatically set everything up for you. From there, you can immediately start writing code, running additional CLI commands, and testing your project (including running web servers for front end applications).

A couple of examples of some automations:

Blockchain app

Install the dependencies
Start local Ethereum node
Compile smart contract
Deploy the smart contract
Start the web server

Docker with a RUST API

Set environment variables
Start Postgres
Build the project - cargo build
Run the project - cargo run

Jamstack app

Install dependencies
Start the web server

Let's look at how we can get started automating these types of projects.

Getting started

There are two examples I'm going to give here:

Deploying and automating your own project to Gitpod
Deploying an existing project to Gitpod

Deploying and automating your own project

First, create a new Next.js app and create a .gitpod.yml file:

npx create-next-app myapp

cd myapp

touch .gitpod.yml

Update .gitpod.yml with the following code:

tasks:
  - name: Install and deploy
    init: yarn
    command: npm run dev

This configuration will do the following once the project is launched in Gitpod:

Install dependencies
Run the dev server after dependencies are installed and open port 3000

You can do quite a bit in the configurations, including async tasks. To learn more about what's possible, check out the docs here

Next, create a new GitHub repo and copy the project URI to your clipboard.

Using your own GitHub project URI, push your project to GitHub:

git init

git remote add origin git@github.com:username/myapp.git

git add .

git commit -m 'initial commit'

git push origin main

Now you can open your project and it will automatically be deployed and run whenever someone opens it with this URL pattern:

https://gitpod.io/#<your-project-uri>

Deploying an existing project to Gitpod

GitPod also has a handful of example projects that you can run and deploy as well here.

If you want to deploy this example Next.js app, check out my repo here

Next steps

If you want to learn more:

Check out the Getting Started guide
Follow Pauline and Mike on Twitter
Check out their YouTube channel
Here are a couple of video overviews of how it works:
- Ethereum Development Environment
- Next.js & Vercel

10 Minute Tutorial - Full Stack GitHub Authentication with Supabase & React

Nader Dabit — Wed, 22 Sep 2021 15:04:13 +0000

In this post I want to show how quickly and easily GitHub authentication can be enabled with Supabase and React, a full stack project in around 50 lines of code.

The video for this tutorial is available here

As I've mentioned before, one of the reasons I like Supabase is the wide variety of authentication providers it give you out of the box.

Also, the APIs for interacting with them are about as simple as it gets:

/* authenticate */
const { user, session, error } = await supabase.auth.signIn({
  provider: 'github'
});

/* request signed in user */
const user = supabase.auth.user()

As a developer, GitHub authentication is something you'll probably want to offer for any developer-facing product or service you create. Let's look at how we can set this up in just a few minutes and not much code with Supabase and React.

You can view all of the Supabase Authentication guides here at any time.

Creating the Supabase project

To get started, visit app.supabase.io and create a new project.

Once you've created your project, click on Settings in the left hand menu, then click API. Here, copy the project URL to your clipboard and then move on to the next step.

Creating the GitHub app

Next we need to create the GitHub OAuth application. To do so, click here and then click "Register a new Application".

Here, we can give the app a name, homepage url (http://localhost:3000 for now), and for the callback, use the Supabase app URL copied to your clipboard, appended with /auth/v1/callback:

https://<project-id>.supabase.co/auth/v1/callback

Once you create the OAuth App, you should be given both a Client ID as well as a way to create a new client secret.

Create the client secret then move on to the next step.

Configuring the OAuth settings in Supabase

In the Supabase dashboard, click on Authentication in the left hand menu, then Settings and toggle the Github enabled switch. Here you should be able to configure your GitHub client ID as well as the GitHub secret:

Your Supabase project is now ready to be used in your front end app!

Building the front end

Now that the Supabase project is ready to go, let's create the front end.

We'll be using React, but these ideas can be applied using any front end framework without a ton of fundamental changes.

First, create a new React project and change into the new directory:

npx create-react-app my-supabase-app

cd my-supabase-app

Next, install the Supabase JS library using either NPM or Yarn:

npm install @supabase/supabase-js

Next, we need to configure the Supabase project in our client application.

To do so, it's nice to have a separate configuration file that we we can import and use anywhere in our app. Create a new file in the src directory named client.js.

Here, we'll need the Supabase App URL as well as the anon public API Key from your project.

You can get these values from your Supabase project by clicking on Settings and then API:

Using these values, create and export your Supabase client configuration:

/* src/client.js */
import { createClient } from '@supabase/supabase-js'

const supabase = createClient('https://appid.supabase.co', 'anon-public-key')

export {
  supabase
}

Now we can start interacting with our Supabase app by importing this client!

Next, update src/App.js with the following code:

import './App.css';
import { useState, useEffect } from 'react';

import { supabase } from './client';

function App() {
  const [user, setUser] = useState(null);
  useEffect(() => {
    /* when the app loads, check to see if the user is signed in */
    checkUser();
    /* check user on OAuth redirect */
    window.addEventListener('hashchange', function() {
      checkUser();
    });
  }, [])
  async function checkUser() {
    /* if a user is signed in, update local state */
    const user = supabase.auth.user();
    setUser(user);
  }
  async function signInWithGithub() {
    /* authenticate with GitHub */
    await supabase.auth.signIn({
      provider: 'github'
    });
  }
  async function signOut() {
    /* sign the user out */
    await supabase.auth.signOut();
    setUser(null);
  }
  if (user) {
    return (
      <div className="App">
        <h1>Hello, {user.email}</h1>
        <button onClick={signOut}>Sign out</button>
      </div>
    )
  }
  return (
    <div className="App">
      <h1>Hello, please sign in!</h1>
      <button onClick={signInWithGithub}>Sign In</button>
    </div>
  );
}

export default App;

Now, we should be able to run the app and have a basic authentication flow set up for us:

npm start

Next steps

Right now we do not have a way to query for the users of our application.

We can set this up pretty easily by following this guide to create a profiles table referencing id in the auth.users table using a user_id field, and then setting row level access rules for reading and writing.

The Complete Guide to Full Stack Solana Development with React, Anchor, Rust, and Phantom

Nader Dabit — Wed, 15 Sep 2021 19:38:30 +0000

Building Full Stack dapps with React, Solana, Anchor, and Phantom wallet.

In The Complete Guide to Full Stack Ethereum Development I did a deep dive into how to build a full stack dapp on Ethereum, which can also be applied to other EVM compatible chains like Polygon, Avalanche, and Ethereum Layer 2's like Arbitrum.

In this guide, I want to dive into Solana to show you how to build a full stack dapp. I also want to introduce the the ecosystem and the developer tooling to you to hopefully help you get up and running building your own ideas and applications going forward.

The code for the project is located here

Solana developer overview

As someone who just started learning Solidity and its ecosystem about 6 months ago, I kind of assumed it couldn't be that much harder to get up and running with. I was wrong.

Parts of the developer tooling are really nice and polished (the Solana CLI and Anchor), while the rest of the ecosystem, and even the documentation for Anchor (which to be fair, is very new), leaves a decent amount to be desired.

That being said, once you get the hang of everything it quickly becomes much easier to understand how to start implementing your own ideas and begin experimenting.

One of the keys to finding answers is to be vigilant about searching across all of Google, Github, and especially the various Discord servers for Anchor and Solana. The developers in those channels have been extremely helpful, especially Armani Ferrante who created the Anchor framework. Get familiar with the search feature, you can often find answers to your questions in past discussions in Discord.

Project overview

The tooling we'll be using today includes:

Solana Tool Suite - This includes a really polished and well documented CLI for interacting with the Solana network.

Anchor Framework - Anchor is actually a life saver for me, and I'm almost certain I would not have been able to get over the hump of building anything without it. It is the Hardhat of Solana development and more, and I love it. It also offers a DSL on top of Rust so that you do not need a deep understanding of the language to get started, though I am still trying to learn Rust as it will probably be useful to build anything non-trivial, even with the DSL. A good free place to learn Rust is The Rust Book.

solana/web3.js - A Solana version of web3.js that seems to work pretty well, but the documentation was almost unusable for me

React - The client-side framework

I will leave off all of the in depth details around how Solana itself works, as other people can cover this better than me. Instead I'll try to just focus on building something and sharing the details that you need to be know to accomplish this, along with things I think are of utmost importance.

If you want to learn more about Solana and how it works, here are a few good pieces:

In this guide we'll focus mainly on project setup, testing, and front end client integration for building out a couple of types of applications, mainly focused on CRUD operations (without the delete of course), which I found to be somewhat undocumented (integration with client applications).

We'll also learn how to airdrop tokens to our own development accounts using the Solana CLI, and deploy our apps to both a local network as well as a live test network.

We won't be focusing on NFTs in this guide, but maybe I will focus on doing that in a future guide. For now, if you're interested in building an NFT marketplace on Solana, I recommend checking out Metaplex.

Prerequisites

This tutorial covers how to build a full stack app on Solana, but does not go into how to install all of the individual dependencies.

Instead, I will list the dependencies and link to the documentation for how to install them, as each project will be able to explain and document these things better than I ever could, as well as keep them up to date.

Node.js - I recommend installing Node using either nvm or fnm
Solana Tool Suite - You can see the installation instructions here. note - If you have any issues installing Solana on an M1 Mac, try building from source and check out this guide.
Anchor (including the Mocha installation) - Anchor installation was pretty straight-forward for me. You can find the installation instructions here.
Solana browser wallet - I recommend Phantom, which is what I have tested this app with.

Getting Started

Before we get started building, let's take a look at the Solana CLI.

Solana CLI

The main things we'll be doing with the Solana CLI will be configuring our network (between localhost and a developer testnet) as well as airdropping tokens into our wallets, pretty much everything else we'll be doing with the Anchor CLI.

For instance, we can check the current network (and other) configuration with this command:



solana config get

# output
Config File: /Users/user/.config/solana/cli/config.yml
RPC URL: https://api.devnet.solana.com
WebSocket URL: wss://api.devnet.solana.com/ (computed)
Keypair Path: /Users/user/.config/solana/id.json
Commitment: confirmed

If you do not have a Keypair path, set one up by following the instructions here

We can change the network like so:



# set to localhost
solana config set --url localhost

# set to devnet
solana config set --url devnet

This is important as you will need to be aware of which network you are using as you're building, testing, and deploying your programs. You also need to be sure your wallet is using the same network that your local environment is using when testing, something I'll cover.

We'll be starting by developing on a localhost network, then switching to the devnet network.

We can also use the CLI to see our current local wallet address:



solana address

And then get the full details about an account:



solana account <address from above>

Next let's airdrop some tokens. To do so, first switch to the local network, as this is where we will be working to start off with:



solana config set --url localhost

Next, start the local network. This is going to be a local Solana node that we can deploy to for testing:



solana-test-validator

Once the local network is running, you can airdrop tokens to your account. With the network running, open a separate window and run the following command:



solana airdrop 100

You can the check the balance of your wallet:



solana balance

# or

solana balance <address>

You should now have a balance 100 SOL in your wallet. With that, we can get started building.

Let's start building

To get started, initialize a new anchor project and change into the new directory:



anchor init mysolanaapp --javascript

cd mysolanaapp

Be sure to use Anchor version 0.16.0 or later.

In this project, you'll see four main folders (in addition to the node_modules):

app - Where our frontend code will go

programs - This is where the Rust code lives for the Solana program

test - Where the JavaScript tests for the program live

migrations - A basic deploy script

Let's take a look at the program that was created for us.

Anchor uses, and enables us to write, an eDSL (embedded DSL) that abstracts away many of the more complex low level operations you'd typically need to do if you were using Solana & Rust without it, making it more approachable for me.



// programs/src/lib.rs
use anchor_lang::prelude::*;

declare_id!("Fg6PaFpoGXkYsidMpWTK6W2BeZ7FEfcYkg476zPFsLnS");

#[program]
pub mod mysolanaapp {
    use super::*;
    pub fn initialize(ctx: Context<Initialize>) -> ProgramResult {
        Ok(())
    }
}

#[derive(Accounts)]
pub struct Initialize {}

This is probably the most basic program you can write. The only thing happening here is we are defining a function called initialize, which when invoked just exits the program successfully. There is no data manipulation at all.

The Initialize struct defines the context as being empty of any arguments. We'll learn more about the function context later.

To compile this program, we can run the Anchor build command:



anchor build

Once a build is completed, you should see a new folder named target.

One of the artifacts created is an IDL located at target/idl/mysolanaapp.json.

IDLs are very similar to an ABI in Solidity (or a query definition in GraphQL), and we will be using them in a similar way in our JavaScript tests and frontends to communicate with our Solana program via RPC.

We can also test out our program. If you open tests/mysolanaapp.js, you will see that there is a test written in JavaScript that allows us to test out the program.

The test should look like this:



const anchor = require('@project-serum/anchor');

describe('mysolanaapp', () => {
  // Configure the client to use the local cluster.
  anchor.setProvider(anchor.Provider.env());

  it('Is initialized!', async () => {
    const program = anchor.workspace.Mysolanaapp;
    const tx = await program.rpc.initialize();
    console.log("Your transaction signature", tx);
  });
});

There are a couple of things to learn from this test that are important and we'll be using in the future, both in our tests as well as in the front end JavaScript clients.

To call a Solana program using Anchor, we typically need two main things:

1. Provider - The Provider is an abstraction of a connection to the Solana network, typically consisting of a Connection, Wallet, and a preflight commitment.

In the test, the Anchor framework will create the provider for us based on the environment (anchor.Provider.env()), but on the client we will need to construct the Provider ourselves using the user's Solana wallet.

2. program - The program is an abstraction that combines the Provider, idl, and the programID (which is generated when the program is built) and allows us to call RPC methods against our program.

Again, like with the Provider, Anchor offers a convenient way to access the program, but when building out the front end we'll need to construct this provider ourselves.

Once we have these two things, we can start calling functions in our program. For example, in our program we have an initialize function. In our test, you'll see we can invoke that function directly using program.rpc.functionName:



const tx = await program.rpc.initialize();

This is a very common pattern that you'll use a lot when working with Anchor, and once you get the hang of understanding how it works, makes it really easy to connect to and interact with a Solana program.

We can now test the program by running the test script:



anchor test

Building Hello World

Now that we have our project setup, let's create something a little more interesting.

I know that, as a full stack developer, most of the time I'm wondering how to do CRUD types of operations, so that's what we'll look at next.

The first program we'll create will allow us to create a counter that increments every time we call it from a client application.

The first thing we need to do is open programs/mysolanaapp/src/lib.rs and update it with the following code:



use anchor_lang::prelude::*;

declare_id!("Fg6PaFpoGXkYsidMpWTK6W2BeZ7FEfcYkg476zPFsLnS");

#[program]
mod mysolanaapp {
    use super::*;

    pub fn create(ctx: Context<Create>) -> ProgramResult {
        let base_account = &mut ctx.accounts.base_account;
        base_account.count = 0;
        Ok(())
    }

    pub fn increment(ctx: Context<Increment>) -> ProgramResult {
        let base_account = &mut ctx.accounts.base_account;
        base_account.count += 1;
        Ok(())
    }
}

// Transaction instructions
#[derive(Accounts)]
pub struct Create<'info> {
    #[account(init, payer = user, space = 16 + 16)]
    pub base_account: Account<'info, BaseAccount>,
    #[account(mut)]
    pub user: Signer<'info>,
    pub system_program: Program <'info, System>,
}

// Transaction instructions
#[derive(Accounts)]
pub struct Increment<'info> {
    #[account(mut)]
    pub base_account: Account<'info, BaseAccount>,
}

// An account that goes inside a transaction instruction
#[account]
pub struct BaseAccount {
    pub count: u64,
}

In this program we have two functions - create and increment. These two functions are the RPC request handlers that we will be able to call from a client application to interact with the program.

The first parameter of an RPC handler is the Context struct, which describes the context that will be passed in when the function is called and how to handle it. In the case of Create, we are expecting three parameters: base_account, user, and system_program.

The #[account(...)] attributes define constraints and instructions that are related to the proceeding account where declared. If any of these constraints do not hold, then the instruction will never execute.

Any client calling this program with the proper base_account can call these RPC methods.

The way that Solana deals with data is much different than anything I've ever worked with. There is no persisted state within the program, everything is attached to what are known as accounts. An account essentially holds all of the state of a program. Because of this, all data is passed by reference from the outside.

There are also no read operations. This is because all you need to do to read the contents of a program is to request the account, from there you are able to view all of the program's state. To read more about how accounts work, check out this post.

To build the program:



anchor build

Next, let's write a test that uses this counter program. To do so, open tests/mysolanaapp.js and update with the following code:



const assert = require("assert");
const anchor = require("@project-serum/anchor");
const { SystemProgram } = anchor.web3;

describe("mysolanaapp", () => {
  /* create and set a Provider */
  const provider = anchor.Provider.env();
  anchor.setProvider(provider);
  const program = anchor.workspace.Mysolanaapp;
  it("Creates a counter)", async () => {
    /* Call the create function via RPC */
    const baseAccount = anchor.web3.Keypair.generate();
    await program.rpc.create({
      accounts: {
        baseAccount: baseAccount.publicKey,
        user: provider.wallet.publicKey,
        systemProgram: SystemProgram.programId,
      },
      signers: [baseAccount],
    });

    /* Fetch the account and check the value of count */
    const account = await program.account.baseAccount.fetch(baseAccount.publicKey);
    console.log('Count 0: ', account.count.toString())
    assert.ok(account.count.toString() == 0);
    _baseAccount = baseAccount;

  });

  it("Increments the counter", async () => {
    const baseAccount = _baseAccount;

    await program.rpc.increment({
      accounts: {
        baseAccount: baseAccount.publicKey,
      },
    });

    const account = await program.account.baseAccount.fetch(baseAccount.publicKey);
    console.log('Count 1: ', account.count.toString())
    assert.ok(account.count.toString() == 1);
  });
});

Before we continue to test and deploy the program, we want to get the dynamically generated Program ID that was generated by the build. We need this ID to use in the Rust program to replace the placeholder ID we set up when we created the project. To get this ID, we can run the following command:



solana address -k target/deploy/mysolanaapp-keypair.json

We can now update the program IDs in lib.rs:



// mysolanaapp/src/lib.rs

declare_id!("your-program-id");

And in Anchor.toml:



# Anchor.toml
[programs.localnet]
mysolanaapp = "your-program-id"

Next, run the test:



anchor test

Once the test passes, we can now deploy.

We can now deploy the program. Be sure that solana-test-validator is running:



anchor deploy

You can also view the validator logging by opening a separate window and running solana logs

Now we're ready to build out the front end.

Building the React app

In the root of the Anchor project, create a new react app to overwrite the existing app directory:



npx create-react-app app

Next, install the dependencies we'll need for Anchor and Solana Web3:



cd app

npm install @project-serum/anchor @solana/web3.js

We'll also be using Solana Wallet Adapter to handle connecting the user's Solana wallet. Let's install those dependencies as well:



npm install @solana/wallet-adapter-react \
@solana/wallet-adapter-react-ui @solana/wallet-adapter-wallets \
@solana/wallet-adapter-base

Next, in the src directory, create a new file named idl.json. Here, copy the IDL JSON that was created for you in the main project folder, located at target/idl/mysolanaapp.json.

It would be nice if we could copy this idl file automatically to our client application src folder, but as of now I have not found a way to do this natively. You can of course create your own script that does this if you'd like, or else you need to copy and paste over the IDL after every change to your main program.

If you want a script like this, you can do it in just a couple of lines of code:



// copyIdl.js
const fs = require('fs');
const idl = require('./target/idl/mysolanaapp.json');

fs.writeFileSync('./app/src/idl.json', JSON.stringify(idl));

Next, open app/src/App.js and update it with the following:



import './App.css';
import { useState } from 'react';
import { Connection, PublicKey } from '@solana/web3.js';
import {
  Program, Provider, web3
} from '@project-serum/anchor';
import idl from './idl.json';

import { PhantomWalletAdapter } from '@solana/wallet-adapter-wallets';
import { useWallet, WalletProvider, ConnectionProvider } from '@solana/wallet-adapter-react';
import { WalletModalProvider, WalletMultiButton } from '@solana/wallet-adapter-react-ui';
require('@solana/wallet-adapter-react-ui/styles.css');

const wallets = [
  /* view list of available wallets at https://github.com/solana-labs/wallet-adapter#wallets */
  new PhantomWalletAdapter()
]

const { SystemProgram, Keypair } = web3;
/* create an account  */
const baseAccount = Keypair.generate();
const opts = {
  preflightCommitment: "processed"
}
const programID = new PublicKey(idl.metadata.address);

function App() {
  const [value, setValue] = useState(null);
  const wallet = useWallet();

  async function getProvider() {
    /* create the provider and return it to the caller */
    /* network set to local network for now */
    const network = "http://127.0.0.1:8899";
    const connection = new Connection(network, opts.preflightCommitment);

    const provider = new Provider(
      connection, wallet, opts.preflightCommitment,
    );
    return provider;
  }

  async function createCounter() {    
    const provider = await getProvider()
    /* create the program interface combining the idl, program ID, and provider */
    const program = new Program(idl, programID, provider);
    try {
      /* interact with the program via rpc */
      await program.rpc.create({
        accounts: {
          baseAccount: baseAccount.publicKey,
          user: provider.wallet.publicKey,
          systemProgram: SystemProgram.programId,
        },
        signers: [baseAccount]
      });

      const account = await program.account.baseAccount.fetch(baseAccount.publicKey);
      console.log('account: ', account);
      setValue(account.count.toString());
    } catch (err) {
      console.log("Transaction error: ", err);
    }
  }

  async function increment() {
    const provider = await getProvider();
    const program = new Program(idl, programID, provider);
    await program.rpc.increment({
      accounts: {
        baseAccount: baseAccount.publicKey
      }
    });

    const account = await program.account.baseAccount.fetch(baseAccount.publicKey);
    console.log('account: ', account);
    setValue(account.count.toString());
  }

  if (!wallet.connected) {
    /* If the user's wallet is not connected, display connect wallet button. */
    return (
      <div style={{ display: 'flex', justifyContent: 'center', marginTop:'100px' }}>
        <WalletMultiButton />
      </div>
    )
  } else {
    return (
      <div className="App">
        <div>
          {
            !value && (<button onClick={createCounter}>Create counter</button>)
          }
          {
            value && <button onClick={increment}>Increment counter</button>
          }

          {
            value && value >= Number(0) ? (
              <h2>{value}</h2>
            ) : (
              <h3>Please create the counter.</h3>
            )
          }
        </div>
      </div>
    );
  }
}

/* wallet configuration as specified here: https://github.com/solana-labs/wallet-adapter#setup */
const AppWithProvider = () => (
  <ConnectionProvider endpoint="http://127.0.0.1:8899">
    <WalletProvider wallets={wallets} autoConnect>
      <WalletModalProvider>
        <App />
      </WalletModalProvider>
    </WalletProvider>
  </ConnectionProvider>
)

export default AppWithProvider;

Switching your wallet network

Before we can interact with a program on the localhost network, we must switch our Phantom wallet to the proper network.

To do so, open your Phantom wallet and click the settings button. Then scroll down to Change Network:

Next, choose Localhost:

Now we need to airdrop tokens to this wallet. At the top of the wallet interface, click on your address to copy it to your clipboard.

Next, open your terminal and run this command (be sure solana-test-validator is running):



solana airdrop 10 <address>

You should now have 10 tokens in your wallet. Now, we can run and test the app!

Change into the app directory and run the following command:



npm start

You should be able to connect your wallet, create a counter, and increment it.

You'll notice that when you refresh, you lose the state of the program. This is because we are dynamically generating the base account when the program loads. If you wanted to read and interact with the program data across various clients, you would need to create and store the Keypair somewhere in your project. I've put together a gist of a naive approach of how this might look.

Hello World part 2

Let's create a variation of this program that, instead of dealing with a counter, allows us to create a message and keep track of all of the previously created messages.

To do so, let's update our Rust program to look like this:



/* programs/mysolanaapp/src/lib.rs */
use anchor_lang::prelude::*;

declare_id!("your-program-id");

#[program]
mod mysolanaapp {
    use super::*;

    pub fn initialize(ctx: Context<Initialize>, data: String) -> ProgramResult {
        let base_account = &mut ctx.accounts.base_account;
        let copy = data.clone();
        base_account.data = data;
        base_account.data_list.push(copy);
        Ok(())
    }

    pub fn update(ctx: Context<Update>, data: String) -> ProgramResult {
        let base_account = &mut ctx.accounts.base_account;
        let copy = data.clone();
        base_account.data = data;
        base_account.data_list.push(copy);
        Ok(())
    }
}

#[derive(Accounts)]
pub struct Initialize<'info> {
    #[account(init, payer = user, space = 64 + 64)]
    pub base_account: Account<'info, BaseAccount>,
    #[account(mut)]
    pub user: Signer<'info>,
    pub system_program: Program<'info, System>,
}

#[derive(Accounts)]
pub struct Update<'info> {
    #[account(mut)]
    pub base_account: Account<'info, BaseAccount>,
}

#[account]
pub struct BaseAccount {
    pub data: String,
    pub data_list: Vec<String>,
}

In this program we have two main pieces of data we're keeping track of, a String named data and a Vector that holds a list of all data ever added to the program named data_list.

You'll notice that the memory allocation here is higher (128 + 128) than the previous program in order to account for the Vector. I don't know how many updates you'd be able to store in this program as is, but may be something to investigate more or experiment with, as this example in and of itself is experimental and just to give you an understanding of how things work.

Next, we can update the test for this new program:



const assert = require("assert");
const anchor = require("@project-serum/anchor");
const { SystemProgram } = anchor.web3;

describe("Mysolanaapp", () => {
  const provider = anchor.Provider.env();
  anchor.setProvider(provider);
  const program = anchor.workspace.Mysolanaapp;
  it("It initializes the account", async () => {
    const baseAccount = anchor.web3.Keypair.generate();
    await program.rpc.initialize("Hello World", {
      accounts: {
        baseAccount: baseAccount.publicKey,
        user: provider.wallet.publicKey,
        systemProgram: SystemProgram.programId,
      },
      signers: [baseAccount],
    });

    const account = await program.account.baseAccount.fetch(baseAccount.publicKey);
    console.log('Data: ', account.data);
    assert.ok(account.data === "Hello World");
    _baseAccount = baseAccount;

  });

  it("Updates a previously created account", async () => {
    const baseAccount = _baseAccount;

    await program.rpc.update("Some new data", {
      accounts: {
        baseAccount: baseAccount.publicKey,
      },
    });

    const account = await program.account.baseAccount.fetch(baseAccount.publicKey);
    console.log('Updated data: ', account.data)
    assert.ok(account.data === "Some new data");
    console.log('all account data:', account)
    console.log('All data: ', account.dataList);
    assert.ok(account.dataList.length === 2);
  });
});

To test it out:



anchor test

If the test fails, try turning off the validator and then running again.

Next, let's update the client.



/* app/src/App.js */
import './App.css';
import { useState } from 'react';
import { Connection, PublicKey } from '@solana/web3.js';
import { Program, Provider, web3 } from '@project-serum/anchor';
import idl from './idl.json';

import { PhantomWalletAdapter } from '@solana/wallet-adapter-wallets';
import { useWallet, WalletProvider, ConnectionProvider } from '@solana/wallet-adapter-react';
import { WalletModalProvider, WalletMultiButton } from '@solana/wallet-adapter-react-ui';
require('@solana/wallet-adapter-react-ui/styles.css');

const wallets = [ new PhantomWalletAdapter() ]

const { SystemProgram, Keypair } = web3;
const baseAccount = Keypair.generate();
const opts = {
  preflightCommitment: "processed"
}
const programID = new PublicKey(idl.metadata.address);

function App() {
  const [value, setValue] = useState('');
  const [dataList, setDataList] = useState([]);
  const [input, setInput] = useState('');
  const wallet = useWallet()

  async function getProvider() {
    /* create the provider and return it to the caller */
    /* network set to local network for now */
    const network = "http://127.0.0.1:8899";
    const connection = new Connection(network, opts.preflightCommitment);

    const provider = new Provider(
      connection, wallet, opts.preflightCommitment,
    );
    return provider;
  }

  async function initialize() {    
    const provider = await getProvider();
    /* create the program interface combining the idl, program ID, and provider */
    const program = new Program(idl, programID, provider);
    try {
      /* interact with the program via rpc */
      await program.rpc.initialize("Hello World", {
        accounts: {
          baseAccount: baseAccount.publicKey,
          user: provider.wallet.publicKey,
          systemProgram: SystemProgram.programId,
        },
        signers: [baseAccount]
      });

      const account = await program.account.baseAccount.fetch(baseAccount.publicKey);
      console.log('account: ', account);
      setValue(account.data.toString());
      setDataList(account.dataList);
    } catch (err) {
      console.log("Transaction error: ", err);
    }
  }

  async function update() {
    if (!input) return
    const provider = await getProvider();
    const program = new Program(idl, programID, provider);
    await program.rpc.update(input, {
      accounts: {
        baseAccount: baseAccount.publicKey
      }
    });

    const account = await program.account.baseAccount.fetch(baseAccount.publicKey);
    console.log('account: ', account);
    setValue(account.data.toString());
    setDataList(account.dataList);
    setInput('');
  }

  if (!wallet.connected) {
    return (
      <div style={{ display: 'flex', justifyContent: 'center', marginTop:'100px' }}>
        <WalletMultiButton />
      </div>
    )
  } else {
    return (
      <div className="App">
        <div>
          {
            !value && (<button onClick={initialize}>Initialize</button>)
          }

          {
            value ? (
              <div>
                <h2>Current value: {value}</h2>
                <input
                  placeholder="Add new data"
                  onChange={e => setInput(e.target.value)}
                  value={input}
                />
                <button onClick={update}>Add data</button>
              </div>
            ) : (
              <h3>Please Inialize.</h3>
            )
          }
          {
            dataList.map((d, i) => <h4 key={i}>{d}</h4>)
          }
        </div>
      </div>
    );
  }
}

const AppWithProvider = () => (
  <ConnectionProvider endpoint="http://127.0.0.1:8899">
    <WalletProvider wallets={wallets} autoConnect>
      <WalletModalProvider>
        <App />
      </WalletModalProvider>
    </WalletProvider>
  </ConnectionProvider>
)

export default AppWithProvider;

Next, build and deploy the program (be sure that solana-test-validator is running):



anchor build

anchor deploy

With the new build you'll have a new IDL that you'll need to update for your client. Either copy over the new IDL to app/src/idl.json or run your copyIdl.js script.

Testing it out

When testing out the new program, be sure to update the idl.json file that was created by the build.

Change into the app directory and run the start command:



npm start

Deploying to Devnet

Deploying to a live network is pretty straightforward from here. The main things we need to do are:

1. Update the Solana CLI to use devnet:



solana config set --url devnet

2. Update Phantom wallet to use devnet

3. Open Anchor.toml and update the cluster from localnet to devnet.

4. Rebuild the program. Be sure the program ID in Anchor.toml matches the current program ID.

5. Deploy the program again, this time it will be deployed to devnet

6. In app/src/App.js, we need to also update the network, this time using the clusterApiUrl from @solana/web3, like this:



/* before */
<ConnectionProvider endpoint="http://127.0.0.1:8899">

/* after */
import {
  ...,
  clusterApiUrl
} from '@solana/web3.js';

const network = clusterApiUrl('devnet');

<ConnectionProvider endpoint={network}>

From here, you should be able to deploy and test as we have done the the previous steps.

The code for this project is located here

Next steps

Another in depth tutorial I'd suggest checking out next is Create a Solana dApp from scratch which implements a simplified version of Twitter as a Solana dapp.

If you're interested in working with technology like this full time, come join me and my team at Edge & Node, we're hiring!

The New Creator Economy - DAOs, Community Ownership, and Cryptoeconomics

Nader Dabit — Thu, 26 Aug 2021 12:11:43 +0000

// Detect dark theme var iframe = document.getElementById('tweet-1428368687644364805-962'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1428368687644364805&theme=dark" }

Since I first had what I can only describe as a spiritual awakening about 10 years ago to the fact that technology would (figuratively) rule the world, I've been obsessed with wanting to understand how software works and how to build it.

Since that moment, my life has changed significantly for the better. I can only attribute it to the simple fact that I have relied not only on my own instincts, but of those of people much smarter and more experienced than me.

My hypothesis is this - try to find and follow the lead of those who have exhibited a long track record of success, find interests in their wake, and do my best to excel at them (while continuing to explore my own curiosities).

This approach has led me to try and master JavaScript, and then React, and finally to build a successful consultancy ultimately landing me on a team at AWS in a life changing experience that lasted a little over 3 years. All of this with no high school diploma or college degree.

During this time (like many developers) I've relentlessly dived into books, podcasts, blog posts, YouTube videos, and source code of every kind, but there has always been a topic that has captured my curiosity the most - futurism.

Futurists like Gerd Leonhard and Michio Kaku speak of a future, sometimes beautiful and sometimes bleak, but always with the passion and phrasing that make your thoughts wander and move past the current moment in time and into a mind boggling world that does not yet exist.

I recently had another "aha" moment, similar to my technological awakening, that has completely changed the direction of my career and my life. In the spirit of these futurists, I want to talk about why Web3 excites me just as much as their ideas, but is instead happening as we speak.

Web3

This post is meant to dive more into what I think are the benefits and repercussions of Web3. If you want to know my interpretation of what Web3 is, see my thoughts here.

Web3 represents a handful of ideas which together bring about entirely new mental models, organizational structures, and community incentives forcing us to rethink many things that we have become accustomed to.

All of the recent innovation happening is being made possible because of decentralized protocols.

The internet itself has thrived because of native internet protocols that we use everyday, like http, ftp, tcp, and ssh. One of the reasons these protocols have been so successful was that they were widely adopted and not subject to change. If I build a site using http, people can use it without any centralized intermediary - we can trust that it is going to work.

There were two major pieces of native functionality that have been left out up until recently - payments and state.

Blockchains have enabled both of these things, opening the door for programmable money and state without the need of a centralized server, bank, or any intermediary at all.

Ownership

One of the driving forces and the one that resonates with most people (and me) is that Web3 enables ownership.

Gaming

At some point the internet and gaming became almost indistinguishable. Not only because most games continue to receive updates over time, but the most popular ones are often the most interactive.

Fortnite took a lot of people by surprise because it created an innovative new combination of gameplay, peer-to-peer connection, and a unique business model - and everyone gets the game for free. The experience is very interactive, you can join old friends and make new ones, there are constant improvements and enhancements that just happen automatically - the game is consistently evolving.

The monetization strategy was also innovative. Fortnite allows players to buy in-game currency as well as skins that they can wear in the game. If you have a child you know that the $65 you may have spent on the game itself is probably peanuts compared to the amount of money kids spend over the lifetime of their gameplay.

The problem though is this: when the player decides to stop playing the game or outgrows it, where has all that money gone? More importantly, who is allowed as a creator to benefit from all of the purchasing power? The answer is, well, Fortnite (the platform).

What if, instead, players retained ownership of their items and were able to keep or sell them. Their items would maintain, increase, or decrease in value like any physical asset. These types of experiences and communities are now being made possible via NFTs. NFTs (and other digital tokens) enable scarcity in a world where there was in the past no scarcity.

Axie Infinity is an example of how this looks in practice. It is a blockchain-based game that is the most successful of it's kind, and has recently had explosive growth, catapulting it to over $1 billion in sales with over $780 million in the 30 days ending August 10 2021.

The best part about Axie is that, instead of 100% of the revenue going to the platform, they only keep 5%. This means that 95% of the revenue gets distributed directly back to the gamers.

Parallel is an online card game that has done over $100 million in sales and is still extremely early. Dark Forest enables players to get paid to play the game.

When players realize they can retain much of the value of their time and investments while still enjoying the benefit of the game, it not only changes the way they view gaming and where they spend their money, it aligns new incentives around the game itself. If the game succeeds, they can share in that success, therefore they become even more invested.

The combination of ownership, community, and creators who have built audiences creates a whirlwind of new and exciting opportunities that we are just starting to begin see explored throughout the Web3 world.

Ryan Watt, the head of YouTube gaming agrees.

// Detect dark theme var iframe = document.getElementById('tweet-1429108126234546182-497'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1429108126234546182&theme=dark" }

Mar Pincus, founder of Zynga, says "Play 2 earn and play 2 win is next evolution of freemium. Player owned and directed economies could change games and other industries forever. Cant wait!"

// Detect dark theme var iframe = document.getElementById('tweet-1444698585447104512-779'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1444698585447104512&theme=dark" }

EA has called blockchain games "the future of our industry."

// Detect dark theme var iframe = document.getElementById('tweet-1456039561403027462-582'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1456039561403027462&theme=dark" }

And web3 gaming is experiencing never-before seen levels of investment across the board.

// Detect dark theme var iframe = document.getElementById('tweet-1456616150775832586-79'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1456616150775832586&theme=dark" }

Social media and art

Social media platforms were revolutionary in that they allowed anyone from almost any background the ability to grow and foster large audiences using tools that were made free to anyone with a device and an internet connection. There are no gatekeepers to becoming famous on social media as there have been in the past in film and TV, the intermediary was abstracted away — peer to peer connections and direct content sharing was made possible.

The flaw in these implementations is that they offer a terrible monetization system, not just for the platform but for the creator as well. Advertising and the exploitation of user data is the go to play. Also almost all of the money generated by the platform, goes to the platform - the platform monetizes the content being created by its users in exchange of use of the platform itself. This is how social media works today.

In Web3, both creators and the community are able to gain and retain ownership within a platform, creating a synergy that, once experienced, makes the legacy interactions of the past seem archaic and undesirable. When I say ownership, I don't only mean ownership of content, but actual equity as well.

We are seeing the beginnings of this in the art world of Web3. Artists who were, in the past, often barely making it are now able to leverage their platforms, often in collaboration with other community members or causes, creating one of ones or collections of many. Foundation, Super Rare, and Zora enable digital artists to finally begin earning the type of incomes that their brothers and sisters in other parts of the tech sector have been enjoying for the past couple of decades, all enabled by blockchain technology and digital scarcity.

Art and code are also beginning to overlap.

MoonshotBots, launched by Austin Griffith and Kevin Owocki raised over $2 million to give to developers working on Open Source through Gitcoin grants.

Projects like Generative Masks allow talented creators like Takawo Shunsuke to leverage the skills he's acquired throughout his career to generate over $3 million in sales for his collection in just a few minutes, spreading awareness for himself and his cause, and creating another new community (of owners) simultaneously. The best part is that he's giving all of the money to the communities he's benefited from. On top of that, smart contracts allow him to programmatically enable a commission for any future sale that happens going forward, and in just a couple of weeks that amounts to another over $600,000.00.

// Detect dark theme var iframe = document.getElementById('tweet-1427807893458497544-661'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1427807893458497544&theme=dark" }

Generative art itself is an emerging category that combines code and creativity and is something that could alone warrant an entire post, but it suits the coming era particularly well as it enables artists to scale their creativity, community, and distribution.

There will continue to be a larger and larger percentage of digital artists because they can use powerful tools and programs to create art that can then be used in an infinite number of ways. They can then put it for sale on an international, 24 hour, liquid market.

Open Sea, the top online art marketplace today, has seen an absolute explosion in growth the past few months.

// Detect dark theme var iframe = document.getElementById('tweet-1429965382849343490-343'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1429965382849343490&theme=dark" }

Even recently surpassing Etsy in sales.

// Detect dark theme var iframe = document.getElementById('tweet-1427453596858294272-556'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1427453596858294272&theme=dark" }

Whether this type of volume continues, I have no idea. My guess is that there will be some volatility and fairly large swings both up and down. But there is definitely something there.

Another NFT platform, Super Rare, did a retroactive token drop to reward and provide equity to early supporters of their platform. 15% of the total supply of their token was given to artists and collectors who had already used the platform, amounting to anywhere between a few thousand to over a hundred thousand dollars per user.

Most of these NFT projects are launched on Ethereum. Ethereum is soon merging a new consensus mechanism that will make NFTs orders of magnitude more environmentally friendly as a means of sales and transfer of art than how we physically do today, which in the past all required ground transportation.

Future of social media

As it stands today, users of social media platforms can begin leveraging Web3 tools, communities, and platforms to begin monetizing their audience. I believe there will be a breakthrough app that will disrupt social media as we know it built in the in the next 1 - 3 years that blends all of these ideas together in a way that we haven't experienced yet.

Many people have echoed a similar sentiment. Aave, a very successful DeFi protocol built on Ethereum, has already begun work on a decentralized version of Twitter:

// Detect dark theme var iframe = document.getElementById('tweet-1416385933549654016-740'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1416385933549654016&theme=dark" }

Jack Dorsey of Twitter is also working on a Decentralized version of Twitter, though I believe that this type of application will ultimately come from the community or a DAO.

// Detect dark theme var iframe = document.getElementById('tweet-1427314482154414080-899'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1427314482154414080&theme=dark" }

Then there's Reddit, who's founder Alexis Ohanian is extremely bullish on web3:

// Detect dark theme var iframe = document.getElementById('tweet-1454943945633398787-144'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1454943945633398787&theme=dark" }

Reddit is moving into the space claiming to have a goal to "Decentralize social media"

// Detect dark theme var iframe = document.getElementById('tweet-1455950490366263301-941'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1455950490366263301&theme=dark" }

And of course there's the company previously known as Facebook who is unabashedly diving head first into the Metaverse, renaming their company to Meta, issuing their own token, and supporting NFTs.

DAOs, grants, community ownership, and social tokens

DAO stands for Decentralized Autonomous Organization. You can read about what a DAO is here, here, and here, but I want to focus on how DAOs will play a part in the new creator economy.

Shared ownership is a characteristic you'll see carried across all areas of Web3, including how we think about companies and incentive structures around how business is done.

In web2 companies, cash usually comes from large investors and there is no value returned to them for years. Ownership is largely concentrated in the first handful of employees along with their investors. Also, the average person has no chance of investing early in these companies. This funnels more money and more opportunity to the upper class, most connected, and most privileged among us and widening income disparities around the world.

These investments are also not liquid. It also usually takes years to reach a point where investors or employees with equity can begin to see any return on their investment and time spent, those revenues often through the old ways of advertising and exploitation of user data.

Web3 and blockchains bring about entirely new business models, made possible by tokenization and cryptoeconomic protocols.

In web3, communities and companies are built from the bottom up. Ownership can be created and issued to people in the form of tokens. Almost anyone can invest and participate in these communities and protocols much earlier on. Ownership is distributed much more evenly and fairly than in traditional companies. Developers and others can help build these communities, apps, and protocols in exchange for ownership. Unlike stock in startups which is not liquid, these tokens are indeed usually liquid.

DAOs enable communities to be owned by their participants. For example, developers often spend time helping answer questions in some company's Discord or on Stack Overflow. They might spend hours per month, taking time out of there day to do so. At the end of the day, the platform or company is benefitting and monetizing the value from that person, and they are not paid anything in return. In a DAO, community members hold ownership in the form of a token (usually either an NFT or an ERC20). The success of the community will determine the value of their stake, creating incentives for participants to make it successful, increasing the value they retain if the community continues to remain succesful.

There are quite literally countless ways that these tokens are being utilized to create new ways of collaboration and building, ranging from DAOs to web infrastructure to micro-economies:

Developer DAO which was created in September of 2021 already has over 3,000 members, a rapidly growing Twitter following, production projects, and investments to the tune of hundreds of thousands of dollars.
PartyDAO which created over $200,000 in revenue in its first day, was "built in 3 months by a small group of internet friends working part-time", and is backed by a smart contract
Compound, a decentralized finance protocol that allows you to lend and borrow cryptocurrency without trusting a third party with your funds with a market cap of over $2 billion as of this writing
Audius is a music streaming platform that enables them to create, grow, and directly monetize their fanbase directly without the need to sign a record deal or give all of the earnings to the platform like with apps like Spotify or Apple music. Investors include Nas, Pusha T, Katy Perry, and Jason Derulo.
Gitcoin is a platform that enables developers to get paid for working on open source projects
Graph Protocol is a decentralized web infrastructure protocol that allows developers to build APIs to enable the performant querying of blockchain data, all enabled by it's native utility token
Seed Club is a social token incubator that’s focused on helping creators launch and grow social tokens
Friends with Benefits is a social DAO and community that I'm part of that is 100% owned and governed by the participants recently valued at a market cap of around $250 million.
PleasrDAO allows investors to come together to purchase high-value non-fungible tokens like this piece from Edward Snowden

Most DAOs have desirable grants programs, enabling developers and other participants to work with various teams and projects at their will, on things they find interesting or that fit their skill set. There are more and more people beginning to work full time for grants and with DAOs vs traditional full time employment.

// Detect dark theme var iframe = document.getElementById('tweet-1418307358946701319-553'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1418307358946701319&theme=dark" }

Conclusion

If this sounds like something you're interested in being involved, I'd suggest to jump right in. Try P2E (play to earn), get involved with a DAO, or even mint your own NFT.

Also check out How to Get Into Ethereum | Crypto | Web3 as a Developer which is what I put together after getting my own start in the space.

If you want to learn more about these ideas, I encourage you to follow some of the people I mention in this post:

// Detect dark theme var iframe = document.getElementById('tweet-1430865775011803137-723'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1430865775011803137&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1430865775766740994-587'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1430865775766740994&theme=dark" }

Also, here are some of my favorite articles that touch on some of the stuff I've outlined here:

Thanks to Aditi for helping me with ideas and edits as I was getting this across the finish line 🙏

// Detect dark theme var iframe = document.getElementById('tweet-1430585405662011397-813'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1430585405662011397&theme=dark" }

Magic Link Authentication and Route Controls with Supabase and Next.js

Nader Dabit — Tue, 13 Jul 2021 13:15:36 +0000

View the video tutorial of this guide here. As a disclaimer, Supabase is also a sponsor of my YouTube channel

While Supabase is widely known for their real-time database and API layer, one of the things I like about it is the number of easy to set up authentication mechanisms it offers out of the box.

Magic Link

One of my favorites is Magic Link. You've probably used magic link in the past. Magic link sends a link to the user via email containing a link to authenticate with the service via a custom URL and access token.

When the user visits the URL, a session is set in their browser storage and the user is redirected back to the app, authenticating the user in the process.

This is becoming a very popular way to authenticate users as they do not have to keep up with another password, it provides a really great user experience.

Next.js

With Next.js, you have the ability to not only protect routes with client-side authorization, but for added security you can do server-side authorization and redirects in getServerSideProps if a cookie has been set and is available in the request context.

This is also where Supabase comes in handy. There is built-in functionality for setting and getting the cookie for the signed in user in SSR and API routes:

Setting the user in an API route

import { supabase } from '../../client'

export default function handler(req, res) {
  supabase.auth.api.setAuthCookie(req, res)
}

Getting the user in an SSR or API route

export async function getServerSideProps({ req }) {
  const { user } = await supabase.auth.api.getUserByCookie(req)

  if (!user) {
    return {
      props: {} 
    }
  }

  /* if user is present, do something with the user data here */
  return { props: { user } }
}

Server-side redirects are typically preferred over client-side redirects from an SEO perspective - it's harder for search engines to understand how client-side redirects should be treated.

You are also able to access the user profile from an API route using the getUserByCookie function, opening up an entirely new set of use cases and functionality.

With Next.js and Supabase you can easily implement a wide variety of applications using this combination of SSG, SSR, and client-side data fetching and user authorization, making the combination (and any framework that offers this combination of capabilities) extremely useful and powerful.

What we'll be building

In this post, we'll build out a Next.js app that enables navigation, authentication, authorization, redirects (client and server-side), and a profile view.

The project that we'll be building is a great starting point for any application that needs to deal with user identity, and is a good way to understand how user identity works and flows throughout all of the different places in a project using a modern hybrid framework like Next.js.

The final code for this project is located here

Building the app

To get started, you first need to create a Supabase account and project.

To do so, head over to Supabase.io and click Start Your Project. Authenticate with GitHub and then create a new project under the organization that is provided to you in your account.

Give the project a Name and Password and click Create new project.

It will take approximately 2 minutes for your project to be created.

Next, open your terminal and create a new Next.js app:

npx create-next-app supabase-next-auth

cd supabase-next-auth

The only dependency we'll need is the @supabase/supabase-js package:

npm install @supabase/supabase-js

Configuring the Supabase credentials

Now that the Next.js app is created, it needs a to know about the Supabase project in order to interact with it.

The best way to do this is using environment variables. Next.js allows environment variables to be set by creating a file called .env.local in the root of the project and storing them there.

In order to expose a variable to the browser you have to prefix the variable with NEXT_PUBLIC_.

Create a file called .env.local at the root of the project, and add the following configuration:

NEXT_PUBLIC_SUPABASE_URL=https://app-id.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=your-public-api-key

You can find the values of your API URL and API Key in the Supabase dashboard settings:

Creating the Supabase client

Now that the environment variables have been set, we can create a Supabase instance that can be imported whenever we need it.

Create a file named client.js in the root of the project with the following code:

/* client.js */
import { createClient } from '@supabase/supabase-js'

const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL,
  process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY
)

export { supabase }

Updating the index page

Next, let's update pages/index.js to be something more simple than what is provided out of the box. This is just meant to serve as a basic landing page

/* pages/index.js */
import styles from '../styles/Home.module.css'
export default function Home() {
  return (
    <div className={styles.container}>
      <main className={styles.main}>
        <h1 className={styles.title}>
          Hello World!
        </h1>
       </main>
    </div>
  )
}

Creating the sign in screen

Next, let's create the Sign In screen. This will serve a form input for the user to provide their email address.

When the user submits the form, they will receive a magic link to sign in. This will work for both new as well as existing users!

Create a new file in the pages directory named sign-in.js:

/* pages/sign-in.js */
import { useState } from 'react'
import styles from '../styles/Home.module.css'

import { supabase } from '../client'

export default function SignIn() {
  const [email, setEmail] = useState('')
  const [submitted, setSubmitted] = useState(false)
  async function signIn() {
    const { error, data } = await supabase.auth.signIn({
      email
    })
    if (error) {
      console.log({ error })
    } else {
      setSubmitted(true)
    }
  }
  if (submitted) {
    return (
      <div className={styles.container}>
        <h1>Please check your email to sign in</h1>
      </div>
    )
  }
  return (
    <div className={styles.container}>
      <main className={styles.main}>
        <h1 className={styles.title}>
          Sign In
        </h1>
        <input
          onChange={e => setEmail(e.target.value)}
          style={{ margin: 10 }}
        />
        <button onClick={() => signIn()}>Sign In</button>
       </main>
    </div>
  )
}

The main thing in this file is this line of code:

const { error, data } = await supabase.auth.signIn({
  email
})

By only providing the email address of the user, magic link authentication will happen automatically.

Profile view

Next, let's create the profile view. Create a new file in the pages directory named profile.js:

/* pages/profile.js */
import { useState, useEffect } from 'react';
import { supabase } from '../client'
import { useRouter } from 'next/router'

export default function Profile() {
  const [profile, setProfile] = useState(null)
  const router = useRouter()
  useEffect(() => {
    fetchProfile()
  }, [])
  async function fetchProfile() {
    const profileData = await supabase.auth.user()
    if (!profileData) {
      router.push('/sign-in')
    } else {
      setProfile(profileData)
    }
  }
  async function signOut() {
    await supabase.auth.signOut()
    router.push('/sign-in')
  }
  if (!profile) return null
  return (
    <div style={{ maxWidth: '420px', margin: '96px auto' }}>
      <h2>Hello, {profile.email}</h2>
      <p>User ID: {profile.id}</p>
      <button onClick={signOut}>Sign Out</button>
    </div>
  )
}

To check for the currently signed in user we call supabase.auth.user().

If the user is signed in, we set the user information using the setProfile function set up using the useState hook.

If the user is not signed in, we client-side redirect using the useRouter hook.

API Route

In pages/_app.js we'll be needing to call a function to set the cookie for retrieval later in the SSR route.

Let's go ahead and create that API route and function. This will be calling the setAuthCookie API given to us by the Supabase client.

Create a new file named auth.js in the pages/api folder and add the following code:

/* pages/api/auth.js */
import { supabase } from '../../client'

export default function handler(req, res) {
  supabase.auth.api.setAuthCookie(req, res)
}

Nav, auth listener, and setting the session cookie

The largest chunk of code we'll need to write will be in pages/app.js. Here are the things we need to implement here:

Navigation
A listener to fire when authentication state changes (provided by Supabase)
A function that will set the cookie with the user session

In addition to this, we'll also need to keep up with the authenticated state of the user. We do this so we can toggle links, showing or hiding certain links based on if the user is or isn't signed in.

We'll demonstrate this here by only showing the Sign In link to users who are not signed in, and hiding it when they are.

/* pages/_app.js */
import '../styles/globals.css'
import { useState, useEffect } from 'react'
import Link from 'next/link'
import { supabase } from '../client'
import { useRouter } from 'next/router'

function MyApp({ Component, pageProps }) {
  const router = useRouter()
  const [authenticatedState, setAuthenticatedState] = useState('not-authenticated')
  useEffect(() => {
    /* fires when a user signs in or out */
    const { data: authListener } = supabase.auth.onAuthStateChange((event, session) => {
      handleAuthChange(event, session)
      if (event === 'SIGNED_IN') {
        setAuthenticatedState('authenticated')
        router.push('/profile')
      }
      if (event === 'SIGNED_OUT') {
        setAuthenticatedState('not-authenticated')
      }
    })
    checkUser()
    return () => {
      authListener.unsubscribe()
    }
  }, [])
  async function checkUser() {
    /* when the component loads, checks user to show or hide Sign In link */
    const user = await supabase.auth.user()
    if (user) {
      setAuthenticatedState('authenticated')
    }
  }
  async function handleAuthChange(event, session) {
    /* sets and removes the Supabase cookie */
    await fetch('/api/auth', {
      method: 'POST',
      headers: new Headers({ 'Content-Type': 'application/json' }),
      credentials: 'same-origin',
      body: JSON.stringify({ event, session }),
    })
  }
  return (
    <div>
      <nav style={navStyle}>
        <Link href="/">
          <a style={linkStyle}>Home</a>
        </Link>
        <Link href="/profile">
          <a style={linkStyle}>Profile</a>
        </Link>
        {
          authenticatedState === 'not-authenticated' && (
            <Link href="/sign-in">
              <a style={linkStyle}>Sign In</a>
            </Link>
          )
        }
        <Link href="/protected">
          <a style={linkStyle}>Protected</a>
        </Link>
      </nav>
      <Component {...pageProps} />
    </div>
  )
}

const navStyle = {
  margin: 20
}
const linkStyle = {
  marginRight: 10
}

export default MyApp

The last page we need to implement is the route that will demonstrate server-side protection and redirects.

Since we have already implemented setting the cookie, we should now be able to read the cookie on the server if the user is signed in.

Like I mentioned previously, we can do this with the getUserByCookie function.

Create a new file in the pages directory named protected.js and add the following code:

import { supabase } from '../client'

export default function Protected({ user }) {
  console.log({ user })
  return (
    <div style={{ maxWidth: '420px', margin: '96px auto' }}>
      <h2>Hello from protected route</h2>
    </div>
  )
}

export async function getServerSideProps({ req }) {
  /* check to see if a user is set */
  const { user } = await supabase.auth.api.getUserByCookie(req)

  /* if no user is set, redirect to the sign-in page */
  if (!user) {
    return { props: {}, redirect: { destination: '/sign-in' } }
  }

  /* if a user is set, pass it to the page via props */
  return { props: { user } }
}

Testing it out

Now the app is built and we can test it out!

To run the app, open your terminal and run the following command:

npm run dev

When the app loads, you should be able to sign up, and sign in using the magic link. Once signed in, you should be able to view the profile page and see your user id as well as your email address.

Setting metadata and attributes

If you want to continue building out the user's profile, you can do so easily using the update method.

For example, let's say we wanted to allow the user's to set their location. We can do so with the following code:

const { user, error } = await supabase.auth.update({ 
  data: {
    city: "New York"
  } 
})

Now, when we fetch the user's data, we should be able to view their metadata:

The final code for this project is located here

How to Build a Full Stack NFT Marketplace - V2 (2022)

Nader Dabit — Tue, 06 Jul 2021 15:14:09 +0000

Building an NFT marketplace with Polygon, Next.js, Tailwind, Solidity, Hardhat, Ethers.js, and IPFS

To view the video course for this tutorial, click here. To view Version 1 of this tutorial, click here

In my last end to end Ethereum tutorial, The Complete Guide to Full Stack Ethereum Development I introduced how to build a basic app on Ethereum using modern tooling like Hardhat and Ethers.js.

In this guide you'll learn how to build, deploy, and test out a full stack NFT marketplace on Ethereum. We'll also look at how to deploy to Polygon.

One thing that has become apparent is how quickly Ethereum scaling solutions like Polygon, Arbitrum, and Optimism are gaining momentum and adoption. These technologies enable developers to build the same applications they would directly on Ethereum with the added benefits of lower gas costs and faster transaction speeds among other things.

Because of the value proposition that these solutions offer combined with the general lack of existing content, I will be building out various example projects and tutorials for full stack applications using these various Ethereum scaling solutions, starting with this one on Polygon.

To view the final source code for this project, visit this repo

Prerequisites

To be successful in this guide, you must have the following:

Node.js version 16.14.0 or greater installed on your machine. I recommend installing Node using either nvm or fnm.
Metamask wallet extension installed as a browser extension

The stack

In this guide, we will build out a full stack application using:

Web application framework - Next.js
Solidity development environment - Hardhat
File Storage - IPFS
Ethereum Web Client Library - Ethers.js

Though it will not be part of this guide (coming in a separate post), we will look at how to build a more robust API layer using The Graph Protocol to get around limitations in the data access patterns provided by the native blockchain layer.

About the project

The project that we will be building will be Metaverse Marketplace - an NFT marketplace.

When a user puts an NFT for sale, the ownership of the item will be transferred from the creator to the marketplace contract.

When a user purchases an NFT, the purchase price will be transferred from the buyer to the seller and the item will be transferred from the marketplace to the buyer.

The marketplace owner will be able to set a listing fee. This fee will be taken from the seller and transferred to the contract owner upon completion of any sale, enabling the owner of the marketplace to earn recurring revenue from any sale transacted in the marketplace.

The marketplace logic will consist of just one smart contract:

NFT Marketplace Contract - this contract allows users to mint NFTs and list them in a marketplace.

I believe this is a good project because the tools, techniques, and ideas we will be working with lay the foundation for many other types of applications on this stack – dealing with things like payments, commissions, and transfers of ownership on the contract level as well as how a client-side application would use this smart contract to build a performant and nice-looking user interface.

In addition to the smart contract, I'll also show you how to build a subgraph to make the querying of data from the smart contract more flexible and efficient. As you will see, creating views on data sets and enabling various and performant data access patterns is hard to do directly from a smart contract. The Graph makes this much easier.

About Polygon

From the docs:

"Polygon is a protocol and a framework for building and connecting Ethereum-compatible blockchain networks. Aggregating scalable solutions on Ethereum supporting a multi-chain Ethereum ecosystem."

Polygon is about 10x faster than Ethereum & yet transactions are more than 10x cheaper.

Ok cool, but what does all that mean?

To me it means that I can use the same knowledge, tools, and technologies I have been using to build apps on Ethereum to build apps that are faster and cheaper for users, providing not only a better user experience but also opening the door for many types of applications that just would not be feasible to be built directly on Ethereum.

As mentioned before, there are many other Ethereum scaling solutions such as Arbitrumand Optimism that are also in a similar space. Most of these scaling solutions have technical differences and fall into various categories like sidechains , layer 2s, and state channels.

Polygon recently rebranded from Matic so you will also see the word Matic used interchangeably when referring to various parts of their ecosystem because the name still is being used in various places, like their token and network names.

To learn more about Polygon, check out this post as well as their documentation here.

Now that we have an overview of the project and related technologies, let's start building!

Project setup

To get started, we'll create a new Next.js app. To do so, open your terminal. Create or change into a new empty directory and run the following command:



npx create-next-app nft-marketplace

Next, change into the new directory and install the dependencies using a package manager like npm, yarn, or pnpm:



cd nft-marketplace

npm install ethers hardhat @nomiclabs/hardhat-waffle \
ethereum-waffle chai @nomiclabs/hardhat-ethers \
web3modal @openzeppelin/contracts ipfs-http-client \
axios

Setting up Tailwind CSS

We'll be using Tailwind CSS for styling, we we will set that up in this step.

Tailwind is a utility-first CSS framework that makes it easy to add styling and create good looking websites without a lot of work.

Next, install the Tailwind dependencies:



npm install -D tailwindcss@latest postcss@latest autoprefixer@latest

Next, we will create the configuration files needed for Tailwind to work with Next.js (tailwind.config.js and postcss.config.js) by running the following command:



npx tailwindcss init -p

Next, configure your template content paths in tailwind.config.js:



/* tailwind.config.js */
module.exports = {
  content: [
    "./pages/**/*.{js,ts,jsx,tsx}",
    "./components/**/*.{js,ts,jsx,tsx}",
  ],
  theme: {
    extend: {},
  },
  plugins: [],
}

Finally, delete the code in styles/globals.css and update it with the following:



@tailwind base;
@tailwind components;
@tailwind utilities;

Configuring Hardhat

Next, initialize a new Hardhat development environment from the root of your project:



npx hardhat

? What do you want to do? Create a basic sample project
? Hardhat project root: <Choose default path>

If you get an error referencing your README.md, delete README.md and run npx hardhat again.

Now you should see the following files and folders created for you in your root directory:

hardhat.config.js - The entirety of your Hardhat setup (i.e. your config, plugins, and custom tasks) is contained in this file.
scripts - A folder containing a script named sample-script.js that will deploy your smart contract when executed
test - A folder containing an example testing script
contracts - A folder holding an example Solidity smart contract

Next, update the configuration at hardhat.config.js with the following:

View the gist here



/* hardhat.config.js */
require("@nomiclabs/hardhat-waffle")

module.exports = {
  defaultNetwork: "hardhat",
  networks: {
    hardhat: {
      chainId: 1337
    },
//  unused configuration commented out for now
//  mumbai: {
//    url: "https://rpc-mumbai.maticvigil.com",
//    accounts: [process.env.privateKey]
//  }
  },
  solidity: {
    version: "0.8.4",
    settings: {
      optimizer: {
        enabled: true,
        runs: 200
      }
    }
  }
}

In this configuration, we've configured the local Hardhat development environment as well as the Mumbai testnet (commented out for now).

You can read more about both Matic networks here.

Smart Contract

Next, we'll create our smart contract!

In this file I'll do my best to comment within the code everything that is going on.

Create a new file in the contracts directory named NFTMarketplace.sol. Here, add the following code:

View the gist here



// SPDX-License-Identifier: MIT
pragma solidity ^0.8.4;

import "@openzeppelin/contracts/utils/Counters.sol";
import "@openzeppelin/contracts/token/ERC721/extensions/ERC721URIStorage.sol";
import "@openzeppelin/contracts/token/ERC721/ERC721.sol";

import "hardhat/console.sol";

contract NFTMarketplace is ERC721URIStorage {
    using Counters for Counters.Counter;
    Counters.Counter private _tokenIds;
    Counters.Counter private _itemsSold;

    uint256 listingPrice = 0.025 ether;
    address payable owner;

    mapping(uint256 => MarketItem) private idToMarketItem;

    struct MarketItem {
      uint256 tokenId;
      address payable seller;
      address payable owner;
      uint256 price;
      bool sold;
    }

    event MarketItemCreated (
      uint256 indexed tokenId,
      address seller,
      address owner,
      uint256 price,
      bool sold
    );

    constructor() ERC721("Metaverse Tokens", "METT") {
      owner = payable(msg.sender);
    }

    /* Updates the listing price of the contract */
    function updateListingPrice(uint _listingPrice) public payable {
      require(owner == msg.sender, "Only marketplace owner can update listing price.");
      listingPrice = _listingPrice;
    }

    /* Returns the listing price of the contract */
    function getListingPrice() public view returns (uint256) {
      return listingPrice;
    }

    /* Mints a token and lists it in the marketplace */
    function createToken(string memory tokenURI, uint256 price) public payable returns (uint) {
      _tokenIds.increment();
      uint256 newTokenId = _tokenIds.current();

      _mint(msg.sender, newTokenId);
      _setTokenURI(newTokenId, tokenURI);
      createMarketItem(newTokenId, price);
      return newTokenId;
    }

    function createMarketItem(
      uint256 tokenId,
      uint256 price
    ) private {
      require(price > 0, "Price must be at least 1 wei");
      require(msg.value == listingPrice, "Price must be equal to listing price");

      idToMarketItem[tokenId] =  MarketItem(
        tokenId,
        payable(msg.sender),
        payable(address(this)),
        price,
        false
      );

      _transfer(msg.sender, address(this), tokenId);
      emit MarketItemCreated(
        tokenId,
        msg.sender,
        address(this),
        price,
        false
      );
    }

    /* allows someone to resell a token they have purchased */
    function resellToken(uint256 tokenId, uint256 price) public payable {
      require(idToMarketItem[tokenId].owner == msg.sender, "Only item owner can perform this operation");
      require(msg.value == listingPrice, "Price must be equal to listing price");
      idToMarketItem[tokenId].sold = false;
      idToMarketItem[tokenId].price = price;
      idToMarketItem[tokenId].seller = payable(msg.sender);
      idToMarketItem[tokenId].owner = payable(address(this));
      _itemsSold.decrement();

      _transfer(msg.sender, address(this), tokenId);
    }

    /* Creates the sale of a marketplace item */
    /* Transfers ownership of the item, as well as funds between parties */
    function createMarketSale(
      uint256 tokenId
      ) public payable {
      uint price = idToMarketItem[tokenId].price;
      address seller = idToMarketItem[tokenId].seller;
      require(msg.value == price, "Please submit the asking price in order to complete the purchase");
      idToMarketItem[tokenId].owner = payable(msg.sender);
      idToMarketItem[tokenId].sold = true;
      idToMarketItem[tokenId].seller = payable(address(0));
      _itemsSold.increment();
      _transfer(address(this), msg.sender, tokenId);
      payable(owner).transfer(listingPrice);
      payable(seller).transfer(msg.value);
    }

    /* Returns all unsold market items */
    function fetchMarketItems() public view returns (MarketItem[] memory) {
      uint itemCount = _tokenIds.current();
      uint unsoldItemCount = _tokenIds.current() - _itemsSold.current();
      uint currentIndex = 0;

      MarketItem[] memory items = new MarketItem[](unsoldItemCount);
      for (uint i = 0; i < itemCount; i++) {
        if (idToMarketItem[i + 1].owner == address(this)) {
          uint currentId = i + 1;
          MarketItem storage currentItem = idToMarketItem[currentId];
          items[currentIndex] = currentItem;
          currentIndex += 1;
        }
      }
      return items;
    }

    /* Returns only items that a user has purchased */
    function fetchMyNFTs() public view returns (MarketItem[] memory) {
      uint totalItemCount = _tokenIds.current();
      uint itemCount = 0;
      uint currentIndex = 0;

      for (uint i = 0; i < totalItemCount; i++) {
        if (idToMarketItem[i + 1].owner == msg.sender) {
          itemCount += 1;
        }
      }

      MarketItem[] memory items = new MarketItem[](itemCount);
      for (uint i = 0; i < totalItemCount; i++) {
        if (idToMarketItem[i + 1].owner == msg.sender) {
          uint currentId = i + 1;
          MarketItem storage currentItem = idToMarketItem[currentId];
          items[currentIndex] = currentItem;
          currentIndex += 1;
        }
      }
      return items;
    }

    /* Returns only items a user has listed */
    function fetchItemsListed() public view returns (MarketItem[] memory) {
      uint totalItemCount = _tokenIds.current();
      uint itemCount = 0;
      uint currentIndex = 0;

      for (uint i = 0; i < totalItemCount; i++) {
        if (idToMarketItem[i + 1].seller == msg.sender) {
          itemCount += 1;
        }
      }

      MarketItem[] memory items = new MarketItem[](itemCount);
      for (uint i = 0; i < totalItemCount; i++) {
        if (idToMarketItem[i + 1].seller == msg.sender) {
          uint currentId = i + 1;
          MarketItem storage currentItem = idToMarketItem[currentId];
          items[currentIndex] = currentItem;
          currentIndex += 1;
        }
      }
      return items;
    }
}

In this contract we are inheriting from the ERC721 standard implemented by OpenZepplin

Now the smart contract code and environment is complete and we can try testing it out.

To do so, we can create a local test to run through much of the functionality, like minting a token, putting it up for sale, selling it to a user, and querying for tokens.

To create the test, open test/sample-test.js and update it with the following code:

View the gist here



/* test/sample-test.js */
describe("NFTMarket", function() {
  it("Should create and execute market sales", async function() {
    /* deploy the marketplace */
    const NFTMarketplace = await ethers.getContractFactory("NFTMarketplace")
    const nftMarketplace = await NFTMarketplace.deploy()
    await nftMarketplace.deployed()

    let listingPrice = await nftMarketplace.getListingPrice()
    listingPrice = listingPrice.toString()

    const auctionPrice = ethers.utils.parseUnits('1', 'ether')

    /* create two tokens */
    await nftMarketplace.createToken("https://www.mytokenlocation.com", auctionPrice, { value: listingPrice })
    await nftMarketplace.createToken("https://www.mytokenlocation2.com", auctionPrice, { value: listingPrice })

    const [_, buyerAddress] = await ethers.getSigners()

    /* execute sale of token to another user */
    await nftMarketplace.connect(buyerAddress).createMarketSale(1, { value: auctionPrice })

    /* resell a token */
    await nftMarketplace.connect(buyerAddress).resellToken(1, auctionPrice, { value: listingPrice })

    /* query for and return the unsold items */
    items = await nftMarketplace.fetchMarketItems()
    items = await Promise.all(items.map(async i => {
      const tokenUri = await nftMarketplace.tokenURI(i.tokenId)
      let item = {
        price: i.price.toString(),
        tokenId: i.tokenId.toString(),
        seller: i.seller,
        owner: i.owner,
        tokenUri
      }
      return item
    }))
    console.log('items: ', items)
  })
})

Next, run the test from your command line:



npx hardhat test

If the test runs successfully, it should log out an array containing the two marketplace items.

Building the front end

Now that the smart contract is working and ready to go, we can start building out the UI.

The first thing we might think about is setting up a layout so that we can enable some navigation that will persist across all pages.

To set this up, open pages/_app.js and update it with the following code:

View the gist here



/* pages/_app.js */
import '../styles/globals.css'
import Link from 'next/link'

function MyApp({ Component, pageProps }) {
  return (
    <div>
      <nav className="border-b p-6">
        <p className="text-4xl font-bold">Metaverse Marketplace</p>
        <div className="flex mt-4">
          <Link href="/">
            <a className="mr-4 text-pink-500">
              Home
            </a>
          </Link>
          <Link href="/create-nft">
            <a className="mr-6 text-pink-500">
              Sell NFT
            </a>
          </Link>
          <Link href="/my-nfts">
            <a className="mr-6 text-pink-500">
              My NFTs
            </a>
          </Link>
          <Link href="/dashboard">
            <a className="mr-6 text-pink-500">
              Dashboard
            </a>
          </Link>
        </div>
      </nav>
      <Component {...pageProps} />
    </div>
  )
}

export default MyApp

The navigation has links for the home route as well as a page to sell an NFT, view the NFTs you have purchased, and a dashboard to see the NFTs you've listed.

Querying the contract for marketplace items

The next page we'll update is pages/index.js. This is the main entry-point of the app, and will be the view where we query for the NFTs for sale and render them to the screen.

View the gist here



/* pages/index.js */
import { ethers } from 'ethers'
import { useEffect, useState } from 'react'
import axios from 'axios'
import Web3Modal from 'web3modal'

import {
  marketplaceAddress
} from '../config'

import NFTMarketplace from '../artifacts/contracts/NFTMarketplace.sol/NFTMarketplace.json'

export default function Home() {
  const [nfts, setNfts] = useState([])
  const [loadingState, setLoadingState] = useState('not-loaded')
  useEffect(() => {
    loadNFTs()
  }, [])
  async function loadNFTs() {
    /* create a generic provider and query for unsold market items */
    const provider = new ethers.providers.JsonRpcProvider()
    const contract = new ethers.Contract(marketplaceAddress, NFTMarketplace.abi, provider)
    const data = await contract.fetchMarketItems()

    /*
    *  map over items returned from smart contract and format 
    *  them as well as fetch their token metadata
    */
    const items = await Promise.all(data.map(async i => {
      const tokenUri = await contract.tokenURI(i.tokenId)
      const meta = await axios.get(tokenUri)
      let price = ethers.utils.formatUnits(i.price.toString(), 'ether')
      let item = {
        price,
        tokenId: i.tokenId.toNumber(),
        seller: i.seller,
        owner: i.owner,
        image: meta.data.image,
        name: meta.data.name,
        description: meta.data.description,
      }
      return item
    }))
    setNfts(items)
    setLoadingState('loaded') 
  }
  async function buyNft(nft) {
    /* needs the user to sign the transaction, so will use Web3Provider and sign it */
    const web3Modal = new Web3Modal()
    const connection = await web3Modal.connect()
    const provider = new ethers.providers.Web3Provider(connection)
    const signer = provider.getSigner()
    const contract = new ethers.Contract(marketplaceAddress, NFTMarketplace.abi, signer)

    /* user will be prompted to pay the asking proces to complete the transaction */
    const price = ethers.utils.parseUnits(nft.price.toString(), 'ether')   
    const transaction = await contract.createMarketSale(nft.tokenId, {
      value: price
    })
    await transaction.wait()
    loadNFTs()
  }
  if (loadingState === 'loaded' && !nfts.length) return (<h1 className="px-20 py-10 text-3xl">No items in marketplace</h1>)
  return (
    <div className="flex justify-center">
      <div className="px-4" style={{ maxWidth: '1600px' }}>
        <div className="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-4 gap-4 pt-4">
          {
            nfts.map((nft, i) => (
              <div key={i} className="border shadow rounded-xl overflow-hidden">
                <img src={nft.image} />
                <div className="p-4">
                  <p style={{ height: '64px' }} className="text-2xl font-semibold">{nft.name}</p>
                  <div style={{ height: '70px', overflow: 'hidden' }}>
                    <p className="text-gray-400">{nft.description}</p>
                  </div>
                </div>
                <div className="p-4 bg-black">
                  <p className="text-2xl font-bold text-white">{nft.price} ETH</p>
                  <button className="mt-4 w-full bg-pink-500 text-white font-bold py-2 px-12 rounded" onClick={() => buyNft(nft)}>Buy</button>
                </div>
              </div>
            ))
          }
        </div>
      </div>
    </div>
  )
}

When the page loads, we query the smart contract for any NFTs that are still for sale and render them to the screen along with metadata about the items and a button for purchasing them.

Creating and listing NFTs

Next, let's create the page that allows users to create and list NFTs.

There are a few things happening in this page:

The user is able to upload and save files to IPFS
The user is able to create a new NFT
The user is able to set metadata and price of item and list it for sale on the marketplace

After the user creates and lists an item, they are re-routed to the main page to view all of the items for sale.

View the gist here



/* pages/create-nft.js */
import { useState } from 'react'
import { ethers } from 'ethers'
import { create as ipfsHttpClient } from 'ipfs-http-client'
import { useRouter } from 'next/router'
import Web3Modal from 'web3modal'

const client = ipfsHttpClient('https://ipfs.infura.io:5001/api/v0')

import {
  marketplaceAddress
} from '../config'

import NFTMarketplace from '../artifacts/contracts/NFTMarketplace.sol/NFTMarketplace.json'

export default function CreateItem() {
  const [fileUrl, setFileUrl] = useState(null)
  const [formInput, updateFormInput] = useState({ price: '', name: '', description: '' })
  const router = useRouter()

  async function onChange(e) {
    /* upload image to IPFS */
    const file = e.target.files[0]
    try {
      const added = await client.add(
        file,
        {
          progress: (prog) => console.log(`received: ${prog}`)
        }
      )
      const url = `https://ipfs.infura.io/ipfs/${added.path}`
      setFileUrl(url)
    } catch (error) {
      console.log('Error uploading file: ', error)
    }  
  }
  async function uploadToIPFS() {
    const { name, description, price } = formInput
    if (!name || !description || !price || !fileUrl) return
    /* first, upload metadata to IPFS */
    const data = JSON.stringify({
      name, description, image: fileUrl
    })
    try {
      const added = await client.add(data)
      const url = `https://ipfs.infura.io/ipfs/${added.path}`
      /* after metadata is uploaded to IPFS, return the URL to use it in the transaction */
      return url
    } catch (error) {
      console.log('Error uploading file: ', error)
    }  
  }

  async function listNFTForSale() {
    const url = await uploadToIPFS()
    const web3Modal = new Web3Modal()
    const connection = await web3Modal.connect()
    const provider = new ethers.providers.Web3Provider(connection)
    const signer = provider.getSigner()

    /* create the NFT */
    const price = ethers.utils.parseUnits(formInput.price, 'ether')
    let contract = new ethers.Contract(marketplaceAddress, NFTMarketplace.abi, signer)
    let listingPrice = await contract.getListingPrice()
    listingPrice = listingPrice.toString()
    let transaction = await contract.createToken(url, price, { value: listingPrice })
    await transaction.wait()

    router.push('/')
  }

  return (
    <div className="flex justify-center">
      <div className="w-1/2 flex flex-col pb-12">
        <input 
          placeholder="Asset Name"
          className="mt-8 border rounded p-4"
          onChange={e => updateFormInput({ ...formInput, name: e.target.value })}
        />
        <textarea
          placeholder="Asset Description"
          className="mt-2 border rounded p-4"
          onChange={e => updateFormInput({ ...formInput, description: e.target.value })}
        />
        <input
          placeholder="Asset Price in Eth"
          className="mt-2 border rounded p-4"
          onChange={e => updateFormInput({ ...formInput, price: e.target.value })}
        />
        <input
          type="file"
          name="Asset"
          className="my-4"
          onChange={onChange}
        />
        {
          fileUrl && (
            <img className="rounded mt-4" width="350" src={fileUrl} />
          )
        }
        <button onClick={listNFTForSale} className="font-bold mt-4 bg-pink-500 text-white rounded p-4 shadow-lg">
          Create NFT
        </button>
      </div>
    </div>
  )
}

Viewing only the NFTs purchased by the user

In the NFTMarketplace.sol smart contract, we created a function named fetchMyNFTs that only returns the NFTs owned by the user.

In pages/my-nfts.js, we will use that function to fetch and render them.

This functionality is different than the query main pages/index.js page because we need to ask the user for their address and use it in the contract, so the user will have to sign the transaction for it to be able to fetch them properly.

View the gist here



/* pages/my-nfts.js */
import { ethers } from 'ethers'
import { useEffect, useState } from 'react'
import axios from 'axios'
import Web3Modal from 'web3modal'
import { useRouter } from 'next/router'

import {
  marketplaceAddress
} from '../config'

import NFTMarketplace from '../artifacts/contracts/NFTMarketplace.sol/NFTMarketplace.json'

export default function MyAssets() {
  const [nfts, setNfts] = useState([])
  const [loadingState, setLoadingState] = useState('not-loaded')
  const router = useRouter()
  useEffect(() => {
    loadNFTs()
  }, [])
  async function loadNFTs() {
    const web3Modal = new Web3Modal({
      network: "mainnet",
      cacheProvider: true,
    })
    const connection = await web3Modal.connect()
    const provider = new ethers.providers.Web3Provider(connection)
    const signer = provider.getSigner()

    const marketplaceContract = new ethers.Contract(marketplaceAddress, NFTMarketplace.abi, signer)
    const data = await marketplaceContract.fetchMyNFTs()

    const items = await Promise.all(data.map(async i => {
      const tokenURI = await marketplaceContract.tokenURI(i.tokenId)
      const meta = await axios.get(tokenURI)
      let price = ethers.utils.formatUnits(i.price.toString(), 'ether')
      let item = {
        price,
        tokenId: i.tokenId.toNumber(),
        seller: i.seller,
        owner: i.owner,
        image: meta.data.image,
        tokenURI
      }
      return item
    }))
    setNfts(items)
    setLoadingState('loaded') 
  }
  function listNFT(nft) {
    router.push(`/resell-nft?id=${nft.tokenId}&tokenURI=${nft.tokenURI}`)
  }
  if (loadingState === 'loaded' && !nfts.length) return (<h1 className="py-10 px-20 text-3xl">No NFTs owned</h1>)
  return (
    <div className="flex justify-center">
      <div className="p-4">
        <div className="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-4 gap-4 pt-4">
          {
            nfts.map((nft, i) => (
              <div key={i} className="border shadow rounded-xl overflow-hidden">
                <img src={nft.image} className="rounded" />
                <div className="p-4 bg-black">
                  <p className="text-2xl font-bold text-white">Price - {nft.price} Eth</p>
                  <button className="mt-4 w-full bg-pink-500 text-white font-bold py-2 px-12 rounded" onClick={() => listNFT(nft)}>List</button>
                </div>
              </div>
            ))
          }
        </div>
      </div>
    </div>
  )
}

Dashboard

The next page we will be creating is the dashboard that will allow users to view all of the items they have listed.

This page will be using the fetchItemsListed function from the NFTMarketplace.sol smart contract which returns only the items that match the address of the user making the function call.

Create a new file called dashboard.js in the pages directory with the following code:

View the gist here



/* pages/dashboard.js */
import { ethers } from 'ethers'
import { useEffect, useState } from 'react'
import axios from 'axios'
import Web3Modal from 'web3modal'

import {
  marketplaceAddress
} from '../config'

import NFTMarketplace from '../artifacts/contracts/NFTMarketplace.sol/NFTMarketplace.json'

export default function CreatorDashboard() {
  const [nfts, setNfts] = useState([])
  const [loadingState, setLoadingState] = useState('not-loaded')
  useEffect(() => {
    loadNFTs()
  }, [])
  async function loadNFTs() {
    const web3Modal = new Web3Modal({
      network: 'mainnet',
      cacheProvider: true,
    })
    const connection = await web3Modal.connect()
    const provider = new ethers.providers.Web3Provider(connection)
    const signer = provider.getSigner()

    const contract = new ethers.Contract(marketplaceAddress, NFTMarketplace.abi, signer)
    const data = await contract.fetchItemsListed()

    const items = await Promise.all(data.map(async i => {
      const tokenUri = await contract.tokenURI(i.tokenId)
      const meta = await axios.get(tokenUri)
      let price = ethers.utils.formatUnits(i.price.toString(), 'ether')
      let item = {
        price,
        tokenId: i.tokenId.toNumber(),
        seller: i.seller,
        owner: i.owner,
        image: meta.data.image,
      }
      return item
    }))

    setNfts(items)
    setLoadingState('loaded') 
  }
  if (loadingState === 'loaded' && !nfts.length) return (<h1 className="py-10 px-20 text-3xl">No NFTs listed</h1>)
  return (
    <div>
      <div className="p-4">
        <h2 className="text-2xl py-2">Items Listed</h2>
          <div className="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-4 gap-4 pt-4">
          {
            nfts.map((nft, i) => (
              <div key={i} className="border shadow rounded-xl overflow-hidden">
                <img src={nft.image} className="rounded" />
                <div className="p-4 bg-black">
                  <p className="text-2xl font-bold text-white">Price - {nft.price} Eth</p>
                </div>
              </div>
            ))
          }
        </div>
      </div>
    </div>
  )
}

Reselling a token

The final page we will be creating will allow users to resell an NFT they've purchased from someone else.

This page will be using the resellToken function from the NFTMarketplace.sol smart contract.

View the gist here



/* pages/resell-nft.js */
import { useEffect, useState } from 'react'
import { ethers } from 'ethers'
import { useRouter } from 'next/router'
import axios from 'axios'
import Web3Modal from 'web3modal'

import {
  marketplaceAddress
} from '../config'

import NFTMarketplace from '../artifacts/contracts/NFTMarketplace.sol/NFTMarketplace.json'

export default function ResellNFT() {
  const [formInput, updateFormInput] = useState({ price: '', image: '' })
  const router = useRouter()
  const { id, tokenURI } = router.query
  const { image, price } = formInput

  useEffect(() => {
    fetchNFT()
  }, [id])

  async function fetchNFT() {
    if (!tokenURI) return
    const meta = await axios.get(tokenURI)
    updateFormInput(state => ({ ...state, image: meta.data.image }))
  }

  async function listNFTForSale() {
    if (!price) return
    const web3Modal = new Web3Modal()
    const connection = await web3Modal.connect()
    const provider = new ethers.providers.Web3Provider(connection)
    const signer = provider.getSigner()

    const priceFormatted = ethers.utils.parseUnits(formInput.price, 'ether')
    let contract = new ethers.Contract(marketplaceAddress, NFTMarketplace.abi, signer)
    let listingPrice = await contract.getListingPrice()

    listingPrice = listingPrice.toString()
    let transaction = await contract.resellToken(id, priceFormatted, { value: listingPrice })
    await transaction.wait()

    router.push('/')
  }

  return (
    <div className="flex justify-center">
      <div className="w-1/2 flex flex-col pb-12">
        <input
          placeholder="Asset Price in Eth"
          className="mt-2 border rounded p-4"
          onChange={e => updateFormInput({ ...formInput, price: e.target.value })}
        />
        {
          image && (
            <img className="rounded mt-4" width="350" src={image} />
          )
        }
        <button onClick={listNFTForSale} className="font-bold mt-4 bg-pink-500 text-white rounded p-4 shadow-lg">
          List NFT
        </button>
      </div>
    </div>
  )
}

Running the project

To run the project, we will need to have a deploy script to deploy the smart contracts to the blockchain network.

Deploying the contracts to a local network

When we created the project, Hardhat created an example deployment script at scripts/sample-script.js.

To make the purpose of this script more clear, update the name of scripts/sample-script.js to scripts/deploy.js.

Next, update scripts/deploy.js with the following code:



const hre = require("hardhat");
const fs = require('fs');

async function main() {
  const NFTMarketplace = await hre.ethers.getContractFactory("NFTMarketplace");
  const nftMarketplace = await NFTMarketplace.deploy();
  await nftMarketplace.deployed();
  console.log("nftMarketplace deployed to:", nftMarketplace.address);

  fs.writeFileSync('./config.js', `
  export const marketplaceAddress = "${nftMarketplace.address}"
  `)
}

main()
  .then(() => process.exit(0))
  .catch((error) => {
    console.error(error);
    process.exit(1);
  });

This script will deploy the contract to the blockchain network and create a file named config.js that will hold the address of the smart contract after it's been deployed.

We will first test this on a local network, then deploy it to the Mumbai testnet.

To spin up a local network, open your terminal and run the following command:



npx hardhat node

This should create a local network with 20 accounts.

Next, keep the node running and open a separate terminal window to deploy the contract.

In a separate window, run the following command:



npx hardhat run scripts/deploy.js --network localhost

When the deployment is complete, the CLI should print out the address of the contract that was deployed:

You should also see the config.js file populated with this smart contract address.

Importing accounts into MetaMask

You can import the accounts created by the node into your Metamask wallet to try out in the app.

Each of these accounts is seeded with 10000 ETH.

To import one of these accounts, first switch your MetaMask wallet network to Localhost 8545.

Next, in MetaMask click on Import Account from the accounts menu:

Copy then paste one of the Private Keys logged out by the CLI and click Import. Once the account is imported, you should see some the Eth in the account:

I'd suggest doing this with 2 or 3 accounts so that you have the ability to test out the various functionality between users.

Running the app

Now we can test out the app!

To start the app, run the following command in your CLI:



npm run dev

To test everything out, try listing an item for sale, then switching to another account and purchasing it.

Deploying to Polygon

Now that we have the project up and running and tested locally, let's deploy to Polygon. We'll start by deploying to Mumbai, the Polygon test network.

The first thing we will need to do is save one of our private keys from our wallet as an environment variable.

To get the private key, you can use one of the private keys given to you by Hardhat or you can export them directly from MetaMask.

If you are on a Mac, you can set an environment variable from the command line like so (be sure to run the deploy script from this same terminal and session):



export privateKey="your-private-key"

Private keys are never meant to be shared publicly under any circumstance. It is advised never to hardcode a private key in a file. If you do choose to do so, be sure to use a testing wallet and to never under any circumstances push a file containing a private key to source control or expose it publicly.

Configuring the network

Next, we need to switch from the local test network to the Mumbai Testnet.

To do so, we need to create and set the network configuration.

First, open MetaMask and click on Settings.

Next, click on Networks and then Add Network:

Here, we will add the following configurations for the Mumbai test network as listed here:

Network Name: Mumbai TestNet
New RPC URL: https://rpc-mumbai.maticvigil.com
Chain ID: 80001
Currency Symbol: Matic

Save this, then you should be able to switch to and use the new network!

Finally, you will need some testnet Matic tokens in order to interact with the applications.

To get these, you can visit the Matic Faucet, inputting the address of the wallets that you would like to request the tokens.

Deploying to the Matic / Polygon network

Now that you have some Matic tokens, you can deploy to the Polygon network!

To do so, be sure that the address associated with the private key you are deploying your contract with has received some Matic tokens in order to pay the gas fees for the transaction.

Also, be sure to uncomment the mumbai configuration in hardhat.config.js:



    mumbai: {
      url: "https://rpc-mumbai.maticvigil.com",
      accounts: [process.env.privateKey]
    }

To deploy to Matic, run the following command:



npx hardhat run scripts/deploy.js --network mumbai

If you run a deployment error, the public RPC may be congested. In production, it's recommended to use an RPC provider like Infura, Alchemy, Quicknode, or Figment DataHub.

Once the contracts have been deployed, update the loadNFTs function call in pages/index.js to include the new RPC endpoint:



/* pages/index.js */

/* old provider */
const provider = new ethers.providers.JsonRpcProvider()

/* new provider */
const provider = new ethers.providers.JsonRpcProvider("https://rpc-mumbai.maticvigil.com")

You should now be able to update the contract addresses in your project and test on the new network 🎉!



npm run dev

If you run into an error, the contract address printed out to the console by hardhat could be incorrect due to a bug I've run into recently. You can get the correct contract addresses by visiting https://mumbai.polygonscan.com/ and pasting in the address from which the contracts were deployed to see the most recent transactions and getting the contract addresses from the transaction data.

Deploying to Mainnet

To deploy to the main Matic / Polygon network, you can use the same steps we set up for the Mumbai test network.

The main difference is that you'll need to use an endpoint for Matic as well as import the network into your MetaMask wallet as listed here.

An example update in your project to make this happen might look like this:



/* hardhat.config.js */

/* adding Matic main network config to existing config */
...
matic: {
  url: "https://rpc-mainnet.maticvigil.com",
  accounts: [privateKey]
}
...

Public RPCs like the one listed above may have traffic or rate-limits depending on usage. You can sign up for a dedicated free RPC URL using services like Infura, MaticVigil, QuickNode, Alchemy, Chainstack, or Ankr.

For example, using something like Infura:



url: `https://polygon-mainnet.infura.io/v3/${infuraId}`

To view the final source code for this project, visit this repo

Next steps

Congratulations! You've deployed a non-trivial app to Polygon.

The coolest thing about working with solutions like Polygon is how little extra work or learning I had to do compared to building directly on Ethereum. Almost all of the APIs and tooling in these layer 2's and sidechains remain the same, making any skills transferable across various platforms like Polygon.

For the next steps, I'd suggest porting over the queries implemented in this app using The Graph. The Graph will open up many more data access patterns including things like pagination, filtering, and sorting which are necessary for any real-world application.

I will also be publishing a tutorial showing how to use Polygon with The Graph in the coming weeks.

Uploading Files to IPFS from a Web Application

Nader Dabit — Mon, 28 Jun 2021 13:30:46 +0000

One of the most common interactions with IPFS is uploading files like images and videos from a client-side application, so I found it surprising that there were not a lot of straightforward tutorials showing how this is done.

In this tutorial you will learn just that in as few lines of code (and as simply) as possible using ipfs-http-client. The ideas here are implemented in React but should be fairly easily transferrable to doing the same thing in any other JavaScript framework, like Vue, Angular, or Svelte.

About IPFS

IPFS is a decentralized, peer to peer file sharing protocol.

There are various types of IPFS gateways available. Some are free, some are not. Some offer read-only access, and others offer both read and write access.

You can also run your own IPFS gateway.

Because we will be uploading / saving files, we need to be sure to choose a gateway that allows us write access. The gateway we will be using today is Infura. Other popular services are Pinata or Fleek.

For this example to work, you need to sign up with Infura and get a project ID and API secret.

For an example of how to pin a file to IPFS with Pinata, check out this repo.

Getting started

If you already have a React application created, you can skip this step.

First, create a new React app and change into the new directory:

npx create-react-app ipfs-example

cd ipfs-example

Next, install the ipfs-http-client library and buffer using either NPM or Yarn:

npm install ipfs-http-client buffer

Base code

The basic functionality can be summed up in these lines of code, but I'll also be building out an entire UI to show how it all fits together.

The basic code for getting this to work is here:

/* import the ipfs-http-client and buffer libraries */
import { create } from 'ipfs-http-client'
import { Buffer } from 'buffer'

/* configure Infura auth settings */
const projectId = "<your-infura-project-id>"
const projectSecret = "<your-infura-project-secret>"
const auth = 'Basic ' + Buffer.from(projectId + ':' + projectSecret).toString('base64')

/* Create an instance of the client */
const client = create({
  host: 'ipfs.infura.io',
  port: 5001,
  protocol: 'https',
  headers: {
      authorization: auth,
  }
})

/* upload the file */
const added = await client.add(file)

/* or a string */
const added = await client.add('hello world')

Full code

Let's now look at how the above code would be used to actually implement file upload functionality in our app for uploading and viewing images.

In your project, open src/App.js and update it with the following code:

/* src/App.js */
import './App.css'
import { useState } from 'react'
import { create } from 'ipfs-http-client'
import { Buffer } from 'buffer'

/* configure Infura auth settings */
const projectId = "<your-infura-project-id>"
const projectSecret = "<your-infura-project-secret>"
const auth = 'Basic ' + Buffer.from(projectId + ':' + projectSecret).toString('base64');

/* create the client */
const client = create({
  host: 'ipfs.infura.io',
  port: 5001,
  protocol: 'https',
  headers: {
      authorization: auth,
  },
})

function App() {
  const [fileUrl, updateFileUrl] = useState(``)
  async function onChange(e) {
    const file = e.target.files[0]
    try {
      const added = await client.add(file)
      const url = `https://infura-ipfs.io/ipfs/${added.path}`
      updateFileUrl(url)
      console.log("IPFS URI: ", url)
    } catch (error) {
      console.log('Error uploading file: ', error)
    }  
  }
  return (
    <div className="App">
      <h1>IPFS Example</h1>
      <input
        type="file"
        onChange={onChange}
      />
      {
        fileUrl && (
          <div>
            <img src={fileUrl} width="600px" />
            <a href={fileUrl} target="_blank">{fileUrl}</a>
          </div>
        )
      }
    </div>
  );
}

export default App

Next, run the app:

npm start

When the app loads, you should see a file upload button.

Once a file has been successfully uploaded, you should see it rendered in the UI.