# Feature Request: Access Deleted or Changed Data in Lambda Webhook

**URL:** <https://discuss.dgraph.io/t/feature-request-access-deleted-or-changed-data-in-lambda-webhook/14800>\
**Category:** GraphQL\
**Tags:** kind:enhancement, kind:feature\
**Created:** [July 2, 2021, 2:32am UTC](https://discuss.dgraph.io/t/feature-request-access-deleted-or-changed-data-in-lambda-webhook/14800 "2021-07-02T02:32:24Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![jdgamble555](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/jdgamble555/32/7503_2.png) [@jdgamble555](https://discuss.dgraph.io/u/jdgamble555)\
**Post date:** [July 2, 2021, 2:32am UTC](https://discuss.dgraph.io/t/feature-request-access-deleted-or-changed-data-in-lambda-webhook/14800/1 "2021-07-02T02:32:24Z")

</div>

## Experience Report for Feature Request

### What you wanted to do

Get access to deleted or changed data **BEFORE** it is deleted or changed in order to run backend validation.

Let’s say I want to verify the incoming data in an **update or delete** mutation is in a certain format. An email address may have a regular expression, or I made need to do some complex regular expression etc.

If that validation fails, **there is no way to revert back to the old data**. This defeats the purpose of of a webhook in a lot of cases.

### What you actually did

I can’t do anything to revert the data… the data has already been changed or deleted…

```typescript
async function updateAuthorWebhook({event, dql, graphql, authHeader}) {
    // event object has the add.input to do some validation
   if (complex regex...) {
    // event object has rootUIDs, but the data is already changed
    // so no way to run a graphql mutation to revert back the data
    ...
}

```

### Why that wasn’t great, with examples

There are no **pre-hooks** , but there is **another way** besides pre-hooks.

> [@Webhook (Lambda) on add/update/delete mutations](https://discuss.dgraph.io/t/webhook-lambda-on-add-update-delete-mutations/12904/9):
>
> Pre-hooks over lambda will add cost in terms of mutation latency, as they would require Dgraph to suspend the mutation until the network call from lambda doesn’t return.

While I disagree because it is ultimately my cost, I certainly understand your point of view. However, here is what you could do to fix this:

Firebase Functions are ultimately **post-hooks** like Dgraph Webhooks. However, they give you access to the changed data so that you can revert back to it if you need to.

There are also cases where you don’t need the original data to revert back to anything, but you need the original data for something else, maybe to create new data. There are many problems here.

### Any external references to support your case

> **[Webhook (Lambda) on add/update/delete mutations](https://discuss.dgraph.io/t/webhook-lambda-on-add-update-delete-mutations/12904/8)**
>
> I just gave it a spin locally and it works great. Thanks.

Here you can see a **before** and an **after** change variable in firebase functions:

[https://firebase.google.com/docs/reference/functions/cloud\_functions\_.change](https://firebase.google.com/docs/reference/functions/cloud_functions_.change)

There are also dozens of posts here referring to the pre-hook scenario…

J

---

<div class="post-metadata">

**Author:** ![iyinoluwaayoola](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/iyinoluwaayoola/32/4282_2.png) [@iyinoluwaayoola](https://discuss.dgraph.io/u/iyinoluwaayoola)\
**Post date:** [July 2, 2021, 3:53am UTC](https://discuss.dgraph.io/t/feature-request-access-deleted-or-changed-data-in-lambda-webhook/14800/2 "2021-07-02T03:53:13Z")

</div>

I’m in favour of both pre-hook and having the pre-existing data in Lambda Webhook. It’s necessary to have a pre-hook anyways, otherwise, there is no way to perform pre-validation beyond @auth. I also see pre-hook useful for adding auto fields. My use case for having change data in webhook is to keep track of updated records for audit reasons. In other words, when a node gets updated, I like to record what changed. Although the update event (post-hook) will contain the mutation record, there is no way to determine what actually changed. I now store everything which is far from ideal. This issue can also be resolved by using pre-hooks, as it will give access to the incoming update, while the existing record can be queried.