infra: suffix index.js and worker url with md5

[stephanwlee]

TensorBoard resources, especially JavaScripts, are not tiny yet they are
not being cached at all by clients. As such, users are downloading large
amount of content every time browser refreshes and it impacts:

• above the fold time load latency
• server utilization

This change mitigates above two problems by giving us an ability to
leverage caching by creating a unique resource url with md5 hash of the
file.

Do note that browsers treat, for example, index.js differently than
index.js?random_query.

Internal change: cl/351171360
Test CL: cl/351209032

[wchargin]

Cool. I’m okay with a new binary and macro for this. The more we have,
the more I consider defining something like a custom Jinja context with
filters for inlining base64 images, computing file digests, transcluding
files, etc. That way we could have fewer ad hoc genrules everywhere.

[wchargin]

Lovely; thanks!

[stephanwlee]

Moved the macro to tensorboard/defs/internal/resource.bzl.
Rationale: having everything stuffed into defs.bzl or large bzl file makes it harder to do internal transformations so let's break .bzl down?

Please TAL.

[wchargin]

I don’t entirely understand the internal/external structure—why not move
the contents of defs/internal/resource.bzl to defs/js.bzl?—but no
major objection.

[wchargin]

s/md5/hash/

[stephanwlee]

Any folder with word internal is regarded as an internal set of rules and it disallows other packages like What-If tool to reach in. defs/js.bzl re-exports only what is supposed to be public but in this case, I am not even sure if I want this to be a public rule/macro. Did that address your question?

[wchargin]

Any folder with word internal is regarded as an internal set of rules and it disallows other packages like What-If tool to reach in.

Interesting; I didn’t know this. I don’t entirely understand, since we
load @io_bazel_rules_webtesting//web/internal:platform_http_file.bzl
in our third_party/workspace.bzl. Isn’t that an external package?

I also don’t quite get why it’s valuable to declare this macro in an
internal .bzl file given that we re-export it from js.bzl. Wouldn’t
the What-If Tool be able to access it through js.bzl anyway?

Agreed that it would be nice to avoid random Google packages taking a
dependency on the macro, but my understanding was that this isn’t
possible. That said, since the expanded macro depends on
:resource_digest_suffixer, does it suffice to limit the visibility of
that binary to //tensorboard:internal (which you’ve done)?

[stephanwlee]

Interesting; I didn’t know this. I don’t entirely understand, since we
load @io_bazel_rules_webtesting//web/internal:platform_http_file.bzl
in our third_party/workspace.bzl. Isn’t that an external package?

Technically, it is not a violation at Bazel level but buildozer would scream foul. If you disregard those lint warnings, I guess it has no powers. In other words, it is not Barlog proof.

[wchargin]

I see. In any case, like I said, no major objection; please don’t feel
blocked on my behalf.