Good morning all, we have a feature that needs to make a Zed request from Yves _after_ Yves has sent

UKEP86J66

Good morning all, we have a feature that needs to make a Zed request from Yves after Yves has sent the response. We do this so Yves TTFB is not effected by the Zed call. In the Spryker silex days we used the Silex finally hook and this worked well. For the latest version of Spryker we switch to using the KernelEvents::TERMINATE in a EventDispatcherPlugin . This does not work anymore as the session is now closed (in the KernelEvents::RESPONSE event), so the Zed call does not have access to currency, locale, etc.
We have a workaround to prevent the session closing in the KernelEvents::RESPONSE but not 100% sure if this is safe or future-proof. Has anyone got recommendations for this type of feature?

U01G4K5E0J2

Im not sure such solution would meet your requirements, but you could call zed in order to add an event to queue.
This way you are not waiting for any operations Zed would perform
But you still have to wait for Zed response,
Don't know if this works for you

UKEP86J66

Yes that would work, but it would still make a Zed request before the Yves response is sent so could still add ~100ms to TTFB. So ideally we want to make this Zed call invisible to customers 🙂

Andriy Netseplyayev

Hey Rick, could you elaborate a bit more about your use case - what are you trying to achieve by calling Zed after Yves has sent the response?

UKEP86J66

Yes sure - it's a bit specific to our infrastructure.
We are caching some Yves templates to improve TTFB as we have large amounts of CMS content. We are storing the cache in redis and our Yves servers all have secondary redis instances. The primary redis is running on the Zed server. For security reasons we cannot expose the primary redis details on the Yves servers so we make the Zed call, so Zed will update the primary redis and this will then send the cache data to all of the secondary Yves instances.

UKEP86J66

This is only when the cache is cold, but we still want this update to avoid any impact to customers.

UKEP86J66

If our infrastructure was different we could make the update directly from Yves.

Andriy Netseplyayev

..and so if page content is not found in Yves’s redis, you send Zed request in order to re-publish?

UKEP86J66

Kindof - if page content is not found in Yves redis we render the template in Yves and sent the response, then we send the new cache html to Zed for Zed to persist in the primary redis

UKEP86J66

And hi Andriy! 😉

Andriy Netseplyayev

alright, I’m wondering if that (syncing) can’t be achieved some how on the infrastructural level, or outside of the Yves request flow.. maybe some scheduled job or even “lambda-function”-like implementation that would monitor redis and “sync” things back to the master one. Just as some more ideas on the table. Your solution is also quite a working one here

UKEP86J66

We did consider that approach but with multiple frontend Yves servers it would be complex, and the original issue was not exposing the primary redis details on Yves servers. The feature is working well on production which is still on the silex version, we have just hit this problem while working on upgrading to the latest version.