The number of production Dapps continues to explode and the demand for developers building with Solidity and other blockchain languages continues to outpace supply, moving wages higher and higher.

As a developer getting into this space, I quickly learned there are a lot of differences in the way that we interact with and build on top of blockchains versus what I was used to in the traditional web. With Ethereum (and other blockchains), data isn’t stored in a format that can efficiently or easily be consumed directly from other applications or front ends. The problem is that you need to have the data 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.

In the traditional web stack, databases, servers, and APIs query, filter, sort, paginate, group, and join data before it is returned to an application usually via some type of http request. These types of data transformations are not possible when reading data directly from Ethereum or other blockchains.

In the past, developers were getting around this by building their own centralized indexing servers — pulling data from blockchains, storing it in a database, and exposing it over an API. This required significant engineering and hardware resources and broke the important security properties required for decentralization.

How can we build an API on top of blockchain data that can easily be deployed to a decentralized web infrastructure? Let’s find out.

Decentralizing web infrastructure

The vision of and movement towards a decentralized internet is commonly referred to as Web3. Web3 enhances the internet as we know it today with these added characteristics:

• Decentralized
• Verifiable
• Trustless
• Self governing

For a great overview of what Web3 is, check out this video by Juan Benet

To achieve decentralization, protocols define networks that offer a range of digital services such as compute, storage, bandwidth, identity, and other pieces of web infrastructure with no intermediaries. These protocols are usually distributed across multiple nodes (servers) that enable the participation of anyone looking to be part of the network and provide a service.

The network participants are incentivized to provide the highest quality services to anyone consuming them. Rules are also put in place to ensure the security and the integrity of the network itself. This is usually accomplished using a combination of consensus mechanisms programmed into smart contracts implementing various types of game theory and cryptoeconomic design.

Building on The Graph

In this post, we will be looking at one such protocol, The Graph, and how to build and deploy our own GraphQL API using data stored in the Ethereum blockchain.

The Graph is an indexing protocol for querying blockchains like Ethereum and networks like IPFS. Anyone can build and publish open APIs, called subgraphs, making data easily accessible.

Subgraphs define the data, data sources, and data access patterns that you would like to have made available via a GraphQL API. You as a developer can choose either to use a subgraph already deployed by another developer, or define and deploy your own subgraph and use it.

Developers can create open APIs by deploying their subgraphs either to the hosted service or to the network, enabling them to earn money based on the amount of usage of their API.

Subgraphs are made up of a few main parts:

1. GraphQL Schema

The GraphQL Schema defines the data types / entities you would like to save and query for. You can also define configuration like relationships and full text search capabilities in your schema.

2. Subgraph Manifest (yaml configuration)

(from the docs) The manifest defines the smart contracts your subgraph indexes, their ABIs, which events from these contracts to pay attention to, and how to map event data to entities that Graph Node stores and allows to query.

3. AssemblyScript Mappings

AssemblyScript Mappings allow you to save data to be indexed using the entity types defined in your schema. The Graph CLI also generates AssemblyScript types using a combination of the subgraph’s schema along with a smart contract’s ABIs.

Let’s start building

Now that we have a good understanding of The Graph and how it works, let’s start writing some code.

In this tutorial we’ll build a subgraph for querying NTF data from the Zora smart contract, implementing queries for fetching NFTs as well as their owners, and building relationships between them.

Prerequisites

To be successful in this tutorial, you should have Node.js installed on your machine. These days, I recommend using either nvm or fnm to manage Node.js versions.

Creating the Graph project in the Graph Explorer

To get started, open the Graph Explorer 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 — Zoranftsubgraph
• Subtitle — A subgraph for querying NFTs
• 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.

There are two ways to initialize a new subgraph:

1 — From an example subgraph

$ graph init --from-example <GITHUB_USERNAME>/<SUBGRAPH_NAME> [<DIRECTORY>]

2 — From an existing smart contract

If you already have a smart contract deployed to Ethereum mainnet or one of the testnets, initializing a new subgraph from this contract is an easy way to get up and running.

$ graph init --from-contract <CONTRACT_ADDRESS> \
  [--network <ETHEREUM_NETWORK>] \
  [--abi <FILE>] \
  <GITHUB_USER>/<SUBGRAPH_NAME> [<DIRECTORY>]

In our case we’ll be using the Zora Token Contract so we can initilize from that contract address by passing in the contract address using the --from-contract flag:

$ graph init --from-contract 0xabEFBc9fD2F806065b4f3C237d4b59D9A97Bcac7 --network mainnet  \
--contract-name Token --index-events

? Subgraph name › your-username/Zoranftsubgraph
? Directory to create the subgraph in › Zoranftsubgraph
? Ethereum network › Mainnet
? Contract address › 0xabEFBc9fD2F806065b4f3C237d4b59D9A97Bcac7
? Contract Name · Token

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 Token @entity {
  id: ID!
  tokenID: BigInt!
  contentURI: String!
  metadataURI: String!
  creator: User!
  owner: User!
}

type User @entity {
  id: ID!
  tokens: [Token!]! @derivedFrom(field: "owner")
  created: [Token!]! @derivedFrom(field: "creator")
}

On Relationships via @derivedFrom (from the docs):

Reverse lookups can be defined on an entity through the @derivedFrom field. This creates a virtual field on the entity that may be queried but cannot be set manually through the mappings API. Rather, it is derived from the relationship defined on the other entity. For such relationships, it rarely makes sense to store both sides of the relationship, and both indexing and query performance will be better when only one side is stored and the other is derived.

For one-to-many relationships, the relationship should always be stored on the ‘one’ side, and the ‘many’ side should always be derived. Storing the relationship this way, rather than storing an array of entities on the ‘many’ side, will result in dramatically better performance for both indexing and querying the subgraph. In general, storing arrays of entities should be avoided as much as is practical.

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:
  - Token
  - User

Next, update the dataSources.mapping.eventHandlers to include only the following two event handlers:

eventHandlers:
  - event: TokenURIUpdated(indexed uint256,address,string)
    handler: handleTokenURIUpdated
  - event: Transfer(indexed address,indexed address,indexed uint256)
    handler: handleTransfer

Finally, update the configuration to add the startBlock:

source:
  address: "0xabEFBc9fD2F806065b4f3C237d4b59D9A97Bcac7"
  abi: Token
  startBlock: 11565020

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 {
  TokenURIUpdated as TokenURIUpdatedEvent,
  Transfer as TransferEvent,
  Token as TokenContract
} from "../generated/Token/Token"

import {
  Token, User
} from '../generated/schema'

export function handleTokenURIUpdated(event: TokenURIUpdatedEvent): void {
  let token = Token.load(event.params._tokenId.toString());
  token.contentURI = event.params._uri;
  token.save();
}

export function handleTransfer(event: TransferEvent): void {
  let token = Token.load(event.params.tokenId.toString());
  if (!token) {
    token = new Token(event.params.tokenId.toString());
    token.creator = event.params.to.toHexString();
    token.tokenID = event.params.tokenId;

    let tokenContract = TokenContract.bind(event.address);
    token.contentURI = tokenContract.tokenURI(event.params.tokenId);
    token.metadataURI = tokenContract.tokenMetadataURI(event.params.tokenId);
  }
  token.owner = event.params.to.toHexString();
  token.save();

  let user = User.load(event.params.to.toHexString());
  if (!user) {
    user = new User(event.params.to.toHexString());
    user.save();
  }
}

These mappings will handle events for when a new token is created, transfered, or 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 using the Graph CLI. To deploy, you will first need to copy the Access token for the subgraph you created in the Graph Explorer:

Next, run the following command:

$ graph auth https://api.thegraph.com/deploy/ <ACCESS_TOKEN>

$ 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 Graph explorer:

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 tokens and their metadata:

{
  tokens {
    id
    tokenID
    contentURI
    metadataURI
  }
}

We can also configure the order direction:

{
  tokens(
    orderBy:id,
    orderDirection: desc
  ) {
    id
    tokenID
    contentURI
    metadataURI
  }
}

Or choose to skip forward a certain number of results to implement some basic pagination:

{
  tokens(
    skip: 100,
    orderBy:id,
    orderDirection: desc
  ) {
    id
    tokenID
    contentURI
    metadataURI
  }
}

Or query for users and their associated content:

{
  users {
    id
    tokens {
      id
      contentURI
    }
  }
}

Updating the subgraph

What if we want to make some changes to the subgraph and then redeploy? This is pretty easy, so let’s learn how to do it.

Let’s say that we want to add a new feature to our subgraph. In addition to our existing querying capabilities, let’s say that we wanted to add the capabilities to sort by the timestamp that the NFT was created.

To do so, we need to first add a new createdAtTimestamp field to the Token entity:

type Token @entity {
  id: ID!
  tokenID: BigInt!
  contentURI: String!
  metadataURI: String!
  creator: User!
  owner: User!
  "Add new createdAtTimesamp field"
  createdAtTimestamp: BigInt!
}

Now we can re-run the codegen:

graph codegen

Next, we need to update the mapping to save this new field:

// update the handleTransfer function to add the createdAtTimestamp to the token object
export function handleTransfer(event: TransferEvent): void {
  let token = Token.load(event.params.tokenId.toString());
  if (!token) {
    token = new Token(event.params.tokenId.toString());
    token.creator = event.params.to.toHexString();
    token.tokenID = event.params.tokenId;
    // Add the createdAtTimestamp to the token object
    token.createdAtTimestamp = event.block.timestamp;

    let tokenContract = TokenContract.bind(event.address);
    token.contentURI = tokenContract.tokenURI(event.params.tokenId);
    token.metadataURI = tokenContract.tokenMetadataURI(event.params.tokenId);
  }
  token.owner = event.params.to.toHexString();
  token.save();

  let user = User.load(event.params.to.toHexString());
  if (!user) {
    user = new User(event.params.to.toHexString());
    user.save();
  }
}

Now we can re-deploy the subgraph:

$ yarn deploy

Once the subgraph has been redeployed, we can now query by timestamp to view the most recently created NFTS:

{
  tokens(
    orderBy:createdAtTimestamp,
    orderDirection: desc
  ) {
    id
    tokenID
    contentURI
    metadataURI
  }
}

The codebase for this project is located here

Next steps

If you are interested in learning more about Web3, building Dapps, or building subgraphs, check out the following resources:

The Graph on Twitter — @graphprotocol

The Complete Guide to Full Stack Ethereum Development

The Graph Discord

Solidity Docs

Ethereum Developer Documentation

Austin Griffith on Twitter @austingriffith & Scaffold Eth

Crypto Zombies

TLDR: Check out our new publication here.

Medium has defaulted all posts to be behind a paywall (meaning you need to opt out, not opt in) which has caused some confusion for people that have published here in the past. This has caused some posts to be behind a paywall that people may not have really wanted to be behind by default.

Over the past year I’ve seen many people not enjoying the experience of reading on Medium now that many of these articles are behind this paywall so I have been slowly moving my personal as well as new publications writing to Dev.to.

I’ve created a new Open GraphQL publication there. If you’re interested in contributing or writing about GraphQL, come join us there. Dev.to is a great and thriving community of people passionate about what they do. Also, you are able to write in Markdown allowing you to easily port your content to other places with ease.

Thanks for reading!

Open GraphQL Moving to Dev.to was originally published in Open GraphQL on Medium, where people are continuing the conversation by highlighting and responding to this story.

I’ve been deep-diving into some interesting use-cases showing some of the real-time capabilities of GraphQL subscriptions.

A couple of weeks ago I built HypeBeats, a collaborative drum-machine with the help of Ken Wheeler’s drum machine, & before that I built a real-time drawing canvas with React Canvas Draw.

