You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Being able to extend the functionality of an Atomic Data Server can be very useful.
I've already written quite a bit on plugins, mostly in the atomic-data-rust repo in this issue and these tagged issues.
Usecases:
Automatically import things from some we service (e.g. import rss articles for an rss reader)
Use a custom / possibly external authorization mechanism (e.g. active directory)
Add custom, dynamic properties to resources (e.g. show who the author is of some resource by checking commits)
Add an endpoint that does things (e.g. an endpoit that serves Atomic Data events asiCal calendar items)
Hooks / handles
We need some way of knowing when a plugin should be executed. I think having a bunch of hooks is the way to go:
onCron (cron jobs, exectutes every X time)
beforeCommit (e.g. extra authorization checks)
aftercommit (e.g. additional indexing logic)
onRequest (e.g. extend a resource, or create some custom endpoint)
For many of these hooks, it makes sense to standardize conditional logic. For beforeCommit, for example, we might want to check if some properties in the resource are present. We could also keep this check logic in the hook itself, but then we'd need to call all of the hooks, always for every resource. If instantiating the plugin itself is costly, this could dramatically impact performance.
The text was updated successfully, but these errors were encountered:
Being able to extend the functionality of an Atomic Data Server can be very useful.
I've already written quite a bit on plugins, mostly in the
atomic-data-rust
repo in this issue and these tagged issues.Usecases:
iCal
calendar items)Hooks / handles
We need some way of knowing when a plugin should be executed. I think having a bunch of hooks is the way to go:
onCron
(cron jobs, exectutes every X time)beforeCommit
(e.g. extra authorization checks)aftercommit
(e.g. additional indexing logic)onRequest
(e.g. extend a resource, or create some custom endpoint)For many of these hooks, it makes sense to standardize conditional logic. For
beforeCommit
, for example, we might want to check if some properties in the resource are present. We could also keep this check logic in the hook itself, but then we'd need to call all of the hooks, always for every resource. If instantiating the plugin itself is costly, this could dramatically impact performance.The text was updated successfully, but these errors were encountered: