# Google Maps Onebox data is not cached
**URL:** https://meta.discourse.org/t/google-maps-onebox-data-is-not-cached/59124
**Category:** Feature
**Created:** [March 15, 2017, 1:39am UTC](https://meta.discourse.org/t/google-maps-onebox-data-is-not-cached/59124 "2017-03-15T01:39:01Z")
**Posts on this page:** 14
**Page:** 1
### Author:  [@glebm](https://meta.discourse.org/u/glebm)
#### Post date: [March 15, 2017, 1:39am UTC](https://meta.discourse.org/t/google-maps-onebox-data-is-not-cached/59124/1 "2017-03-15T01:39:01Z")
Test case: [Google Maps](https://goo.gl/maps/R6nj3Qwf2LR2)
https://maps.google.com/maps?ll=51.5332441,-0.1281903&z=17&output=embed&dg=ntvb&q=Google+UK
Rendering this onebox issues **10** network requests in sequence every time.
* * *
**Update:** I mean server-side network requests when calling `Onebox.preview(map_url).to_s`.
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [March 15, 2017, 1:44am UTC](https://meta.discourse.org/t/google-maps-onebox-data-is-not-cached/59124/2 "2017-03-15T01:44:55Z")
Are you talking about the `png`s from Google?
Every `special` onebox is just an iframe where the remote site is responsible for everything and we can’t control it.
---
### Author:  [@glebm](https://meta.discourse.org/u/glebm)
#### Post date: [March 15, 2017, 1:45am UTC](https://meta.discourse.org/t/google-maps-onebox-data-is-not-cached/59124/3 "2017-03-15T01:45:42Z")
No, I’m talking about the server-side ([`google_maps_onebox.rb`](https://github.com/discourse/onebox/blob/master/lib/onebox/engine/google_maps_onebox.rb))
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [March 15, 2017, 2:32pm UTC](https://meta.discourse.org/t/google-maps-onebox-data-is-not-cached/59124/4 "2017-03-15T14:32:10Z")
I am still struggling with this, how can the onebox gem fix it.
This markup is cached fine:
```plaintext
```
Is there an option to amend the markup so somehow the iframe stops it barrage of requests and uses a local cache or something?
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [March 16, 2017, 12:23am UTC](https://meta.discourse.org/t/google-maps-onebox-data-is-not-cached/59124/5 "2017-03-16T00:23:44Z")
This is in no way a bug of any kind.
---
### Author:  [@glebm](https://meta.discourse.org/u/glebm)
#### Post date: [March 16, 2017, 12:43am UTC](https://meta.discourse.org/t/google-maps-onebox-data-is-not-cached/59124/6 "2017-03-16T00:43:56Z")
@codinghorror Every other onebox’s data is cached. For maps, though, `Onebox.preview(maps_url).to_s` makes network calls every time.
Correct behaviour:
```ruby
Onebox.preview('https://xkcd.com/123').to_s # network call
Onebox.preview('https://xkcd.com/123').to_s # no network call because it's been cached
```
The maps onebox:
```ruby
Onebox.preview('https://goo.gl/maps/R6nj3Qwf2LR2').to_s # 10 network calls
Onebox.preview('https://goo.gl/maps/R6nj3Qwf2LR2').to_s # 10 network calls
```
The library states it provides caching. The caching is not working for the maps onebox. How is it unreasonable to consider this a bug?
Even if you consider caching simply an optimization (I disagree but can see how you may think so), how is it “in no way a bug of any kind”? Performance issues are a kind of a bug. These 10 sequential network calls take about 5 seconds (I’ve tried on Linode London, Scaleway Amsterdam, and Heroku US).
Perhaps you’ve missed my [post](https://meta.discourse.org/t/google-maps-onebox-data-is-not-cached/59124/3) clarifying that this is about server-side? That would explain it.
---
### Author:  [@mpalmer](https://meta.discourse.org/u/mpalmer)
#### Post date: [March 16, 2017, 1:09am UTC](https://meta.discourse.org/t/google-maps-onebox-data-is-not-cached/59124/7 "2017-03-16T01:09:03Z")
I’m with @codinghorror: this isn’t a bug.
Consider the difference in response headers from the two requests:
```
$ wget -O /dev/null -S https://xkcd.com/123 |& grep Cache-Control
Cache-Control: max-age=300
Cache-Control: max-age=300
$ wget -O /dev/null -S https://goo.gl/maps/R6nj3Qwf2LR2 |& grep Cache-Control
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Cache-Control: private
Cache-Control: no-cache, must-revalidate
```
(There are multiple headers because of redirects being followed)
It would be a bug if the onebox library cached data when the origin said not to. The other way around… not so much.
---
### Author:  [@glebm](https://meta.discourse.org/u/glebm)
#### Post date: [March 16, 2017, 1:15am UTC](https://meta.discourse.org/t/google-maps-onebox-data-is-not-cached/59124/8 "2017-03-16T01:15:05Z")
@mpalmer Good point, I haven’t realized the intent is to respect the cache headers.
However, the onebox currently does not respect the headers. Instead, it always caches everything forever.
>
It only does the correct thing for Google Maps currently by accident. If Google Maps changes the cache headers tomorrow, it will no longer do the correct thing.
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [March 16, 2017, 2:22pm UTC](https://meta.discourse.org/t/google-maps-onebox-data-is-not-cached/59124/9 "2017-03-16T14:22:00Z")
I think you are totally misunderstanding how we use the onebox gem in Discourse.
>
In fact if you look at the actual backend code you will notice that we never use the built-in moneta cache thingy in the onebox gem.
In fact, my vote here is that we should just nuke the moneta dependency and dump cache logic built into the onebox gem and have consumers be in charge of it.
As to “allowing origin to participate in caching decisions”, well who knows, maybe an interface can be added that allows providers to pass that information on.
Regardless, Discourse uses a “dumb” cache that caches all oneboxes for 1 day unless you rebake a post or force the cache invalidation.
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [March 16, 2017, 6:08pm UTC](https://meta.discourse.org/t/google-maps-onebox-data-is-not-cached/59124/10 "2017-03-16T18:08:15Z")
> [@sam](#):
>
> my vote here is that we should just nuke the moneta dependency and dump cache logic built into the onebox gem and have consumers be in charge of it.
Yes let’s do that please. Can you add to your list @techapj?
---
### Author:  [@glebm](https://meta.discourse.org/u/glebm)
#### Post date: [March 16, 2017, 11:19pm UTC](https://meta.discourse.org/t/google-maps-onebox-data-is-not-cached/59124/11 "2017-03-16T23:19:33Z")
@sam I see, so, Discourse caches the view for 1 day regardless of the cache headers.
The onebox gem caches only the data necessary to generate the view, which has a much smaller footprint than caching the entire view, often an order of magnitude smaller.
The consumers of the gem would not be able to do that with the current interface.
The consumers of the gem also would not be able to implement cache header-aware caching because they do not have this information.
> As to “allowing origin to participate in caching decisions”, well who knows, maybe an interface can be added that allows providers to pass that information on.
If caching is left to the gem users, the interface should be changed at the same time to enable the use cases above. Otherwise, the users of the gem are left with an unsolvable problem.
> [@sam](#):
>
> I think you are totally misunderstanding how we use the onebox gem in Discourse.
Thank you for the explanation! By the way, I do not use Discourse. Only posting here because the gem has Issues disabled on GitHub.
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [March 16, 2017, 11:58pm UTC](https://meta.discourse.org/t/google-maps-onebox-data-is-not-cached/59124/12 "2017-03-16T23:58:54Z")
Thing is, there are currently 0 providers that are cache header aware, and even if the actual data required to generate a onebox is usually much smaller, we are still talking pretty tiny payloads of view.
Regardless, I am totally happy to nuke this built in caching, because I find it super complicated to follow in the code and just have `preview` return all the data required to make the decisions.
```plaintext
Onebox.preview("http://xyz") =>
{
data: {} # raw data used to render the onebox,
valid_till: ... # optionally return when it is valid till
etc...
}
```
Then you can cache `data` in the consumer, and call preview forcing data if you wish to bypass http
Feel free to work on a PR in this direction I think it is a valid change
---
### Author:  [@glebm](https://meta.discourse.org/u/glebm)
#### Post date: [March 17, 2017, 1:25pm UTC](https://meta.discourse.org/t/google-maps-onebox-data-is-not-cached/59124/13 "2017-03-17T13:25:27Z")
@sam 👍 Also, there needs to be a way to pass the cached `data` to onebox, e.g. by adding a `data` argument to `Onebox.preview`.
---
### Author:  [@techAPJ](https://meta.discourse.org/u/techAPJ)
#### Post date: [November 2, 2019, 2:23am UTC](https://meta.discourse.org/t/google-maps-onebox-data-is-not-cached/59124/14 "2019-11-02T02:23:15Z")
> [@sam](#):
>
> my vote here is that we should just nuke the moneta dependency and dump cache logic built into the onebox gem and have consumers be in charge of it.
Done via
[https://github.com/discourse/onebox/commit/8c61a33a6e4459fc267cecb7a2938fa58544bd55](https://github.com/discourse/onebox/commit/8c61a33a6e4459fc267cecb7a2938fa58544bd55)