Last week I sent out a tweet to see what other ideas people had, & there were a lot:

Nader Dabit on Twitter

What crazy 🚫❌❗️❓ do you want you want me to build next with GraphQL? Looking for some useful and or crazy demo ideas. Real-time / collaboration is what I'd like to showcase the most.

An idea that immediately stood out to me was from NagarajanFs on Twitter:

Nagarajan on Twitter

@dabit3 A collaborative markdown editor with features of real-time comment by participants on different sections. (Google docs, but with markdown)

Basically his idea was Google Docs but for markdown. I loved it, so I decided to build it! The result was writewithme.dev.

Getting Started

The first thing I did was created a new React application:

npx create-react-app write-with-me

The next thing I needed to do was to find the tool I was going to use to allow markdown in a React App. I stumbled upon react-markdown by Espen Hovlandsdal (rexxars on Twitter).

npm install react-markdown

React Markdown was super simple to use. You import ReactMarkdown from the package & pass in the markdown you’d like to render as a prop:

const ReactMarkdown = require('react-markdown')

const input = '# This is a header\n\nAnd this is a paragraph'

<ReactMarkdown source={input} />

Building the API

Now that we have the markdown tool the next set was creating the API. I used AWS AppSync & AWS Amplify to do this. With the Amplify CLI, you can set a base type & add a decorator to build out the entire backend by taking advantage of the GraphQL Transform library.

amplify init

amplify add api

// chose GraphQL
// Choose API Key as the authentication

The schema I used was this:

type Post @model {
  id: ID!
  clientId: ID!
  markdown: String!
  title: String!
  createdAt: String
}

The @model decorator will tell Amplify to deploy a GraphQL backend complete with a DynamoDB data source & schema (types & operations) for all crud operations & GraphQL subscriptions. It will also create the resolvers for the created GraphQL operations.

After defining & saving the schema we deploy the AppSync API:

amplify push

When we run amplify push, we’re also given the option to execute GraphQL codegen in either TypeScript, JavaScript, or Flow. Doing this will introspect your GraphQL schema & automatically generate the GraphQL code you’ll need on the client in order to execute queries, mutations, & subscriptions.

Installing the dependencies

Next, we install the other necessary libraries we need for the app:

npm install aws-amplify react-router-dom uuid glamor debounce

• uuid — to create unique IDs to uniquely identify the client
• react-router-dom — to add routing
• aws-amplify — to interact with the AppSync API
• glamor — for styling
• debounce — for adding a debounce when user types

Writing the code

Now that our project is set up & our API has been deployed, we can start writing some code!

The app has three main files:

• Router.js — Defines the routes
• Posts.js — Fetches & renders the posts
• Post.js — Fetches & renders a single post

Router.js

Setting up navigation was pretty basic. We needed two routes: one for listing all of the posts & one for viewing a single post. I decided to go with the following route scheme:

/post/:id/:title

When someone hits the above route, we have access to everything we need to display a title for the post as well as the ID for us to fetch the post if it is an existing post. All of this info is available directly in the route parameters.

React Hooks with GraphQL

If you’ve ever wondered how to implement hooks into a GraphQL application, I recommend also reading my post Writing Custom Hooks for GraphQL because that’s exactly what we’ll be doing.

Instead of going over all of the code for the 2 components (if you’d like to see the code, click on the links above), I’d like to focus on how we implemented the necessary functionality using GraphQL & hooks.

The main API operations we needed from this app are intended to do the following:

1. Load all of the posts from the API
2. Subscribe to new posts being created by others
3. Load an individual post
4. Subscribe to changes within an individual post & re-render the component

Let’s take a look at each.

Loading all of the posts from the API

To load the posts I went with a useReducer hook combined with a function call within a useEffect hook. We first define the initial state. When the component renders for the first time we call the API & update the state using the fetchPosts function. This reducer will also handle our subscription:

import { listPosts } from './graphql/queries'
import { API, graphqlOperation } from 'aws-amplify'

