Invalidating Firebase Hosting / CDN Cloud Function cache

[ro...@passphere.com]

It's awesome to see that we can now using Firebase Hosting for our Cloud Functions, meaning we can now have URls like www.app.com/api/cloudFunction and we now have a fast CDN backing Cloud Functions. 

Both great improvements!

I was wondering how we can invalidate our cache?

It appears if we run a firebase hosting deploy then our cache is invalidated but that invalidates the cache for every single file. 

What about if we just want to invalidate the cache for a single function?

It would be great if:

• firebase CDN talked with Cloud Functions and any time a new cloud function was deployed it also invalidated the cache
  
• If we could programatically invalidate the cache, e.g. when our data is updated.

(X-Post from Google Functions Beta Group)

[Michael Bleigh]

Thanks for the questions and feedback! We thought this was likely to be an area of interest once we launched Cloud Functions + Firebase Hosting, and I can see we were right :)

For now, our advice is to use appropriately short TTLs such that you don't need to manually purge. While origin hits do have higher latency than edge cache hits, even a relatively short CDN TTL (e.g. 10 minutes) can provide massive reductions in load and massive increases in performance. You can think of a Hosting deploy as being an "emergency" lever that will invalidate the whole cache if you need it.

That being said, we are going to continue gathering feedback and usage patterns from developers making use of the new integration. If we can come up with an easy-to-use cache purging strategy that solves real problems developers are running into, we will of course consider that in the future.

In the meantime, I'd encourage you to play with the feature and TTL lengths to find something you're happy with.

Cheers,
Michael

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/679758d0-7bbe-43d2-adeb-335ac92c7330%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Laurent Pellegrino]

Hello,

I would also be interested in such a feature for migrating an existing service to Firebase. 

Is there any plan for invalidating Functions cache from an API (e.g. invoked from another Cloud function). 

In my case, it would be nice if the invalidation can be done for function results that have the desired header(s) defined.

Kind Regards,

Laurent Pellegrino

[Michael Bleigh]

Thanks for the note. We have an internal feature request open to track this, and will consider it as more feedback comes in.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/d1028926-e4a7-408d-9a2a-42848ae3d6d3%40googlegroups.com.

[Rubén López]

Here is another use case, since you are gathering those:

I have a url schema like /path/:id mapped to a firebase function. That ID is a key in the realtime database, and the firebase function is rendering <title> and <meta> headers for proper social sharing of these URLs based on the branch of the database under that ID. The rest of the data is rendered client-side, I only use the function for social tags.

Database branches occasionally change, and it would be great to have a way to invalidate the CDN cache whenever the corresponding database branch changes.

I like the proposal from Laurent to invalidate the cache from another cloud function (a database triggered one, in my case), but any other approach that allows invalidating the CDN cache as a response to a database change would also work for me.

As a short-term workaround, reducing the TTL to minutes also works, although I don't have that many users, and if I do that, the CDN cache will never be used...

[David Dam]

Hello Michael, any news on this feature?

Op donderdag 29 juni 2017 23:16:11 UTC+2 schreef Michael Bleigh:

[Vincent De Ridder]

Hi Michael,

Any updates on this subject? 

This would be the perfect solution for my use case. 

I also host a web application that changes content max. once per month. 

Being able to automatically invalidate the cache when content has changed would be a live saver. 

Thank you

Op donderdag 29 juni 2017 23:16:11 UTC+2 schreef Michael Bleigh:

Thanks for the note. We have an internal feature request open to track this, and will consider it as more feedback comes in.

[Brad Stanfield]

Hi,

This would be an amazing feature. Any further word on the status of this?

A Firebase video here: https://www.youtube.com/watch?v=7_2CJs_VZk4 at 33:19 it talks of the PURGE method. 

I've tried implementing it in my project and it doesn't seem to work?

I posted a StackOverFlow question about it here: https://stackoverflow.com/questions/52787090/firebase-hosting-with-cloud-functions-how-to-purge-refresh-cdn-cache but so far no luck.

Thanks

Brad

[Moriz Büsing]

Hi,

any news on this feature? My usecase is pretty similar to what Rubén López posted. We could basically use an endless TTL except for when things in the database change, then we'd need to invallidate the cache. This would be the perfect invalidation strategy for me usecase.

[Michael Bleigh]

Something you can do that is a little bit of an undocumented API (I can't promise it will be around forever but there's no plan to change it) is to issue a request to a specific URL with a PURGE method, e.g.

curl -X PURGE https://my.firebasehosting.site.com/path/to/content

This will purge the CDN cache for that URL, allowing you to potentially do some of the things you're looking for. See my I/O talk for an example of this.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/a6464328-915f-428a-a699-f8ee9501df5d%40googlegroups.com.

[Laurent Pellegrino]

Michael,

That's fantastic! Thanks for sharing.

I know it's not officially supported but is there a rate limit per unit of time (throttling)? Is it possible to purge by headers (e.g. a domain registered in firebase hosting) or by tags?

[Michael Bleigh]

There is currently no hard cap on request rate, but that may change in the future (again, unofficial feature here). You can currently only purge specific URLs, not domains/headers/etc.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/b95ac9e0-5869-44e2-8cc7-10d3dfb5ccee%40googlegroups.com.

[James Hegedus]

Hi Michael,

This is an amazingly useful feature. Are you able to update us on whether this is a feature still coming down the pipeline?

On Wednesday, January 23, 2019 at 7:39:58 AM UTC+11, Michael Bleigh wrote:

There is currently no hard cap on request rate, but that may change in the future (again, unofficial feature here). You can currently only purge specific URLs, not domains/headers/etc.

To unsubscribe from this group and stop receiving emails from it, send an email to fireba...@googlegroups.com.

[ManWithSteelNerves]

Any chance this can be official at some point?

I want to use this in production but just worried as it may break at some point. Even if this option is removed, will there be an alternative option provided to do it from backend when in production?

Thanks,

Ayyappa

On Wednesday, 23 January 2019 02:09:58 UTC+5:30, Michael Bleigh wrote:

There is currently no hard cap on request rate, but that may change in the future (again, unofficial feature here). You can currently only purge specific URLs, not domains/headers/etc.

To unsubscribe from this group and stop receiving emails from it, send an email to fireba...@googlegroups.com.