How to model user,posts and likes on dgraph?

[amaster507 (Anthony Master)]

@Raju_Rastogi

type User{
    posts: [Post]
    likes: [Like]
}

type post{
    likes: [Like]
    author: User
}

type Like{
    time 
    Likeby User 
    LikedOn Post
}

^ this must not be your exact schema then… your schema most likely has LikedBy: User! and an id field

So if you want to get the likes only by a specific user then apply the filter and cascade. Or rearrange the query:

{
  queryLike @cascade {
    id
    likedBy(filter: {username: {eq: "test"}}) {
      username
    }
  }
}

{
  queryUser(filter: { username: { eq: "test" }) {
    likes {
      id
    }
  }
}

@Raju_Rastogi

With dgraph, we can only search on primitive fields.

See for reference of work in progress/RFC:

RFC: Nested Filters in GraphQL

Motivation There are many requests from the community to add nested filters in GraphQL and it’s also one of the feature which can add more flexibility and value in our GraphQL implementation. Nested Filters like below are not supported in GraphQL . query { queryAuthor( filter: { name: { eq: "Alice" }, or: { posts: { postID: ["0x1", "0x2"] } } } ) { name posts { title } } } Although in DQL this Query is possible using var blocks like below query { post1 as var(…

@Raju_Rastogi

When the user unlikes it we update it so that if a user likes it again we don’t send a notification.

This is business logic and there are several different ways to handle it. Each different way to implement this has its own tradeoffs. do you want to store a list somewhere of sent notifications, or do you want to perpetually store a Like with a delete boolean field that you change if a user deletes the like, but you keep the node itself. But then you have to factor that in when counting likes for posts… This is what makes every schema structure unique and why not every schema is the same because of business logic like this and how the developer wants to handle unique edge cases.