Allow user to switch between "app blueprint" and "recording blueprint"

[jleibs]

Context

Blueprint APIs make it somewhat easy to create "recording coupled blueprints". By this I mean your entity tree is not fixed for the app, but dynamic in some way, and that the blueprint is programmatically generated based on knowledge of that data. For example, I could easily modify the stocks example to take --stocks NVDA,AMD as a CLI parameter. The blueprint code iterates over the stock ticker values, so it would do the "right" thing.

Everybody is happy right up until you try to run the app twice in the same viewer:

python blueprint_stocks/main.py --stocks NVDA,AMD
python blueprint_stocks/main.py --stocks MSFT,AAPL

Now I have two recordings in my viewer, they share the app-id "blueprint_stocks", and both of them are trying to use a blueprint that's been hard-coded to only do queries about MSFT and AAPL.

Workarounds

Our only workaround for this at the moment is to tell users something like "Generate a dynamic app-id based on your data" which is not only ugly but practically annoying since it potentially means doing a bunch of work prior to even initializing rerun.

Proposal

Introduce a separation of two blueprint concepts

• app blueprint
• recording blueprint

When a recording + blueprint are sent to the viewer together, that blueprint becomes the "recording blueprint" for that recording.

• Note: One possibility to clearly indicate that a blueprint should be treated as the recording-specific blueprint is to use the same internal id as used by the recording. That is the id field would match, but the kind field would be different in StoreId.

Add a button somewhere (probably the new recording panel) along the lines of "Clone as the app blueprint for app_name_here"

• My thought is cloning here rather than linking avoids situations where editing the app edits the recording-specific blueprint (which will only be editable if the given recording is open).

Add a toggle somewhere (probably in the blueprint panel?): "Switch to App Blueprint" <-> "Switch to Recording Blueprint"

• I suspect the value of this toggle should act as a mode of the app rather than the recording. Meaning if you toggle to the "App blueprint" that should continue to persist as you click through different recordings. But this probably needs some experimentation.

If you receive a recording and we have no current app-blueprint, we should create one.

• If the recording includes a blueprint we should use that.
• If you receive a recording and we have no current app-blueprint, we create a new app blueprint that's driven from heuristics.

More Notes / Questions

Transparency into what's going on here will be one of the biggest challenges. Can we make this state visible enough to be useful rather than confusing. There are definitely a number of UI questions lurking in here we need designs for quickly.

We already persist a blueprint-per-app to our special blueprints folder. Should we also persist per-recording blueprints in the case where a user has made local changes to a recording-specific blueprint and then re-opens that recording again. This seems like it would be nice to have, but we could probably require them to do something like re-save the recording with the updated recording-specific blueprint.

It could worth adding an indication to the Blueprint APIs that a blueprint is intended to be a recording-specific blueprint. This could slightly change the behavior. If we know that the blueprints for an app are intended to be blueprint-specific, the maybe we don't create an app-specific blueprint, and we leave the app toggle at viewing the recording blueprint.

Related to the above, can we detect that an app-specific blueprint is likely to be interesting. If a blueprint is marked as an app-blueprint and is has content that didn't exist in the original app-blueprint (not whatever modifications the user has made on top), there's a good chance we should notify them to look at this new blueprint and decide if they want to make it the new app-blueprint.

[emilk]

Related:

• 5298

• 5629

[jleibs]

Pushing to post 0.15. For 0.15 we'll recommend the "Generate a dynamic app-id" workaround.