How to represent the recycle (soft-delete) and restore objects in Feathers?

[koteisaev]

Hello!
I am completely new to Feathers, and while I explored the website and blog posts about Feathers concepts, I noticed that only scenario of hard (permanent) delete of data is covered.
What if one of business requirements is to support soft-delete, to easily recover an item deleted by mistake.
The retention policy for recycled content does not matter so far for context of this discussion.

[bwgjoseph]

Take a look at soft-delete

Technically, it's only a flag that you toggle to make it soft-deleted or restored

[J3m5]

Personnaly, I would use a property like deletedAt with a date, like you would have createdAt or updatedAt with mongoose.

Then if you want to only return non deleted records, you can add a hook that would modify the query with deletedAt: null if it's not already set.

[koteisaev]

Both your answers are good, especially combined together.
But they miss one point actually key to my question.
If you will take a look at common list of methods at a typical service and a blog article describing the resource concept the Feathers service seems to be following, there are these verbs (actions that can happen with data:

find - Find all data (potentially matching a query)
get - Get a single data entry by its unique identifier
create - Create new data
update - Update an existing data entry by completely replacing it
patch - Update one or more data entries by merging with the new data
remove - Remove one or more existing data entries

This was quote from https://docs.feathersjs.com/guides/basics/services.html#feathers-services

I just do not see a built-in way in feathers to have methods set like this instead:

softDelete - soft-delete, with marking objects as soft deleted
restore - removing soft deletion flag
erase - completely remove data regardless of soft deletion status (e. g. to process a user data erasure request or to erase object with expired soft-deleted retention period).

is there a way to add new "verb" to Feathers service contract, and map it like this in REST transport:

DELETE /api/:resource/:id - soft delete data item
PATCH /api/:resource/id/restore - restore soft-deleted data item 
DELETE /api/:resource/id/erase - permanent deletion of data item

Or in this way:

PATCH/api/:resource/:id/recycle - soft delete data item
PATCH /api/:resource/id/restore - restore recycled data item 
DELETE /api/:resource/id - permanent deletion of data item

I do not want to reinvent whole new branch of Feathers or reinvent whole new library just for this aspect :)
This is why I look for some more Feather-ish way to implement/achieve this.

[J3m5]

What we do is having a before remove hook that call the patch method to add the date to the deletedAt property and then set the context.result property in order to skip the acutal remove call.

[J3m5]

I would avoid to add HTTP verb or special routes, I'd prefer to stay as close as the HTTP spec and keep the soft delete logic hidden from the user.

[koteisaev]

What's wrong with doing a PATCH/api/:resource/:id with { deletedAt: null } to restore it?

What if some additional logic must happen only on recycle/restore?
E. g. journal entry must be added on what/who/when has been recycled/restored/deleted?
I do not want expose these additional activities and do not want allow to modify these special fields like recycledAt or recycled by patch function/method.
Saying I must to

PATCH /api/:resource/:id `

with

{ recycledAt: null }

is opposite to

keep the soft delete logic hidden from the user

While these

PATCH /api/:resource/:id/recycle
PATCH /api/:resource/id/restore
DELETE /api/:resource/id

is fully within HTTP spec and I am more not about transport specific aspect, but more about support of such common aspects at service layer explicitly.
I need to be able to do something like

await app.service("tasks").recycle(taksId);
await app.service("tasks").restore(taksId);
await app.service("tasks").erase(taksId);

and be sure these methods will be widely available across all data-centric services within Feathers app.

[J3m5]

If the users of your api can restore items by using their ids, that means that for them, it's not really deleted, it's disabled, or hidden.
In our case, when a user delete an item, at their point of view, it is effectively deleted, they wont be able to get it again.
This is what I mean when I say that this logic is hidden.

It is not used as a delete/restore feature but as a safety mechanism and a way for us to analyze and get stats about the data.
But, in certain cases we have a feature that let users disable/deactivate/hide items and reverse it if they need to.
When they want to, the request sent just set the property disabled to true or false.

So in our case we don't need these recycle or restore methods/path because only admins can revert the deletion by patching the items, which is permitted only because they have the permissions to do it.
Editing the deletedAt property is not permitted for the normal users, any values received via the PATH, UPDATE or POST methods will be discarded unless the user has the permission to modify it.

And to respond to your question

What if some additional logic must happen only on recycle/restore?

You add a hook that handles it when the value is modified by checking if the property is defined or not and it's value.

[J3m5]

If you still want to have specific methods to deal with this logic, the next version of feathers will let you define custom methods on services.

[robbyphillips]

I need to be able to do something like

await app.service("tasks").recycle(taksId);
await app.service("tasks").restore(taksId);
await app.service("tasks").erase(taksId);

Any service class can be extended with additional methods.

// things.class.ts
// where `Service` is the database adapter
export class Things extends Service<IThing> {
  constructor(options, app) {
    super(options)
  }

  async remove(id: NullableId, params: Params) {
    // override remove implementation ...
  }

  async recycle(id) {
    // ...
  }

  async erase(id) {
    return super.remove(id)
  }
}

With this, app.service('things').recycle(id) is available anywhere in the app. If you want to have those methods available on all your CRUD services, you could make a new db service class that extends the one provided by the adapter.

The "catch" here is that (at least in v4), those methods are internal-only and do not have any hooks.