The beauty of doing GraphQL, more so on the Hasura, is that you can iterate faster. You can get your ideas out there fast, roll out new features, test, and deploy effortlessly. All of this can be done without worrying about configuring the backend infrastructure. This also cuts out common GraphQL implementation tasks like going through the grunt work of setting up GraphQL servers, resolvers, and so on. You spend more time with your ideas and developing your core application. This gives you a pleasant developer experience, and in turn, a robust and pragmatic product cycle.

Modeling data entities

Our Instagram clone is going to be a fairly stripped-down version with two main data entities: users and photos.

Each user’s feed will contain posts by the users they’re following. Let’s look at such a post and try to pinpoint its different elements:

1. An image
2. The username of the user who posted the image
3. Then an optional description by the user
4. Comments on the post
5. Likes on the post

We can take the following notes on the basic understanding we have for now on the application data:

• Users:
  • Each user has a username. Like the original Instagram, users can have a real name too, but it’s optional.
  • An avatar image
  • An optional “About me” text
  • An associated email address
  • Number of followers and followings
  • Posts
• Posts:
  • Each post belongs to a single user
  • Image
  • An optional text or description accompanying the post or image
  • Number of likes (for now we’ll consider numbers only)
  • A post can have zero or more comments
• Comment
  • Each post can have zero or more comments
  • The text of the comment
  • The associated user who made the comment

Keeping this functionality in mind, we can now start creating the Database tables. The schema will consist of three types: User, Post, and Comment. These fields will correspond to the observations we’ve just made. We’ll also assume that all the images within the app reside in an external resource.

The following graph diagram can help you better understand the relationships each type has with one another:

User type

Below is the User table:

Like in Instagram, the username will act as a unique identifier for each user.

A user can have more than one post, and we’d like to be able to access their data when we’re traversing User nodes in our data graph.

See this link for creating relationships through foreign key in hasura. We just need the following relationships.

Post type

The post table looks like the following:

Conversely, multiple posts can have a single author. In those cases, we’d also like an option of being able to query about their authors too. You can easily see the type of relationship these two types have with each other; we want to define that relationship in our schema and the ability to traverse from both direction.

The same kind of relationship exists between a Post and Comment object. Hence just like users and their posts, we’ve established a bidirectional edge between post and comment objects.

Comment type

Lastly, the Comment table:

Hasura creates a fully functional GraphQL API that can handle all requests coming in from the client.

We won’t build any UI this time, instead, we’ll use API tab to simulate sending requests from a client to the GraphQL API and see if we can get enough data to render a useful UI. Hasura prepares your server side in mere minutes. From there your efforts can go into building the client with your framework of choice like React, Vue, svelte or any other one. that interacts with the API using a GraphQL client like Apollo or urql.

Simulating various application functions

We can now start exploring application functions that’ll be triggered by different in-app operations.

First, we’ll populate the database with some mock data. This will simulate getting the first couple of users for your application and give us some data to play with. As they start using the app, users start posting photos and comments.

When we create, update, or delete data in GraphQL, we do so by sending a mutation request to the API. The data within the request exactly is then used by the backend to do the operation requested.

For example, consider the following chain of events:

• A user signs in with the necessary credentials (username, name, email, etc.) and starts using the app.Remember that the User type represents all information regarding a user.
  • For each new user, you need to add them to the server by sending a mutation request to the remote API containing those credentials.
• The user posts an image with a description.
  • It’s a mutation operation corresponding to the Post type that adds it to the database, with some data for the description field.
• Someone likes and comments on that post.
  • The likes field of that post would be increased by one. This is not adding new data but rather updating or modifying a part of it.
  • The comment corresponds to the Comment type and there’ll be a mutation request to the API with necessary data adding that comment.

The front-end of your app will have mechanisms set up to track these events (for example when you press the like button on a post), and based on the type of event, it’ll send a suitable GraphQL request to the server.

Adding some new users

paste the following mutation request:

mutation AddSomeUsers($objects: [user_insert_input!]!) {
  insert_user(objects: $objects) {
    affected_rows
  }
}

With the following JSON as the objects query variable:

