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
Developers often want to react to modification happening in the database directly from the backend side.
If modification are made from the API then we can use pipes (generic:document:* events) or a realtime subscription.
If modification are made from the backend, we can only use realtime subscription.
Generic Document events could always be triggered, even if it's from the backend so backend developers can plug pipes on those events and react on every database modification
The text was updated successfully, but these errors were encountered:
I completely agree on this. If I remember well, the choice of not triggering those events when updates came from the backend itself, was in order to prevent infinite loops provoked by hooks or pipes that would re-trigger the same event.
IMHO, we can leave this responsibility to the end-developer and just warn them in the documentation. Does this make sense to you?
Yes totally. It still can be a friction point for developers debugging infinite loop but if there is only one category of events that may cause this and if it's well documented then I think we can do it. Specially because it adds a lot of value
Feature Description
Developers often want to react to modification happening in the database directly from the backend side.
If modification are made from the API then we can use pipes (
generic:document:*
events) or a realtime subscription.If modification are made from the backend, we can only use realtime subscription.
Generic Document events could always be triggered, even if it's from the backend so backend developers can plug pipes on those events and react on every database modification
The text was updated successfully, but these errors were encountered: