API Platform with alternative Runtime, Caddy, Vulcain, Cache ecosystem

608 Views Asked by At

Currently I'm investigating a setup backed by api-platform with the following goals:

  • the PHP backend MUST yield minimal resource payloads, thus I do not want to embed relations at all
  • the PHP backend SHOULD be able to run in alternative runtimes, e.g. Swoole
  • the webserver should push related resources via HTTP2 Push leveraging the built in vulcain support of the api-platform distribution

I cannot find that many resources about those setups - at least not in such a form that they answer subsequent questions sufficiently.

My starting setup was simply based on the api-platform distribution 2.6.8

So, until now I've learned the following things:

  • out of the box, the caddy + http2 push setup works with the PHP container being based on php:8.1-fpm-alpine - while caddy is obviously directly using php_fastcgi
  • when I was fooling around with the currently available cache-handler I was able to get the http cache working but I was struggling to find any information about cache invalidation works. The api-platform docs mostly focus on varnish; there is also only a VarnishPurger shipped in the api-platform core. Wring a custom one should not be that hard if the caddy cache-handler somehow allows BAN requests or something similar - where to find info about that? I see that the handler is based on Souin - but as unfamiliar as I am I have no clue how (and if) Souin supports cache invalidation after all.
  • when changing the php container to be (in my current testing scenario) based on Swoole then php_fastcgi cannot be used in caddy - instead, I ended up using reverse_proxy (as described in vulcain docs) which basically works and serves proper http responses but does not push any resources requested with Preload headers (as I said, it worked when the PHP backend was based on PHP-FPM). How can I debug what happens here? Caddy does not yield any info about the push handling - nor does the vulcain caddy module

Long story short(er): to sum up my questions

  • how can I figure out why caddy + vulcain is not working in a reverse_proxy setup?
  • is the current state of the caddy cache handler functional / supported by the api-platform distribution
  • how to implement/support BAN requests (or other fine grained cache invalidation) for caddy cache handler?
1

There are 1 best solutions below

0
On

Souin supports the invalidation using the PURGE HTTP method. I already wrote a PR to set Souin in the api-platform/core project but they are busy with the v3.0 release. Maybe in a near future they'll review and probably merge it, I dunno. But if you use a decorator on the varnish purger and use the code I wrote in the PR, you'll be able to purge automatically the associated endpoints to the base route.