{
  "objects": [
    {
        "username": "kmulbery0",
        "name": "Kimberlee Mulbery",
        "email": "kmulbery0@rediff.com",
        "about": "Art, cinema and books.",
        "avatarImageURL": "https://robohash.org/voluptatibussapientein.png?size=50x50&set=set1",
        "following": 41,
          "follower": 20
    },
    {
        "username": "foakes",
        "name": "Francis Oakes",
        "email": "foakes@liveinternet.ru",
        "avatarImageURL": "https://robohash.org/namilloipsam.png?size=50x50&set=set1",
        "following": 69,
          "follower": 40
    },
    {
        "username": "docahill2",
        "name": "Danny O'Cahill",
        "email": "docahill2@prweb.com",
        "about": "Welcome to my digital album!",
        "avatarImageURL": "https://robohash.org/quiofficiispraesentium.png?size=50x50&set=set1",
        "following": 4,
          "follower": 10
    },
    {
        "username": "karen",
        "name": "Karen Gillian",
        "email": "karen@cnn.com",
        "about": "21st century polymath",
        "avatarImageURL": "https://robohash.org/fugitetautem.png?size=50x50&set=set1",
        "following": 60,
          "follower": 22
    },
    {
        "username": "adury4",
        "name": "Anna-diane Dury",
        "email": "adury4@businessweek.com",
        "avatarImageURL": "https://robohash.org/impediteaet.png?size=50x50&set=set1",
        "following": 41,
          "follower": 100
    },
    {
        "username": "rkemwall5",
        "name": "Killian Rourke",
        "email": "rkemwall5@wired.com",
        "avatarImageURL": "https://robohash.org/etenimdeleniti.png?size=50x50&set=set1",
        "following": 67,
          "follower": 180
    },
    {
        "username": "cparramore6",
        "name": "Cirilo Parramore",
        "email": "cparramore6@biglobe.ne.jp",
        "about": "Food lover and critique.",
        "avatarImageURL": "https://robohash.org/inventorefacilisfugiat.png?size=50x50&set=set1",
        "following": 75,
          "follower": 100
    },
    {
        "username": "ff8",
        "name": "Raymond Ferdinand",
        "email": "ray@gmail.com",
        "about": "Freelance artist",
        "avatarImageURL": "https://robohash.org/ipsambeataeest.png?size=50x50&set=set1",
        "following": 1022,
          "follower": 13000
    },
    {
        "username": "shaw",
        "name": "Sebastian Shaw",
        "email": "sshaw8@mail.ru",
        "about": "Writer of useless things.",
        "avatarImageURL": "https://robohash.org/illumsintvoluptas.png?size=50x50&set=set1",
        "following": 6,
          "follower": 11
    }
  ]
}

Here we’re sending an insert_user mutation to invoke the operation. We optionally have named it AddSomeUser, but you can exclude that if you want. It’s good practice to separate the mutation data into a query variable when the data is large, as we’ve done here with the objects variable. It keeps the main query body clear and readable.

Posting some pictures on your InstaClone app

So some users have installed the app on their devices and they’re likely to start posting. So let’s simulate that! As you can probably guess, it’s going to an insert_post type mutation:

mutation AddSomePosts($objects: [post_insert_input!]!) {
  insert_post(objects: $objects) {
    affected_rows
  }
}

With query variable as:

{
  "objects": [
    {
            "username": "karen",
            "description": "A new antique book I just collected!",
            "likes": 0,
            "imageURL": "http://dummyimage.com/107x100.png/ff4444/ffffff"
        },
        {
            "username": "kmulbery0",
            "description": "Some amazing shots from the film Drive (2011)",
            "likes": 0,
            "imageURL": "http://dummyimage.com/138x100.png/5fa2dd/ffffff"
        },
        {
            "username": "foakes",
            "description": "We went on a hike!",
            "likes": 0,
            "imageURL": "http://dummyimage.com/103x100.png/ff4444/ffffff"
        },
        {
            "username": "docahill2",
            "description": "Minnie likes the sunny day today. Just look at her!",
            "likes": 0,
            "imageURL": "http://dummyimage.com/247x100.png/5fa2dd/ffffff"
        },
        {
            "username": "adury4",
            "likes": 0,
            "imageURL": "http://dummyimage.com/107x100.png/cc0000/ffffff"
        },
        {
            "username": "rkemwall5",
            "description": "Workout time...",
            "likes": 0,
            "imageURL": "http://dummyimage.com/194x100.png/5fa2dd/ffffff"
        },
        {
            "username": "cparramore6",
            "description": "Will come back here just for this burger.",
            "likes": 0,
            "imageURL": "http://dummyimage.com/161x100.png/cc0000/ffffff"
        },
        {
            "username": "ff8",
            "description": "My new concept art. Please share!",
            "likes": 0,
            "imageURL": "http://dummyimage.com/179x100.png/5fa2dd/ffffff"
        },
        {
            "username": "shaw",
            "description": "Cover photo of my book that's hitting the shelves in September!",
            "likes": 0,
            "imageURL": "http://dummyimage.com/220x100.png/dddddd/000000"
        }
  ]
}

Since they are new posts, all of them have zero likes for now. In the next step let’s simulate other users liking and commenting on them.

Adding comments on InstaClone posts

