|
|
|
|
|
|
by ajahahxbbd
450 days ago
|
|
|
1. Is this filtering after returning results from the database? That seems horribly inefficient in most cases. Most databases should support filtering the data before you return it. Or APIs or whatever. 2. How are these functions now “pure”? I dont think things are magically catchable because you removed some auth logic. It’s just a little simpler to cache, though if the auth logic data doesnt change often it’s not much different. |
|
|
1. While yes, this would allow you to `SELECT * FROM table` and then filter on your server. However, I believe that most developers are aware that that is, as you said, horribly inefficient. For performance, you would definitely make your queries only return the authorized data.
(Although, now that you've mentioned it, I'm starting to think of a "pre-protect" API to stop the query before it ever even runs in the first place, which would solve the performance issue.)
I'm sure this won't suit everyone, however I've found it a very helpful pattern in my experience. In most cases in my apps, that the protector is only a safe-guard for exceptions, and the app would function securely even without protectors. However, they add an extra layer of security and confidence.
2. The function returned by Kilpi.query is not pure, however the inner function is pure. For example, considering the upcoming Next.js "use cache" directive, you can add it to the inner function wrapped by Kilpi.query and it just works.