Builtin cache invalidation system aka make API Platform fast as hell #952

dunglas · 2017-02-20T11:58:03Z

Q	A
Bug fix?	no
New feature?	yes
BC breaks?	no
Deprecations?	no
Tests pass?	yes
Fixed tickets	n/a
License	MIT
Doc PR	todo

The usual quote:

There are only two hard things in Computer Science: cache invalidation and naming things.

-- Phil Karlton

Well, API Platform is an awesome name, so this PR try to solve the other hard thing: caching to make your API as fast as possible.

It introduces a builtin mechanism to always serve API responses from a cache (Varnish and CloudFlare are targeted), and invalid stale data in real time when a resource is updated, deleted or created.
With this mechanism, on my computer and using Docker, large and complex responses are served in ~15ms instead of ~700ms without cache.

The API Platform serializer has been tweaked to store the list of all resources included in a given response (the root document, but also embedded documents and documents appearing in lists).

The response is marked with all resources it contains in the Cache-Tags HTTP header. A md5 hash of all included IRIs is generated to prevent collisions and reduce the header size.
Then, all API's responses are stored with a high expiration time in the proxy cache. On all subsequent (read) requests from a client, the response is served from the proxy, the PHP application is not touched.

When a resource is modified (only changes made to Doctrine entities are supported for now), all responses containing or referencing it are purged from the cache.
A class to purge Varnish is provided in this PR, and a class to purge CloudFlare (enterprise plans only) will be provided later. An interface allows to add support for other cache providers.

Paged collections are also handled: if a resource is added or removed, all collection pages are purged. If a resource is edited, pages (and all other API responses, including those embedding it as a nested document) are purged.

Enabling this new feature doesn't require to change existing code. The following config enable the mechanism and mades your API instantly blazing fast:

api_platform:
    http_cache:
        enable_tags: true
        varnish_url: 'http://my-varnish-proxy'
        shared_max_age: 3600

I've also opened a PR to add Varnish with a compatible setup to the API Platform Docker setup: api-platform/api-platform#238.
Last but not least, this PR introduces some config options to set global cache settings. Example:

api_platform:
    http_cache:
        max_age: 60
        shared_max_age: 3600
        vary: ['Content-Type', 'Cookie']

Note: for advanced needs, prefer the awesome FosHttpCache library.

As stated in the quote, cache invalidation is a hard thing and this PR probably contains bugs and edge cases. Please test it and report any problem.

TODO:

Add unit tests

dunglas · 2017-02-20T12:03:49Z

src/HttpCache/EventListener/PurgeListener.php

+     *
+     * @param GetResponseForControllerResultEvent $event
+     */
+    public function onKernelView(GetResponseForControllerResultEvent $event)


Probably useless because it is already handled for Doctrine and not reliable enough for non-Doctrine data providers.

dunglas · 2017-02-20T12:04:06Z

src/HttpCache/EventListener/PurgeListener.php

+        }
+    }
+
+    private function addResources(Request $request)


Probably useless because it is already handled for Doctrine and not reliable enough for non-Doctrine data providers.

fbourigault · 2017-02-20T12:44:37Z

This looks amazing, but does providing a solution coupled to specific cache solution as first class citizen a good idea?

Maybe an intermediate solution build using standard Http headers would improve interoperability.

bendavies · 2017-02-20T12:46:27Z

Nice work @dunglas.

This is a very similar strategy to what i've implemented previously.
A few comments:

why not just use FosHttpCache instead of implementing your own tagging/purgers etc?
It does not look like this will work with authenticated apis that don't use cookies, i.e just header auth or query param (FosHttpCache has provisions for user specific caching). I'm guessing this would be for the user to implement?
why do you md5 the tags?

fbourigault · 2017-02-20T12:57:06Z

composer.json

@@ -34,6 +34,7 @@
        "doctrine/orm": "^2.5",
        "doctrine/annotations": "^1.2",
        "friendsofsymfony/user-bundle": "^2.0@dev",
+        "guzzlehttp/guzzle": "^6.0",


You should use php-http/httplug for better interop.