You have to know the IDs of all the posts since you’ll need that to connect a comment with the post via the commentOn field. You also need to know the usernames of existing users for the commentBy field. The following query fetches IDs of existing posts along with usernames of their posters:

query queryAllPosts {
  post {
    id
    postedBy {
      username
    }
  }
}

It gives the following response:

{
  "data": {
    "post": [
      {
        "id": "a84e5680-1659-44d6-aa38-d0c8658b327f",
        "postedBy": {
          "username": "karen"
        }
      },
      {
        "id": "dae5a80d-7cd4-4641-a6c5-58cb1844b025",
        "postedBy": {
          "username": "kmulbery0"
        }
      },
      ...
    ]
  }
}

Now we’re ready to do an insert_comment mutation to add some comments:

mutation AddSomePosts($objects: [comment_insert_input!]!) {
  insert_comment(objects: $objects) {
    affected_rows
  }
}

For simplicity, let’s assume that existing users will comment on one another’s posts. The following is the data of the query variable:

{
  "objects": [
    {
      "text": "This book's a fantastic addition to your other collections",
      "postId": "a84e5680-1659-44d6-aa38-d0c8658b327f",
      "username": "kmulbery0"
    },
    {
      "text": "It's soundtrack made me fall in love with synth and electronic music. Nightcall is goat",
      "postId": "dae5a80d-7cd4-4641-a6c5-58cb1844b025",
      "username": "karen"
    },
    {
      "text": "Minnie cures my sadness every time for the time being. What a sweetie!",
      "postId": "d6602d89-3fe5-4ffa-9ee1-d5aaeb4de329",
      "username": "foakes"
    }
  ]
}

Liking posts

Now let’s simulate the event of liking posts. As I mentioned previously, this falls under the update operation category that updates an already existing piece of data or a part of it, like someone gaining a new follower. Let’s see how this works. When someone hits the like button on a post, that event would trigger the associated mechanism and the app would use the id of the post to update its like data. It’ll use the following query to do so:

mutation LikeSomePosts($id: uuid!, $likes: Int!) {
  update_post_by_pk(pk_columns: {id: $id}, _set: {likes: $likes}) {
    id
    likes
  }
}

The query variable contains:

{
  "id": "a84e5680-1659-44d6-aa38-d0c8658b327f",
  "likes": 12
}

In this same way you can also dispatch an update_user request and set its follower field when someone gains (or loses) a follower.

Generating the application feed

The application feed would contain posts from the users someone is following. Can you guess how to fetch all the data for that?

Hasura has a robust set of search and filtering tools that you can use in scenarios such as this. Here, the app just needs to send a query post request asking for all the posts from everyone the user is following. Since usernames can uniquely identify each user, the app can use that as a filter. For example, the following fetches data from two users:

query {
  user(where: {username: {_in: ["kmulbery0", "rkemwall5"]}}) {
    username
    avatarImageURL
    posts {
      description
      imageURL
      comments {
        text
        commentBy {
          username
          avatarImageURL
        }
      }
    }
  }
}

This yields:

{
  "data": {
    "user": [
      {
        "username": "kmulbery0",
        "avatarImageURL": "https://robohash.org/voluptatibussapientein.png?size=50x50&set=set1",
        "posts": [
          {
            "description": "Some amazing shots from the film Drive (2011)",
            "imageURL": "http://dummyimage.com/138x100.png/5fa2dd/ffffff",
            "comments": [
              {
                "text": "It's soundtrack made me fall in love with synth and electronic music. Nightcall is goat",
                "commentBy": {
                  "username": "karen",
                  "avatarImageURL": "https://robohash.org/fugitetautem.png?size=50x50&set=set1"
                }
              }
            ]
          }
        ]
      },
      {
        "username": "rkemwall5",
        "avatarImageURL": "https://robohash.org/etenimdeleniti.png?size=50x50&set=set1",
        "posts": [
          {
            "description": "Workout time...",
            "imageURL": "http://dummyimage.com/194x100.png/5fa2dd/ffffff",
            "comments": []
          }
        ]
      }
    ]
  }
}

You have the usernames and their associated avatars, and their posts with images, descriptions and comments. They’re all you need to render the feed.

Conclusion

In this article, we learned how to use a GraphQL schema to model an application’s data and bring it under an explicit structure defining its various data objects and relationships. Later we saw how to process various requests to fetch and modify data. GraphQL is the perfect tool to use in social media applications where data is highly connected and you need to traverse these graphs to compose satisfactory responses for the request traffic.

Hasura makes GraphQL super-easy like none other by bringing you a production-ready GraphQL API and corresponding database just from a single schema. It gives you a highly scalable way to meet your application’s evolving set of requirements. No need to write API boilerplates, then get distracted in connecting layers and tools to get the server side ready.