Moved event emitter middleware to api app #10233
Conversation
|
Really nice PR description/context 👍 I was wondering if the site.changed event needs to be triggered for v0.1 changes anyway? In general: we should finish up #10060 asap 😁 |
|
This change seems logical to me as |
We can decide to go either way here, It doesn't need to work with v0.1 necessarily. But since currently we have not made explicit that new webhook is limited to v2 APIs, and also since there is no side-effect or changes needed in v0.1 APIs to make it work, I thought it made sense to allow it to avoid confusion. 😄 Wdyt @kirrg001 ? |
closes TryGhost#10226 - Middleware emits site-changed event used to trigger webhook, was configured to v2 admin api only. - Change allows all versions of api to emit event in case of cache invalidation
rishabhgrg
force-pushed
the
site-change-event-update
branch
from
d0a622c
to
3eeba67
Compare
closes #10226
site.changedevents from v2 admin api to apiApp.Context
We added a new webhook recently which is triggered on
site.changedevent. The middleware responsible for emitting this event was configured directly to v2 admin api as Admin client was already updated to use v2 APIs.Problem
While most of the APIs were moved to v2, the post-scheduling adapter is still using default API set which is v0.1 currently. So any scheduled post is published via old APIs which in turn does not trigger the event/webhook for
site.changed.FIX: Moving the emit-event middleware one level up to api app, so it listens to all API response across api versions and fires
site.changedevent/webhook when needed. Afaik it shouldn't have any side effects on existing event flow as its based on cache-invalidation header in response. The alternate is to narrow it down and add the middleware directly to v0.1 app but till the time we don't have api version specific middleware for this event, it made more sense to add it here.