985804 - Have Fireplace (not Zamboni) serve Fireplace's index.html

Status: RESOLVED WONTFIX

(Marketplace Graveyard :: Consumer Pages, defect, P3)

Description

[Christopher Van Wiemeersch [:cvan]]

Right now we do this silly thing where every time we deploy, `commonplace includes` writes a numeric timestamp to this file called `build_id.txt` which Zamboni then reads in and cachebusts our assets with the aforementioned timestamp (falling back to Zamboni's `BUILD_ID` if `build_id.txt` is for some reason unavailable). We need to stop doing this global timestamp/build ID nonsense and cache bust only when each individual bundle, each favicon, etc. actually changes. (That's bug 985291.)

In order to do that, with our current architecture (with Zamboni serving our `index.html`), it would involve our passing unique build IDs from commonplace/fireplace back to Zamboni, which is getting ever silly.

Is there a reason we can't have Fireplace serve our `index.html`? It could go directly through nginx not through Django. And then we'd be able to more easily write out the correct URL hashes in bug 985291.

I forgot what the reasoning was about Zamboni serving our index.html; Jason could probably jog my memory. But let's definitely do whatever we can to do this, as it'd definitely make things easier to maintain, easier to deploy, and get us faster (since [1] nginx is awesome and [2] we'd no longer need to read from the filesystem `build_id.txt` and [3] there's probably more).

Comment 1

[Wil Clouser [:clouserw]]

Is this still relevant if we go to a packaged app?

Comment 2

[Christopher Van Wiemeersch [:cvan]]

(In reply to Wil Clouser [:clouserw] from comment #1)
> Is this still relevant if we go to a packaged app?

Yes. Because https://marketplace.firefox.com still needs to be accessible as a web site.

Comment 3

[Christopher Van Wiemeersch [:cvan]]

Today Nginx serves the consumer pages from Zamboni:
https://github.com/mozilla/zamboni/blob/master/mkt/commonplace/templates/commonplace/index.html

This bug is to make Nginx serve the consumer pages from Fireplace:
https://github.com/mozilla/fireplace/blob/master/hearth/server.html

Comment 4

[Mathieu Pillard [:mat]]

Note that having django serving that index.html has some advantages: we get opengraph for the detail page (bug 976653), waffle checks to know whether we should include persona login.js or not, and possibly if we decide to implement it, we could get geoip region directly (bug 1082855), improving performance.

Comment 5

[Christopher Van Wiemeersch [:cvan]]

There's no reason https://marketplace.firefox.com/opensearch.xml can't still be served by Zamboni (although it would be trivial to have Fireplace serve this as well). Nginx handles all the routing, so we actually wouldn't need to change anything for `/opensearch.xml`. We'd just need to make `/index.html` come from Fireplace instead of Zamboni.

Waffle checks? Yes, you're right. Is this FxA one the only one?

    https://github.com/mozilla/zamboni/blob/master/mkt/commonplace/views.py#L116

Knowing whether to include Persona login.js? Yes, you're correct - that's easier to handle on the server side and not from a static file. That part would really get complicated by this bug.

Geoip directly? Actually bug 1082855 sounds easier to achieve with our current setup where Zamboni serves the `/index.html`.

Comment 6

[Mathieu Pillard [:mat]]

Opengraph, not opensearch - it currently doesn't work for some reason (the bug is reopened), but it should give us description & image links on the app details page to help sharing on social networks and whatnot. That requires db queries that only zamboni can do without weird hacks.

Comment 7

[Christopher Van Wiemeersch [:cvan]]

(In reply to Mathieu Pillard [:mat] from comment #6)
> Opengraph, not opensearch - it currently doesn't work for some reason (the
> bug is reopened), but it should give us description & image links on the app
> details page to help sharing on social networks and whatnot. That requires
> db queries that only zamboni can do without weird hacks.

Oh, right. I read OG but I was looking at OS. You're totally right - that gets gross if Zamboni isn't doing this.

Comment 8

[[e-mail]]

Having Zamboni serve the fireplace HTML also makes it easier for the docker dev environment. 

The instant you that we want to point to fireplace's index.html you need to maintain a bunch of really annoying nginx conf to know where to route urls to whereas that's currently in the urls.py for zamboni.

So far in working on the docker stuff the nginx conf has stayed quite simple see: https://github.com/mozilla/wharfie/blob/master/images/nginx/nginx.conf.

The biggest additional win I see is maintaining the ability to do configuration via zamboni settings otherwise you punt that complexity into how the static file gets generated.

Comment 9

[[e-mail]]

See also bug 1074301

Comment 10

[Kevin Ngo [:ngoke]]

Going to wontfix this as we sometimes rely on Zamboni to pass in some data (e.g, FXA, OG, switches).