Best practice to virtually "delete" data in Node.JS Applications!

[goldbergyoni]

Best practice to virtually "delete" data in Node.JS Applications!

[BrunoScheufler]

Well I think that really depends on the data source you're using. Whether you use SQL or NoSQL databases like MongoDB etc. greatly changes the result

[elouizbadr]

@BrunoScheufler I am using the MEAN Stack so it's NoSQL with MongoDB.

[goldbergyoni]

@elouizbadr interesting and relevant case.

can you elaborate on your specific use case: what data, why not simply delete physically, what constraints (e.g. have 5B records, deleting will overaload the system)

Milestone added

[elouizbadr]

@i0natan Thank you for considering this matter.

I am working on project that automatically deploy applications that were developed by company teams, to a private cloud hosted on a 3rd party provider. I have data objects like Servers, Infrastructure, Applications, Instances ... etc. The issue here is that I want to protect data from being deleted accidentally and for further restoration. Even though on my AngularJS Front End the admin should confirm every time he clicks on the "Delete" button, but that's not sufficient.

Me and my team have talked about email confirmation, using separate MongoDB collection for "deleted" stuff,or even a complete separate database for them ... and so on.

In addition to that, Users may want the "undo" or "redo" functionality so it's relevant to this issue.

[syzer]

@elouizbadr
The historical tables for mongo collections are quite common solution for that case.
there are plugins for most mongo object mappers that do that automatically

The downside is that adds so much IO overhead.. but it might not be important in that particular case.
Example if your organisation uses ruby python it would not notice performance difference.

Also I would highly recommend reading about lenses, clojure, and immutability in general
and about using event sourcing.

For also using redux/flux/graphql architecture (AKA event sourcing/modern stack), would solve your particular case.

But every case is different, so would go with lazy-ass solution(historical tables) and change architecture only when you need specific needs.
ex: transactions

[elouizbadr]

@syzer Very grateful for your comment and suggestions.

I'll check on every one of your suggestions in order to choose the one that fits my project requirements.

[syzer]

Generally functional approach to Undo is trivial.
OOP is quite complex.
Do not forget about transaction support if its required.

[goldbergyoni]

@syzer covered it perfectly. Simply put event sourcing or any kind of append-only (doc per-version, no updates, avoid calcualting deltas) seems like the sweet spot between implementation complexity and performance (sacrifice storage but you can work around this with periodical deletion).

This post summarizes it well:
http://www.askasya.com/post/revisitversions/