Graphql-engine: Tracking node deletion using subscriptions

[egislook]

Is there any easy way to track the node deletions? In graphcool engine they had mutation (created, deleted ...) and previousValue fields. Does hasura support something like this?

[coco98]

@egislook Hasura GraphQL subscriptions are more like live-queries so you can implicitly get information about if something got inserted, updated or deleted. We do this because sending events to a web-client (browser/mobile) is usually not reliable. For example if the wifi connection broke, you might miss the delete event that the server sent. It's easier to subscribe to a live-query so that whenever you reconnect you always have the latest result "state".

However, this info is super easy to capture on the backend with Hasura. If you want to know when rows/nodes getting updated/deleted, you should use the event triggers. https://docs.hasura.io/1.0/graphql/manual/event-triggers/index.html
It's super simple to try out.

1. Add event trigger
2. Choose the table you want to listen on
3. Set the webhook to https://httpbin.org/post as an example to see what the payload looks like (old value, new value, operation type etc)

Can you talk a little bit about the specific use-case you're trying to solve? We should be able to recommend the easiest way to do it with Hasura :)

[JeetChaudhari]

@coco98 I really like the idea of using live queries as the subscription. I remember we had this kind of functionality in fireloop.io which was discontinued. However, I think it is important to know what actually changed whenever subscriptions get an update.

For example, let's say we have displayed table full of records on the front end and subscription changed some entry into it. Now there is no way we can know which record was changed and what was changed in it if we want to highlight updated record or do something else.

We can do this by saving the previous array into another variable and comparing those values with changed values but I think this is not a clear way to achieve this functionality. Also, as you mentioned about webhooks and triggers it is just not ideal if we need this kind of functionality for multiple tables in the database for multiple view pages on front-end application.

I would like to propose one solution to this problem.

For any live query subscription, Hasura API should have subscriptions like below.

subscription {
  todos {

    # live query response wrapped in nodes
    nodes {
       id
       description
       dueAt
    }

    mutation {

      # type would contain string CREATE/UPDATE/DELETE
      type

      # node values before update/delete, in case of create, it should be null
      previousValue {
        id
        description
        dueAt
      }

      # node values after update/create, in case of delete it should be null
      currentValue {
        id
        description
        dueAt
      }
    }
  }
}

We can even allow filter for a subscription if the client only needs to know newly created/updated/deleted nodes. This kind of feature exists in Prisma without live queries. If we implement this, it would be the best of both worlds.

[0x777]

Closing this in favour of #2317.