Codestin Search App

dunglas · 2017-02-20T12:01:43Z

See api-platform/core#952 for the rationale.

TODO:

Disable the cache for app_dev.php

Simperfit · 2017-02-22T11:59:52Z

composer.json

        "php": ">=7.0",
        "symfony/symfony": "3.2.*",
-        "api-platform/core": "^2.0",
+        "api-platform/core": "dev-cache_tags",


Don't forget to change it when merging both

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

docker/varnish/conf/default.vcl

+import std;
+
+backend default {
+  .host = "nginx";


beware, varnish resolves the IP of the domain at boot time and keep it till the end of process.
If the IP of nginx changes (for instance when the container restarts) varnish won't be able to route traffic to the new container

Do you know a workaround for this?

Several people use a local nginx configured in proxy pass.
Varnish point to nginx 127.0.0.1, and nginx performs the DNS resolution on the fly.
Some other use a script in charge of reloading varnish when the I'm change.

None is ideal to me.

In dev environment, I just restart my container, in production we use a local nginx

I suggest to let it as is for now. WDYT?

I use https://github.com/nigoroll/libvmod-dynamic.

jderusse · 2017-03-17T07:21:18Z

docker/varnish/conf/default.vcl

+    return(synth(400, "X-Ban-Regex HTTP header must be set."));
+  }
+
+  # Don't cache in dev mode


Why? Shouldn't be an issue if the invalidator works well.
If it don't, you'll not going on prod.

It hurts the DX. When you change the code in dev, you want the new code to be executed even if the underlying resource has not been modified.

jderusse · 2017-03-17T07:24:25Z

docker/varnish/conf/default.vcl

+  # To allow API Platform to ban by cache tags
+  if (req.method == "BAN") {
+    if (client.ip !~ ban) {
+      return(synth(403, "Not allowed"));


What's about 405?

jderusse · 2017-03-22T07:36:36Z

docker/varnish/conf/default.vcl

+  # Don't send cache tags related headers to the client
+  unset resp.http.url;
+  # Uncomment the following line to NOT send the "Cache-Tags" header to the client (prevent using CloudFlare cache tags)
+  #unset resp.http.Cache-Tags;


I wonder if we shouldn't remove the s-max-age header too.
With this new tag feature, the app sets an arbitrary value because we known we'll be able to invalidate the varnish. Which is fine.

BUT what if an other unknown proxy is on the path? (see "proxy cache" in this old version of the documentation http://symfony.com/doc/2.2/book/http_cache.html#types-of-caches)

We should use a custom header like X-Reverse-Proxy-TTL instead of abusing s-max-age.

For instance, when using CloudFlare, the s-max-age header should be set too. I propose to keep it as is for now too. We'll see when we'll get some feedback.

We must not set an incorrect s-max-age. It's 100% dangerous. If the user needs to do that for CloudFlare, they should set it themselves (or we should provide some easy way of setting it).

I don't get your point, we don't set this value automatically, it's up to the user. We just provide a good default when using the Varnish image.

Alright. I see that the default configuration doesn't set maxage and s-maxage, so we're safe. 😄

https://github.com/api-platform/core/blob/9fa028903d1df02011c2b75504b87d1e975e7b70/src/Bridge/Symfony/Bundle/DependencyInjection/Configuration.php#L123

But we provide an unsafe default in api-platform/api-platform. A good default is a safe default. 😞

api-platform/app/config/config.yml

Line 89 in ddb4e77

shared_max_age: 3600

So my suggestion is that we should use a custom header, e.g. Reverse-Proxy-TTL

Simply because the HTTP cache mechanism is not designed with reverse caching proxies in mind, so it's not the right tool for the job.

My concern is that this custom header will not be taken into account by Cloudflare. Maybe can we set the smaxage as we currently do but remove it with Varnish before the request go outside our network?

If CloudFlare uses s-maxage, let the user change the shared_max_age option that we already provide in the bundle config. It's not a safe default, and the default setup in api-platform/api-platform uses Varnish anyway, not CloudFlare.

Shine-neko · 2017-05-23T16:30:23Z

app/config/config.yml

+api_platform:
+    http_cache:
+        enable_tags: true
+        varnish_urls: %varnish_urls%


dunglas · 2017-06-02T18:12:04Z

Requires api-platform/core#1156

dunglas force-pushed the varnish branch from 85d7b71 to 024539d Compare February 20, 2017 22:53

dunglas mentioned this pull request Feb 20, 2017

Builtin cache invalidation system aka make API Platform fast as hell api-platform/core#952

Merged

1 task

dunglas force-pushed the varnish branch 3 times, most recently from 2540fe5 to 568ef1e Compare February 20, 2017 23:17

Simperfit approved these changes Feb 22, 2017

View reviewed changes

Simperfit reviewed Feb 22, 2017

View reviewed changes

jderusse reviewed Mar 17, 2017

View reviewed changes

jderusse reviewed Mar 22, 2017

View reviewed changes

quentinus95 mentioned this pull request May 9, 2017

Add varnish server to Docker-Compose p-project/p-api#7

Open

Shine-neko reviewed May 23, 2017

View reviewed changes

app/config/config.yml Outdated

api_platform:

http_cache:

enable_tags: true

varnish_urls: %varnish_urls%

Copy link

Shine-neko May 23, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Quote ?

dunglas force-pushed the varnish branch 4 times, most recently from ff6404e to 0c81720 Compare June 2, 2017 18:11

dunglas force-pushed the varnish branch from 0c81720 to aef39e9 Compare June 2, 2017 18:17

dunglas requested a review from teohhanhui June 2, 2017 21:29

dunglas force-pushed the varnish branch from aef39e9 to ec39682 Compare June 6, 2017 17:22

Add a Varnish container and enable cache invalidation

8c2dd55

dunglas force-pushed the varnish branch from ec39682 to 8c2dd55 Compare June 6, 2017 18:28

dunglas merged commit ddb4e77 into api-platform:master Jun 6, 2017

dunglas deleted the varnish branch June 6, 2017 18:53

Uh oh!

Conversation

dunglas commented Feb 20, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dunglas Apr 7, 2017 • edited by Simperfit Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

teohhanhui Jun 7, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

teohhanhui Jun 7, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dunglas commented Jun 2, 2017

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

dunglas commented Feb 20, 2017 •

edited

Loading

dunglas Apr 7, 2017 •

edited by Simperfit

Loading

teohhanhui Jun 7, 2017 •

edited

Loading

teohhanhui Jun 7, 2017 •

edited

Loading