Requires Trucaller app be installed on the device, beyond this, no information on what activity or information the app itself gathers, only mentions they don't track your app's activity, which is meaningless in context.
No clear information on the Trucaller revenue model at all, and unclear on any other potential gotchas.
You're probably better off using Twillio or another SMS backend with OTP verification methods in practice. Aside: I just don't trust outsourcing your authentication, I think it's a bad idea to literally outsource your user access and has so much potential for abuse. Similarly I wouldn't recommend using Firebase or Auth0 as primary authentication interfaces either.
In addition to #3
let { propToRemove, ...newObj } = oldObj;
then throw away the propToRemove.
Also, if you are serializing and set the value to `undefined`, then it won't be JSON stringified into the output.
Nice intro to hashing and bcrypt library. I've tended to favor pbkdf2 lately, mostly because it's "in the box" and has generally been a hard requirement (NIST recommended) for some of the work I do (government clients).
I would suggest considering going to 12 rounds over 10, if your deployment server can handle it. It does become a potential DDoS attack vector if you aren't tracking/limiting failed attempts by user and IP.
I'm not a fan of RxJS for several reasons. RxJS is pretty big in and of itself for what it does, and I find the Redux patterns easier to reason with the larger your application gets.
Definitely cool for those that know JS but not lower level languages and/or not experienced in sorting algorithms. However, most languages (including JS) already have sorting algorithms, some work better in most scenarios than even quicksort.
Second, the code formatting is entirely missing, and is nearly impossible to reason with in the article.
LOL... I once worked on a system where database records were inserted with a spacing of (1,3) so that there were intentional gaps... this was then encoded base36, and with a non-standard character order. The idea was to limit casual users from changing the /path/to/:id ... it worked pretty well in practice. It was emphatically NOT encryption though, just obfuscation, there was no real risk involved.