Maybe when it will be a PSR. But for now it has nos advantage over using Guzzle 6 for this use case: it is harder to setup (requires to install an extra Symfony bundle), adds complexity and a (small) performance overhead.
Guzzle 6 is already an abstraction layer, with builtin curl and streams implementations. We only depend of the ClientInterface, it's easy to bridge other implementations (but I think it is not worth it).

As we support PHP 7 only, we don't target older libraries such as Guzzle 5.

I didn't catch the last point. 👍

@dunglas IMHO, you should consider using buzz. And It's not a joke:

Guzzle have so many version, and these versions are not compatible each others. So people that are using a version that is incompatible with guzzle 6 will be blocked.

Buzz is very simple and works well

AFAIK it doesn't support async requests... and it has not been updated since 2015.

When guzzle guys will release the 7.0 version, you will be stuck with the 6.0 version. Http clients are a widely common dependency and so conflicts may appears. But ATM you could go with guzzle 6. Using httplug could be added later.

I have a very strong (I think) argument for using HTTPlug: you do not get into hell like FOSHttpCache did (and still is) with their hard coupling to a specific Guzzle version.

dunglas · 2017-02-20T13:32:34Z

@fbourigault there is an abstraction layer and and implementation (Varnish). Basically, anyone can add support for any cache provider supporting cache invalidation (it's a matter of implementing an interface). I plan to add support CloudFlare in core too.

There is no standard (HTTP headers) for cache invalidation (only expiration is supported in RFCs) but I choose to use Cache-Tags because it's the one used by CloudFlare.

@bendavies regarding FosHttpCache, for 2 reasons:

my implementation is a bit different (the md5 hash) and tight to the concept of "resources" and "IRIs", not present in FosHttpCache
the implementation is trivial (and it's possible to bridge it with FosHttpCache if wanted), it will ease our maintenance process to not have a dependency to a 3rd party library we don't maintain (our soft dependency to FosUser is a pain to maintain...).

It can work with any mechanism of authentification (it's why I've introduced a way to configure the Vary HTTP header). If the resource varies depending of the Authorization header, just set api_platform.http_cache.vary to ['Content-Type', 'Authorization'] (you'll need to tweak the Varnish config too). A key concept of REST is being stateless, a resource identified by an IRI (and some headers specified in Vary) should not vary depending of the current logged in user (in this case, the URL should not be the same).

3/ To avoid collisions (if the a resource is tagged with /foos/,/foos1 and another with only /foos/2, sending a BAN request with /foos as parameter will ban both, and it's a bug. Using md5 hashes prevent this problem. A CRC32 hash should do the trick too, but md5 is usually faster on modern servers.

fbourigault · 2017-02-20T15:25:02Z

There is no standard (HTTP headers) for cache invalidation (only expiration is supported in RFCs) but I choose to use Cache-Tags because it's the one used by CloudFlare.

By standard HTTP headers, I mean revalidation. But maybe in such case, caching is not efficient.

teohhanhui · 2017-02-20T15:44:05Z

There is no standard (HTTP headers) for cache invalidation (only expiration is supported in RFCs) but I choose to use Cache-Tags because it's the one used by CloudFlare.

Custom HTTP headers should be prepended by `X-`. CloudFlare is flaunting the spec (bad).

If the resource varies depending of the Authorization header, just set api_platform.vary to ['Content-Type', 'Authorization'] (you'll need to tweak the Varnish config too).

It's not so simple. An authorization context needs to be provided and hashed in Varnish. Blindly adding `Vary: Authorization` would kill hit rates, if your intention is to keep a cache for each user, for example.

A key concept of REST is being explicit, a resource identified by an IRI should not vary depending of the current logged in user (in this case, the URL should not be the same).

False. A resource can vary by any header as declared in the Vary header.

…

On Mon, 20 Feb 2017, 23:25 Fabien Bourigault, ***@***.***> wrote: There is no standard (HTTP headers) for cache invalidation (only expiration is supported in RFCs) but I choose to use Cache-Tags because it's the one used by CloudFlare. By standard HTTP headers, I mean revalidation. But maybe in such case, caching is not efficient. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#952 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAhf63uGzERC5mdRPdJ0d2iStftzosjsks5rebBOgaJpZM4MGFp2> .

teohhanhui · 2017-02-20T15:51:25Z

To avoid collision (if the a resource is tagged with /foos/,/foos1 and

another with only /foos/2, sending a BAN request with /foos as parameter will ban both, and it's a bug. Using md5 hashes prevent this problem. A CRC32 hash should do the trick too, but md5 is usually faster on modern servers. Just use regex. Varnish has good regex support. Using a hash is a nightmare when trying to debug cache tags. :)

…

On 20 Feb 2017 21:32, "Kévin Dunglas" ***@***.***> wrote: @fbourigault <https://github.com/fbourigault> there is an abstraction layer and and implementation (Varnish). Basically, anyone can add support for any cache provider supporting cache invalidation (it's a matter of implementing an interface). I plan to add support CloudFlare in core too. There is no standard (HTTP headers) for cache invalidation (only expiration is supported in RFCs) but I choose to use Cache-Tags because it's the one used by CloudFlare. @bendavies <https://github.com/bendavies> regarding FosHttpCache, for 2 reasons: - my implementation is a bit different (the md5 hash) and tight to the concept of "resources" and "IRIs", not present in FosHttpCache - the implementation is trivial (and it's possible to bridge it with FosHttpCache if wanted), it will ease our maintenance process to not have a dependency to a 3rd party library we don't maintain (our soft dependency to FosUser is a pain to maintain...). It can work with any mechanism of authentification (it's why I've introduced a way to configure the Vary HTTP header). If the resource varies depending of the Authorization header, just set api_platform.vary to ['Content-Type', 'Authorization'] (you'll need to tweak the Varnish config too). A key concept of REST is being explicit, a resource identified by an IRI should not vary depending of the current logged in user (in this case, the URL should not be the same). 3/ To avoid collision (if the a resource is tagged with /foos/,/foos1 and another with only /foos/2, sending a BAN request with /foos as parameter will ban both, and it's a bug. Using md5 hashes prevent this problem. A CRC32 hash should do the trick too, but md5 is usually faster on modern servers. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#952 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAhf6wbwV3BrEH6NhwLvb1gsngiwy9X4ks5reZXzgaJpZM4MGFp2> .

dunglas · 2017-02-20T15:54:28Z

I'll make the header configurable but I'll keep CloudFlare compatibility by default, it's an invaluable feature. By the way this header should not be exposed to the end client.

Regarding Vary, it's exactly what I explain in my post 🙂

Regarding the hit rate, doing more advanced things like hashing cannot be automated on the API Platform side, it requires a custom development and it's easy to implement using the new vary option.
Using FosHTTPCache for such usages is also an option, it's up to the developer.

dunglas · 2017-02-20T15:56:40Z

Regex (at least simple regexes) doesn't fix the issue in my example. /foos will match /foos/*, not only the collection response.

teohhanhui · 2017-02-20T15:58:12Z

/^\/foos$/

…

On Mon, 20 Feb 2017, 23:56 Kévin Dunglas, ***@***.***> wrote: Regex (at least simple regexes) doesn't fix the issue in my example. /foos will match /foos/*, not only the collection response. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#952 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAhf6xda_oN9xDzCcGI-KffMusAtGIHtks5rebe4gaJpZM4MGFp2> .

dunglas · 2017-02-20T15:59:18Z

But maybe a more complex regex can do the trick, I'll give it a try (I agree that plain tags are better than hashes for debug).

dunglas · 2017-02-20T15:59:50Z

The comma must be handled too.

jderusse · 2017-02-20T16:14:14Z

features/http_cache/tags.feature

+    """
+    Then the response status code should be 200
+    And the header "Cache-Tags" should not exist
+    And "/relation_embedders/1,/related_dummies/1,/third_levels/1" IRIs should be purged


A PUT may change the value of an attribute used to order a responses. You should invalidate collection too

Good catch, I add this.

jderusse · 2017-02-20T16:15:27Z

features/http_cache/tags.feature

+    And I send a "DELETE" request to "/relation_embedders/1"
+    Then the response status code should be 204
+    And the header "Cache-Tags" should not exist
+    And "/relation_embedders/1,/relation_embedders" IRIs should be purged


What's about related_dummies who was previously linked to this entity? They should be invalidated too

They will be, because they are marked with /relation_embedders/1.

jderusse · 2017-02-20T16:16:10Z

features/http_cache/tags.feature

+    """
+    Then the response status code should be 201
+    And the header "Cache-Tags" should not exist
+    And "/relation_embedders,/related_dummies,/third_levels,/relation_embedders/1,/related_dummies/1,/third_levels/1" IRIs should be purged


I don't understand in you code how you make the link between relation_embedders and third_levels? Who flaged it?

It's because of this line: https://github.com/api-platform/core/pull/952/files#diff-0362bfae91549bcd08af0d06bd806b37R14

jderusse · 2017-02-20T16:24:42Z

features/http_cache/tags.feature

+  Scenario: Tags must be set for items
+    When I send a "GET" request to "/relation_embedders/1"
+    Then the response status code should be 200
+    And the header "Cache-Tags" should be equal to "aa9e2bee5be20590f7dcc520ce2dffca,12a0c94f947a680d68bd6f65e025457d,91774d67418192a057e25dae00345572"


md5 obfuscate tests... :(
I wonder if a dedicated context could be more readable: the cache-tag header should be equals to "/relation_embedders, ...."

True, I'm working on a fix to remove the hash and use plain IRIs. I'll update the PR when it's ready.

jderusse · 2017-02-20T19:14:17Z

src/Bridge/Symfony/Bundle/DependencyInjection/Configuration.php

+                        ->end()
+                        ->booleanNode('public')->defaultNull()->info('To make all responses public by default.')->end()
+                        ->booleanNode('enable_tags')->defaultFalse()->info('Add cache tags to the response.')->end()
+                        ->scalarNode('varnish_url')->defaultNull()->info('URL of the Varnish server to purge using cache tags when a resource is updated.')->end()


Don't forget user with several varnish servers

dunglas · 2017-02-20T22:57:29Z

Thank you for the reviews everyone!

Plain IRIs are now used instead of md5 hashes (and the regex have been updated accordingly)
Collections are purged even when a PUT is done

Simperfit

👍

soyuka

Would be nice to add unit tests to all those listeners!

soyuka · 2017-02-22T13:39:25Z

src/Bridge/Doctrine/EventListener/PurgeHttpCacheListener.php

+    public function onFlush(OnFlushEventArgs $eventArgs)
+    {
+        $iriConverter = $this->container->get('api_platform.iri_converter');
+        $resourceManager = $this->container->get('api_platform.http_cache.resource_manager');


Circular reference is only because of IriConverter no? Can't you inject the ResourceManager properly though?

soyuka · 2017-02-22T13:42:22Z

src/HttpCache/VarnishPurger.php

+            return;
+        }
+
+        $parts = array_map(function ($iri) {


A small comment to explain what goes below would be great for future readers!

jderusse · 2017-02-20T19:55:13Z

features/http_cache/tags.feature

+    And I send a "DELETE" request to "/relation_embedders/1"
+    Then the response status code should be 204
+    And the header "Cache-Tags" should not exist
+    And "/relation_embedders/1,/relation_embedders" IRIs should be purged


jderusse · 2017-02-23T16:30:27Z

src/Bridge/Symfony/Bundle/Resources/config/http_cache_tags.xml

+            <argument type="service" id="api_platform.http_cache.resource_manager" />
+            <argument type="service" id="api_platform.http_cache.purger" />
+
+            <tag name="kernel.event_listener" event="kernel.terminate" method="onKernelTerminate" />


I suggest to move the purge as close as possible to the transaction (doctrine postFlush IMO)

I understand your point of view to return a response to the user as soon as possible, but this introduce cross concurrency bugs.

Example:

list all blogs (cache mis)

post a blog

list all blog (cache hit when called before the kernel terminate even)

I already have this issue in the my CI (agreed, this is a particular case with a lot of stress tests). but the probability of cross concurrency is higher when:

you have several varnishes to purge

you have other kernel.terminate events with an higher priority (sending an email for instance)

^ That does not actually address the race condition, but only trying to avoid it.

indeed, it fixes one case.

BTW (not related to the RC): A small improvment for the user would be to start async request on the postFlush event, and wait on the kernelFinish event.

jderusse · 2017-03-17T07:37:43Z

src/HttpCache/EventListener/ConfigureListener.php

+    private $vary;
+    private $public;
+
+    public function __construct(int $maxAge = null, int $sharedMaxAge = null, array $vary, bool $public = null)


I suggest to add a LastModified header too initialized to the default value now().
As a result, Varnish will handled it for free (by default), and returns 304 code stuff.

This small change should not interfer in your App and how you invalid cache. But will save bandwidth between the user and varnish.

Varnish already returns 304 response properly. We should not send bogus Last-Modified headers.

I thought this listener was used only with "tag" thing. I apologize, agreed, this header don't make sens here.

But I think, you missed my point, the idea, when using tagged response, is to add a validation header (could be etag or last-modified, don't care). To save bandwidth between users and varnish when cache is hit.

IMO we should provide a good default config for this (in the standard edition) but let the user configure it as he wants.

@jderusse:

the idea, when using tagged response, is to add a validation header (could be etag or last-modified, don't care). To save bandwidth between users and varnish when cache is hit.

That's incorrect. Varnish already sends 304 response with proper ETag in that case. There is no need for the backend to send an ETag or Last-Modified header unless the backend intends to return 304 on vcl_backend_fetch.

Let explain with a schema (my last try)...
Here is the actual implementation

My objective is to transform the last response in step 6 into a 304.

To do it, varnish need a if-none-match header in step 5

To do it, client need a etag header in step 4

To do it, varnish needs nothing, it just forward the response from the app from step 3

To do it, app must send this header <= this is my point

And Here is the target sequence

Your last comment suggest that varnish add this header by it self, with something like that

Is it what you mean? Because I doubt varnish add such header by itself (unless you implement this behavior in a VCL which is fine to me too)

Because I doubt varnish add such header by itself

Varnish does it by default. Try it. At least it has been doing so since 4.0 😄

I bootstraped an empty api-plateform from this PR api-platform/api-platform#238

curl test2_varnish_1.docker/foos -i HTTP/1.1 200 OK Server: nginx/1.11.10 Content-Type: application/ld+json; charset=utf-8 X-Powered-By: PHP/7.1.3 Vary: Content-Type X-Content-Type-Options: nosniff X-Frame-Options: deny Cache-Control: public, s-maxage=3600 Link: <http://test2_varnish_1.docker/docs.jsonld>; rel="http://www.w3.org/ns/hydra/core#apiDocumentation" Cache-Tags: /foos Date: Wed, 22 Mar 2017 07:23:50 GMT X-Varnish: 26 32789 Age: 3 Via: 1.1 varnish-v4 Accept-Ranges: bytes Content-Length: 111 Connection: keep-alive {"@context":"\/contexts\/Foo","@id":"\/foos","@type":"hydra:Collection","hydra:member":[],"hydra:totalItems":0}

varnish don't add validation header 😕

@jderusse You're right. I overlooked that FOSHttpCacheBundle was the one adding it. My apologies...

I think we should use the same approach. Just use the MD5 hash of the Response content as ETag. MD5 is cheap, so no reason to use a meaningless Last-Modified. 😄

Doing a md5 of the response is not ok (the response contains the date). We may do a md5 of the response's body.

jderusse · 2017-03-17T07:41:20Z

src/Bridge/Symfony/Bundle/DependencyInjection/ApiPlatformExtension.php

+    {
+        $loader->load('http_cache.xml');
+
+        if (true !== $config['http_cache']['enable_tags']) {


When enable_tags is true and maxAge > 0. We should warn the developer that the browser will cache responses and remove the benefits of cache invalidation.

It can be intended (I often do that). It allows to always serve fresh data for the first request but reduce the server load/bandwidth usage thanks to expiration. It's often not a problem when the TTL is low. I would let the user do what he wants without warning.

jderusse · 2017-05-11T08:14:34Z

src/Bridge/Doctrine/EventListener/PurgeHttpCacheListener.php

+            return;
+        }
+
+        $resources = $request->attributes->get('_resources', []);


This tight couple the purge system with http requests context which is used like a databag.

Yes I'll try to find a better solution but I'm not sure there is one. Anyway its called purge HTTP cache, it's not a big deal to couple it with the HTTP request.

dunglas · 2017-05-15T18:55:33Z

All comments handled. Can you make a last review?

sroze · 2017-05-15T19:50:19Z

src/Hal/Serializer/ItemNormalizer.php


        $rawData = parent::normalize($object, $format, $context);
        if (!is_array($rawData)) {
            return $rawData;
        }

-        $data = ['_links' => ['self' => ['href' => $this->iriConverter->getIriFromItem($object)]]];
+        $data = ['_links' => ['self' => ['href' => $context['iri']]]];
+        $context['debug'] = true;


Is there any reason for this property in the context?

Good catch, it has nothing to do here!

soyuka · 2017-05-15T20:03:21Z

features/http_cache/tags.feature

@@ -0,0 +1,64 @@
+Feature: Cache invalidation trough HTTP Cache tags


soyuka · 2017-05-15T20:07:19Z

src/HttpCache/EventListener/AddTagsListener.php

+            !$request->isMethodCacheable()
+            || !$response->isCacheable()
+            || (!$attributes = RequestAttributesExtractor::extractAttributes($request))
+            || !$resources = $request->attributes->get('_resources')


no parenthesis here, but the line above yes?

The parenthesis on the previous line are mandatory because of operator priorities.

soyuka · 2017-05-15T20:11:10Z

tests/Serializer/ItemNormalizerTest.php

@@ -94,7 +95,7 @@ public function testNormalize()
        );
        $normalizer->setSerializer($serializerProphecy->reveal());

-        $this->assertEquals(['name' => 'hello'], $normalizer->normalize($dummy));
+        $this->assertEquals(['name' => 'hello'], $normalizer->normalize($dummy, null, ['resources' => []]));


Shouldn't we avoid changing those tests? It feels like the tests (this one and the others) won't pass without 2 more arguments (eg, null, ['resources' => []]). Is it the case / Isn't this breaking things somehow?

It passes without the arguments and without change, but I've modified it to test the new behavior.

Okay as long as there is a test that doesn't adds up those arguments.

Simperfit · 2017-05-19T10:11:33Z

I'm going to test this with a project, ill tell if there are some bugs

QuingKhaos · 2017-05-23T08:55:26Z

May you use http://httplug.io/ instead of guzzle directly?

teohhanhui · 2017-05-23T10:51:27Z

May you use http://httplug.io/ instead of guzzle directly?

It has been raised before, and I'd like to once again echo this.

dunglas · 2017-05-23T11:04:53Z

HTTPPlug introduces a lot of complexity (including an extra bundle to configure... until we get Flex) for no gain here. I'm still 👎 for now.
I understand the problem with Guzzle 3, but API Platform is younger than Guzzle 3, every bundle I use are compatible with Guzzle 6, and AFAIK, there is no projet to develop Guzzle 7 soon.

dunglas · 2017-05-23T11:06:02Z

And by the way, Guzzle is a soft dependency here. So someone wanting to use another client can do it, he just have to implement by himself the PurgerInterface, not a big deal.

theofidry · 2017-05-23T11:35:11Z

As long as Guzzle is a soft dependency it's ok

Builtin cache invalidation system aka make API Platform fast as hell

dunglas force-pushed the cache_tags branch from 3b2659b to 4cc12df Compare February 20, 2017 11:59

dunglas mentioned this pull request Feb 20, 2017

Add a Varnish container and enable cache invalidation api-platform/api-platform#238

Merged

1 task

dunglas commented Feb 20, 2017

View reviewed changes

dunglas force-pushed the cache_tags branch from 4cc12df to 1f08113 Compare February 20, 2017 12:13

fbourigault reviewed Feb 20, 2017

View reviewed changes

jderusse reviewed Feb 20, 2017

View reviewed changes

dunglas force-pushed the cache_tags branch 2 times, most recently from 2ac0f1e to 603fa12 Compare February 20, 2017 22:55

dunglas force-pushed the cache_tags branch 2 times, most recently from ce8419e to 29c2b4f Compare February 20, 2017 23:18

Simperfit approved these changes Feb 22, 2017

View reviewed changes

soyuka requested changes Feb 22, 2017

View reviewed changes

jderusse reviewed Feb 23, 2017

View reviewed changes

jderusse reviewed Mar 17, 2017

View reviewed changes

dunglas force-pushed the cache_tags branch from 2899344 to f6edf5c Compare May 10, 2017 14:33

jderusse reviewed May 11, 2017

View reviewed changes

dunglas force-pushed the cache_tags branch 3 times, most recently from 5359fa6 to a32a049 Compare May 15, 2017 14:09

dunglas added the [RFR] Ready for Review label May 15, 2017

dunglas force-pushed the cache_tags branch from 1f32d1f to 6d02113 Compare May 15, 2017 18:55

sroze reviewed May 15, 2017

View reviewed changes

soyuka reviewed May 15, 2017

View reviewed changes

dunglas force-pushed the cache_tags branch 4 times, most recently from 11dd011 to 6075fa2 Compare May 22, 2017 15:58

dunglas force-pushed the cache_tags branch 2 times, most recently from d044bac to 17443aa Compare May 23, 2017 09:57

dunglas force-pushed the cache_tags branch from 17443aa to 1126dda Compare May 23, 2017 13:49

Builtin cache invalidation system aka make API Platform fast as hell

2139c80

dunglas force-pushed the cache_tags branch from 1126dda to 2139c80 Compare May 23, 2017 15:03

dunglas merged commit 5a81357 into api-platform:master May 23, 2017

dunglas deleted the cache_tags branch May 23, 2017 15:57

dunglas mentioned this pull request Jul 26, 2017

[RFC] purge on kernel terminate, instead of post flush #1286

Closed

hoangnd25 pushed a commit to hoangnd25/core that referenced this pull request Feb 23, 2018

Merge pull request api-platform#952 from dunglas/cache_tags

2e5b5d6

Builtin cache invalidation system aka make API Platform fast as hell

usu mentioned this pull request Jul 2, 2023

POC: HTTP reverse proxy cache ecamp/ecamp3#3610

Merged

9 tasks

		@@ -0,0 +1,64 @@
		Feature: Cache invalidation trough HTTP Cache tags

Builtin cache invalidation system aka make API Platform fast as hell #952

Builtin cache invalidation system aka make API Platform fast as hell #952

Conversation

dunglas commented Feb 20, 2017 • edited Loading

dunglas Feb 20, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fbourigault commented Feb 20, 2017

bendavies commented Feb 20, 2017 • edited Loading

Choose a reason for hiding this comment

dunglas Feb 20, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dunglas commented Feb 20, 2017 • edited Loading

fbourigault commented Feb 20, 2017

teohhanhui commented Feb 20, 2017 via email • edited by Simperfit Loading

teohhanhui commented Feb 20, 2017 via email

dunglas commented Feb 20, 2017

dunglas commented Feb 20, 2017

teohhanhui commented Feb 20, 2017 via email

dunglas commented Feb 20, 2017

dunglas commented Feb 20, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dunglas commented Feb 20, 2017

Simperfit left a comment • edited Loading

Choose a reason for hiding this comment

soyuka left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

teohhanhui Mar 22, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

teohhanhui Mar 22, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dunglas May 11, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dunglas May 11, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dunglas commented May 15, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

soyuka May 15, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Simperfit commented May 19, 2017

QuingKhaos commented May 23, 2017

teohhanhui commented May 23, 2017

dunglas commented May 23, 2017

dunglas commented May 23, 2017 • edited Loading

dunglas commented Feb 20, 2017 •

edited

Loading

dunglas Feb 20, 2017 •

edited

Loading

bendavies commented Feb 20, 2017 •

edited

Loading

dunglas Feb 20, 2017 •

edited

Loading

dunglas commented Feb 20, 2017 •

edited

Loading

teohhanhui commented Feb 20, 2017 via email •

edited by Simperfit

Loading

Simperfit left a comment •

edited

Loading

teohhanhui Mar 22, 2017 •

edited

Loading

teohhanhui Mar 22, 2017 •

edited

Loading

dunglas May 11, 2017 •

edited

Loading

dunglas May 11, 2017 •

edited

Loading

soyuka May 15, 2017 •

edited

Loading

dunglas commented May 23, 2017 •

edited

Loading