Trace hosting server

[paulirish]

https://chromedevtools.github.io/timeline-viewer/ has the ability to load traces over XHR from any host that's providing the JSON with proper CORS headers. (The google drive integration is designed to set the right permission and use the undocumented (lol) URL that is served with CORS headers.

Ideally though, folks would be able to POST a trace to a public endpoint. That would, in turn, provide a URL where the trace is now available. And then it's just a matter of opening https://chromedevtools.github.io/timeline-viewer/?loadTimelineFromURL=<hosted trace url>

I'd be happy to foot the bill for this for now, and I feel confident I can secure a long-term billing situation.

---

Strawman proposal:

• service must be deployable on Google Cloud or Firebase
• javascript would be nice, though python could do in a pinch
• Maybe we set an expectation that traces will be deleted after 3 months or something?

User flow:

1. POST a trace to /trace/upload
2. Once uploaded the server validates that the data looks good
   • e.g. It appears to be JSON and roughly starts with {"traceEvents":[)
3. If it's a valid, the 200 response is the new url: /traces/<UUID>
   • We do sweet UUIDs like gfycat-style-urls?
   • If it's invalid or there's a problem, respond with 500
4. The client can then do whatever it needs with the trace URL, like creating the new timeline-viewer URL

I'm open to all ideas on the above. :)

[tollmanz]

Great start! I think the response should return a URL to the raw trace and a link to view it:

{
  raw: 'https://chromedevtools.github.io/traces/CuriousRedCrow',
  view: 'https://chromedevtools.github.io/timeline-viewer/?loadTimelineFromURL=https://chromedevtools.github.io/traces/CuriousRedCrow'
}

Maybe we set an expectation that traces will be deleted after 3 months or something?

Seems reasonable. I could even see this being less, but this is mostly a cost issue.

[paulirish]

I think the response should return a URL to the raw trace and a link to view it

SGTM! i dig it.

[denar90]

@tollmanz do you mean that https://chromedevtools.github.io/traces/CuriousRedCrow will be timeline viewer responsibility to fetch data from our server? No direct calls aka https://firabse/devetoolstraces/CuriousRedCrow ?
Instead, we can reduce logic done in timeline viewer to parse and populate trace data and simply do smth like https://chromedevtools.github.io/timeline-viewer/?loadTimelineFromURL=https://firabse/devetoolstraces/CuriousRedCrow

Hence sticking to your case, response will be kinda

{
  raw: 'https://firabse/devetoolstraces/CuriousRedCrow',
  view: 'https://chromedevtools.github.io/timeline-viewer/?loadTimelineFromURL=https://firabse/devetoolstraces/CuriousRedCrow'
}

[tollmanz]

@denar90 That makes a lot of sense. This is hosted on Github and would not make sense to proxy through here. Going direct to the Firebase location makes a ton of sense.

[paulirish]

@denar90 yes i think your interpretation is mostly correct. The limitation we're talking about is that we can't run any server on *.github.io.

{
  raw: 'https://traces.firebaseio.com/traces/CuriousRedCrow',
  view: 'https://chromedevtools.github.io/timeline-viewer/?loadTimelineFromURL=https://traces.firebaseio.com/traces/CuriousRedCrow'
}

Currently I think we shouldn't abbreviate the URL (like the drive://uuid we do for google drive). But it's a minor detail, either way.

[denar90]

sgtm 👍
how about our current features due to gdrive, we are keeping them, right? :)

[paulirish]

how about our current features due to gdrive, we are keeping them, right? :)

ya. later, we could extend it so the user can choose: A) save permanently in your gdrive or B) save here for 90days

[wardpeet]

happy to help where I can :)

[denar90]

attaching repo to not lose or forget about it
https://github.com/denar90/tv-uploader-cli