| CLARIFICATION TO ARTICLE Hello, it's me, the author! I'd like to take the time to clarify a few things about the article. I'm not claiming this to be revolutionary to all people, I'm just claiming it to be useful for some people. The intent of the protected query pattern is the following: - Co-locate query and authorization logic (easier to maintain)
- Allow (but not require) inner functions to be pure (e.g. trivial to cache with upcoming Next.js "use cache" API).
- Allow easy bypassing of authorization for some contexts.
- Simplify logic elsewhere (e.g. getDocument.protect("id") is a pretty one liner). In most cases, I use the protector pattern to either allow or disallow the entire query, based on the results. Filtering or redacting the data is done much more rarely. † What I did NOT intend: - I did not intend to select all rows and return only the useful. You are right, that would be horrible for performance. However, I understand how easy it is to come to that conclusion, seeing how I introduced the Kilpi.filter function. Thank you all for your feedback, this allows me to improve on this pattern and Kilpi in general! † Your worries about performance have given me ideas of a new "preprotector" function that would stop the query before it ever even starts. I'll have to think about adding it in the future! |