Graph gists

[obfuscurity]

This would provide a workflow around transient (read: mocking) or snapshot graphs. There are two proposed workflows that would seem useful:

• User A begins mocking up a new graph but wants to share it with User B before saving it as a real graph. Perhaps User B makes some changes or comments (discussion) surrounding the graph. They collaborate on it and eventually save it as a real graph.
• User C has an existing saved graph and wants to share a particular view/event with someone outside the company (without access to Descartes or their Graphite server). The graph is snapshotted, both as metadata in the db and as an image on S3. This provides a hashed url that can be shared with anyone publicly.

Gists would have their own section within Descartes, with complete search functionality. If the gist is associated with a saved graph, its profile page would reference that graph accordingly.

Conversely, any graphs with associated gist snapshots would contain some sort of gallery view of snapshots within the graph profile view.

[obfuscurity]

Some input ideas:

• taking a "snapshot" of an existing graph
• pasting a json representation of the graph params
• using the to-be-designed graph constructor UI

[obfuscurity]

Totally want this now so I can "bookmark" graphs for later use.

[brntbeer]

I love the idea of pasting a json representation to get a mock/test of a graph out. 👍'ing this simply for testing and disposable purposes. I'm new to this project so i cant totally wrap my head around the details, but im not quite certain how you'd take this mock and make it a real graph? plz2explain

[obfuscurity]

@tehviking pointed me to https://github.com/jnicklas/carrierwave which should be useful for image conversion and file management with Sequel and S3. Still need to figure out how we'd convert the D3 SVG asset into an actual image first.

[obfuscurity]

github/ops#23

[obfuscurity]

After (ahem) 5 months of meditation, I think that instead of taking an honest-to-goodness image snapshot and storing that in S3, we should instead be capturing the data returned by Graphite and storing that in postgres. One of the things that bothers me about capturing an image is that the data immediately stops being interactive. By storing the data we can manipulate it and transform the chart as we see fit at some later date.

[damm]

Perhaps i'm a bad net-citizen but I tend to upload the png's directly into gist.

It works for me, and I am able to make the original 'gist' context about the graphs i'm sharing.

(ignore this if it doesn't help)

[obfuscurity]

Sorry guise, I've done a really bad job explaining what this feature entails. I should have focused the description on the practical goals rather than the implementation. It doesn't help that I'm applying the "gist" name to something that really has nothing to do with GitHub gists; rather, it is intended to be a meta snapshot of data in time.

The goal of this feature is to preserve information around a specifc metric or state of metrics for a defined period. Although it is analogous to simply taking a screenshot of a graph, we really want something that remains interactive while at the same time avoiding the loss of granularity that otherwise comes with the aging/rollups of Graphite metrics. Originally I envisioned that we would simply grab the png, upload it to S3, store some metadata about it, and then recall that image at various times in our workflow.

Rather, we should be storing the data itself as returned by Graphite (presumably the json output) and using that to recreate and interact with live graphs. Any data that needs to be shared "publicly" (as alluded to in the original description) can be accomplished by screenshotting the client-side image, uploading to S3, and then handing that url out.

Hope this makes a little more sense.

[damm]

Oh totally makes sense :) Sorry about that.

[obfuscurity]

No need to apologize. Clearly I've done a 💩 job of explaining the feature.

[obfuscurity]

Per the work done in #86 we can now "snapshot" a graph metadata (and source data) into the Gists model for later retrieval. There isn't anything in the UI to take advantage of this... yet.

[obfuscurity]

#18

[obfuscurity]

Today I've been thinking about the association between Gists and Graphs and how "loose" they should be. When we take a gist snapshot, we gather all of the configuration and datapoints that represent the current state of the graph being viewed and store that. We want to be able to look at gists as snapshots over time of the original graph. However I also think gists should behave like forks of the original graph, with the ability to create a new Graph from the gist at a later date.

When we Graph#destroy we also cascade delete the associated Gists. I wonder if this is the correct behavior, and if not, how to rework the model in such a way that we have a "loose" association wherein we can benefit from foreign keys when the parent Graph exists, but not be so tightly coupled that deleting a Graph breaks any child Gists.

Thoughts?

/cc @b @jnewland because they've expressed an interest in this feature in past conversations.