const initialState = {
  posts: [],
  loading: true,
  error: false
}

function reducer(state, action) {
  switch (action.type) {
    case 'fetchPostsSuccess':
      return { ...state, posts: action.posts, loading: false }
    case 'addPostFromSubscription':
      return { ...state, posts: [ action.post, ...state.posts ] }
    case 'fetchPostsError':
      return { ...state, loading: false, error: true }
    default:
      throw new Error();
  }
}

async function fetchPosts(dispatch) {
  try {
    const postData = await API.graphql(graphqlOperation(listPosts))
    dispatch({
      type: 'fetchPostsSuccess',
      posts: postData.data.listPosts.items
    })
  } catch (err) {
    console.log('error fetching posts...: ', err)
    dispatch({
      type: 'fetchPostsError',
    })
  }
}

// in the hook

const [postsState, dispatch] = useReducer(reducer, initialState)

useEffect(() => {
  fetchPosts(dispatch)
}, [])

Subscribing to new posts being created

We already have our state ready to go from the above code, now we just need to subscribe to the changes in the hook. To do that, we use a useEffect hook & subscribe to the onCreatePost subscription:

useEffect(() => {
  const subscriber = API.graphql(graphqlOperation(onCreatePost)).subscribe({
    next: data => {
      const postFromSub = data.value.data.onCreatePost
      dispatch({
        type: 'addPostFromSubscription',
        post: postFromSub
      })
    }
  });
  return () => subscriber.unsubscribe()
}, [])

In this hook, we set up a subscription that will fire when a user creates a new post. When the data comes through, we call the dispatch function & pass in the new post data that was returned from the subscription.

Fetching a single post

When a user lands on a route, we can use the data from the route params to identify the post name & ID:

https://www.writewithme.dev/#/post/9999b0bb-63eb-4f5b-9805-23f6c2661478/%F0%9F%94%A5%20Write%20with%20me

In this route, the ID would be 9999b0bb-63eb-4f5b-9805–23f6c2661478 & the name would be Write with me.

When the component loads, we extract these params & use them.

The first thing we do is attempt to create a new post. If this is successful, we are done. If this post already exists, we are given the data for this post from the API call.

This may seem strange at first, right? Why not try to fetch, & if unsuccessful the create? Well, we want to reduce the total number of API calls. If we attempt to create a new post & the post exists, the API will actually return the data from the existing post allowing us to only make a single API call. This data is available in the errors:

err.errors[0].data

We handle the state in this component using useReducer hook.

// initial state
const post = {
  id: params.id,
  title: params.title,
  clientId: CLIENTID,
  markdown: '# Loading...'
}

function reducer(state, action) {
  switch (action.type) {
    case 'updateMarkdown':
      return { ...state, markdown: action.markdown, clientId: CLIENTID };
    case 'updateTitle':
      return {  ]...state, title: action.title, clientId: CLIENTID };
    case 'updatePost':
      return action.post
    default:
      throw new Error();
  }
}

async function createNewPost(post, dispatch) {
  try {
    const postData = await API.graphql(graphqlOperation(createPost, { input: post }))
    dispatch({
      type: 'updatePost',
      post: {
        ...postData.data.createPost,
        clientId: CLIENTID
      }
    })
  } catch(err) {
    if (err.errors[0].errorType === "DynamoDB:ConditionalCheckFailedException") {
      const existingPost = err.errors[0].data
      dispatch({
        type: 'updatePost',
        post: {
          ...existingPost,
          clientId: CLIENTID
        }
      })
    }    
  }
}

// in the hook, initialize the state
 const [postState, dispatch] = useReducer(reducer, post)

// fetch post
useEffect(() => {
  const post = {
    ...postState,
    markdown: input
  }
  createNewPost(post, dispatch)
}, [])

Subscribing to a post change

The last thing we need to do is subscribe to changes in a post. To do this, we do two things:

1. Update the API when the user types (both title or markdown changes)
2. Subscribe to changes then the post is updated

