Feature: Hooks for Records API

[sasupp]

Would love to have hooks for before and after Record API execute. This will help in adding custom validation, record transformation and run custom code.

[ignatz]

Agreed. I've been thinking about WASM-based midleware as well. Did you have WASM in mind or are you using TB as a framework?

[sasupp]

I had WASM middleware in mind as I can easily extend TB without changing its core functionality which it executes flawlessly.
In its current form, the WASM middleware doesn’t have access to a lot capabilities of TB.
PocketBase has hooks for everything but I think TB can get very far by just adding basic hooks like access to Record before the request executes to provide custom validation which can not be easily added to SQLite checks, or may be custom rate limiting etc. The after hook can be used to trigger external workflows like email, a cron job etc.
I feel that just these two hooks cover a lot of ground.
Also, I would love to have email library added to WASM as well to trigger emails on custom handlers or hooks.

[ignatz]

PocketBase has hooks for everything but I think TB can get very far by just adding basic hooks like access to Record before the request executes to provide custom validation which can not be easily added to SQLite checks, or may be custom rate limiting etc. The after hook can be used to trigger external workflows like email, a cron job etc.

FWIW, I agree with the usefulness, I did already have this in my private backlog.

Also, I would love to have email library added to WASM as well to trigger emails on custom handlers or hooks.

I agree that that makes sense, too. Let's keep it to: #199

I feel that just these two hooks cover a lot of ground.

Probably. As a lazy excuse and to be transparent, I've been holding off to extend the WASM entry-points too, much since I've long been hoping that WASIp3 will be released any day now :hide:. Especially, since such hooks should probably be async to allow for I/O.

Tangentially, I sore point I've been pondering about is API evolution. Specifically, could such an interceptor/middleware model help. Or more generally what's the happy path to evolving schemas and APIs in various forward and backward (in)compatible ways.