Deleting vs. Destroying Records on the GraphQL API

Sebastian (00:03)
Hey, everyone. My name is Sebastian. In this episode, we're going to be looking at the difference between deleting and destroying records when using back end. When dealing with delete versus destroy, we're really dealing with the concept of soft delete versus permit deletes or hard deletes. What that's doing is that's allowing us to, in a more dynamic way, determine whether or not we really want data permanently deleted from our database or whether we just want certain records not to be returned any longer inquiry results.

Sebastian (00:35)
The way that that's implemented in eight days is that on every record that you create in your data model or in your database, it stores or has a field value or a field type on there called deleted that. We can actually look at that right here inside the API Explorer. I'm going to query back a list of records from a table called tasks, so the tasks list operation. For each task that we're getting, we want the ID of the task, the title of it, and the deleted at field.

Sebastian (01:10)
Now if we run this query, we can see that the delete that field is returning zero on all the returned records, and that's expected, because none of these records have ever been deleted. Now if you were to delete one of them, all this would actually be doing is adding a timestamp or the epoch for the timestamp to this value, and then the system would know, "Hey, in future requests or queries do not return that record any longer. It's been deleted."

Sebastian (01:38)
Now we can actually try that right now. I'm going to take this record ID and we're going to run a mutation that deletes the super important thing 1. Let's run a mutation that is a task delete mutation, and we're going to give it the data of the task we want to delete, which is the ID. Drop that in there. Then as a response, we just want a success response. I run that and it was successfully deleted.

Sebastian (02:09)
Now if we rerun the last query that we did, which was the history here, cool, we can now see that super important thing 1 no longer exists. However, if we were to pass a special argument to our query called with deleted and set that to true, we would now be getting all of the deleted tasks that are still stored in our database, just hidden from our query results. Now we can see that super important thing 1 was deleted at this time stamp.

Sebastian (02:46)
Now what we can do if we wanted to is restore that record. Once again, I'm going to write a mutation here which is a task restore operation. It's going to ask me for the ID of the record, which I can provide. Here I can say, "Well, I want the ID of that record, I want the title and I want the new deleted that value."

Sebastian (03:08)
Once I go ahead and do that, I run that request and we can see that that record was successfully restored, so the delete that time stamp is now back to zero. Any subsequent query that we run, let's just run that one again, boom, super important thing 1 is back in our database.

Sebastian (03:31)
Now when it comes to permanently deleting records, it's permanent delete. Once we do it, that is no more. That is a destroy operation. Essentially what I can do here now is I can take the ID of the record and say, "Well, I want to run a mutation where I actually destroy this task." Meaning if there is no recovery.

Sebastian (03:55)
I'm going to run the filter and say that the ID is the filter for the record and we want a success response back. Now if this record had dependent relationships, we'd also want to specify the force flag to say that destroy it and then destroy anything that has a mandatory relationship to it. However, we're not going to do that right now.

Sebastian (04:18)
I'm going to run destroy. It was successfully destroyed. Now we can see that if we run the tasksList query, super important thing 1 is no longer in our result as well as if we're we run it with deleted flag, which is right there, is also no longer existing.

Sebastian (04:41)
There's a lot of different examples to where you might want to leverage this type of facility. A simple example such as allowing someone to delete a simple record but having the system be able to restore it. You could set up a task potentially which looks for any record deleted within the last week and only destroys them after that time, so you can give someone seven days to restore something or even more complex use cases to where maybe you have some type of social network and you want to allow users to delete their accounts.

Sebastian (05:10)
However, all the data that they had associated with their account, you want to be able to restore if they decide to rejoin, and there's a lot of different ways that you could architect and design that system. However, hopefully this was helpful and gave you some good ideas of cool features you can build into your applications. Feel free to subscribe to the channel if you would like to get into to updates on future videos. Happy developing. See you in future episodes.

‍