async function updatePost(post) {
  try {
    await API.graphql(graphqlOperation(UpdatePost, { input: post }))
    console.log('post has been updated!')
  } catch (err) {
    console.log('error:' , err)
  }
}

function updateMarkdown(e) {
  dispatch({
    type: 'updateMarkdown',
    markdown: e.target.value,
  })
  const newPost = {
    id: post.id,
    markdown: e.target.value,
    clientId: CLIENTID,
    createdAt: post.createdAt,
    title: postState.title
  }
  updatePost(newPost, dispatch)
}

function updatePostTitle (e) {
  dispatch({
    type: 'updateTitle',
    title: e.target.value
  })
  const newPost = {
    id: post.id,
    markdown: postState.markdown,
    clientId: CLIENTID,
    createdAt: post.createdAt,
    title: e.target.value
  }
  updatePost(newPost, dispatch)
}

useEffect(() => {
  const subscriber = API.graphql(graphqlOperation(onUpdatePost, {
    id: post.id
  })).subscribe({
    next: data => {
      if (CLIENTID === data.value.data.onUpdatePost.clientId) return
      const postFromSub = data.value.data.onUpdatePost
      dispatch({
        type: 'updatePost',
        post: postFromSub
      })
    }
  });
  return () => subscriber.unsubscribe()
}, [])

When the user types, we update both the local state as well as the API. In the subscription, we first check to see if the subscription data coming in is from the same Client ID. If it is, we do nothing. If it is from another client, we update the state.

Deploying the app on a custom domain

Now that we’ve built the app, what about deploying it to a custom domain like I did with writewithme.dev?

I did this using GoDaddy, Route53 & the Amplify console.

In the AWS dashboard, go to Route53 & click on Hosted Zones. Choose Create Hosted Zone. From there, enter your domain name & click create.

Be sure to enter your domain name as is, without www. E.g. writewithme.dev

Now in Route53 dashboard you should be given 4 nameservers. In your hosting account, set these custom nameservers in your DNS setting for the domain you’re using.

These nameservers should look something like ns-1355.awsdns-41.org, ns-1625.awsdns-11.co.uk, etc…

Next, in the Amplify Console, click on Get Started under the Deploy section.

Connect your GitHub account & then choose the repo & branch that your project lives in.

This will walk you through deploying the app in the Amplify Console & making it live. Once complete, you should see some information about the build & some screenshots of the app:

Next, click Domain Management in the left menu. Next, click the Add Domain button.

Here, the dropdown menu should show you the domain you have in Route53. Choose this domain & click Configure domain.

This should deploy the app to your domain (this will take between 5–20 minutes). The last thing is to set up redirects. Click on Rewrites & redirects.

Make sure the redirect for the domain looks like this (i.e. redirect the https://websitename to https://www.websitename):

Next Steps

The next thing I’d like to do would be to add authentication & commenting functionality (so people can comment on each individual post). This is all doable with Amplify & AppSync. If we wanted to add authentication, we could add it with the CLI:

amplify add auth

Next, we’d have to write some logic to log people in & out or we can use the withAuthenticator HOC. To learn more about how to do this, check out these docs.

Next, we’d probably want to update the schema to add commenting functionality. To do so, we could update the schema to something like what I created here. In this schema, we’ve added a field for the Discussion (in our case it would probably be called Comment).

In the resolver, we could probably also correlate a user’s identity to the message as well but using the $context.identity.sub which would be available after the user is signed in.

Check out the final code- https://github.com/dabit3/write-with-me

My Name is Nader Dabit . I am a Developer Advocate at AWS working with projects like AWS AppSync and AWS Amplify.

I’m also the author of React Native in Action, & the editor of React Native Training & OpenGraphQL.

How to Build a Real-time Collaborative Markdown Editor with React Hooks, GraphQL & AWS AppSync was originally published in Open GraphQL on Medium, where people are continuing the conversation by highlighting and responding to this story.