Wiring new Beans/Grinders/Equipment APIs data into Workflow API

[tadelv]

STUB:
discussion about how current workflow api would evolve to include references (or direct copies?) of Beans, Grinders and Equpiment objects.

[ebengoechea]

I think it is critical to rethink how these should work in REA and Streamline.js.

The Tcl app had a huge metadata design problem in my opinion in that things like beans or grinders could not easily exist outside of individual shots. As no database was used, only individual shot files were written to disk, operations such as the following were not possible (or very hard, I once implemented things like "modify all shot files in the history that used this beans" for DYE but it was tedious and slow):

• Create several beans at once (e.g. when you receive your monthly roaster subscription) before using them in a shot, then use them in shots.
• Change an existing bean field such as the name when you realize you mispelled it. Have the change apply to all shots in the history that you made with those beans.
• Create all your grinders at once, before using them in a shot, then use them in shots.
• Change an existing grinder field such as the name when you realize you mispelled it. Have the change apply to all shots in the history that you made with that grinder.
• Allow the "+/-" buttons behave differently depending on the grinder model you are using.

All of these have been constant requirements from users during the life of DYE, and were very hard to do on the Tcl app.

[tadelv]

I am preparing a draft (not typing all of it, but reading most of it) here:
https://github.com/tadelv/reaprime/blob/feature/shot-peripherals-introduction-discussion-%2366/doc/plans/beans-equipment-shot-data-schema-proposal.md

The proposal includes all new entities descriptions as well as how they would fit in the current "Workflow" workflow.

I tried to keep Visualiser and Beanconqueror as reference or at least imagine the mapping between all three, as well as the backward relationship of some fields to the OG de1app.

fyi: @ebengoechea @miharekar @graphefruit - looking forward to your input

[ebengoechea]

@tadelv This is a thorough design. Great job! A few minor considerations:

• People should be available as pre-shot data too, not just as post-shot annotation. DYE lets user define the barista and drinker on the Next-Shot page.
• As mentioned on other comments, modelling beans blends may be interesting.
• Even without explicit blends, many beans variables could be lists (like variety is), as occasionally single origin bags do mention several regions, farms, or even more than one processing.
• I think it may be useful to force bean elevation to be a numeric list, as eventually querying or analyzing data by elevation could be interesting.
• Will you be keeping profiles full definitions also as snapshots on shots? Important for DYE, which, when recalling a past shot in auto-favorite or manual copying gives the option to use the profile either exactly as was used in the old shot, or use the current version of the profile with the same name.

[tadelv]

Thanks @ebengoechea . I'll see how I can accommodate your suggestions. And yes, I am thinking of adding the profile snapshot on the shot record, same as with equipment.

Even though, John and I have a Profile API in mind, that would not use the guuid schema for identifying profiles, I think it's still sensible to keep the profile snapshotted on the record itself.

[tadelv]

@ebengoechea

A new version of the draft is available on the same branch (and link) as above, with your comments changes included (elevation, blends, pre/post-shot fields).

• also added "addedLiquid*" fields to pre-shot context, among others
• new data object(s) for Blends, can be used either on BeanBatch or at workflow context, when you're mixing two bags in a pinch, to get that shot out 😅

These would probably require (or benefit from) most review time.

cc @apaperclip, @miharekar, @graphefruit

[apaperclip]

Decaf and the comments around mixed species/bags look good. I want to reread the whole thing soon.

I've been thinking through what the workflow would look like. I know it will be driven by the the UI experience but wanted to bring it up for your thoughts.

Is the expectations that a user defines a bean first, and then associates it with a bag? Ideally it would be one step but some fields would create the bean record and others would create the bag record. For multiple or subsequent bag purchases, I would expect to clone a previous bag. I dont think I'd do much manual manipulate of the bean record.

[tadelv]

Correct! Ideally a user would populate their Bean table and then associate individual BeanBatches with the specific Beans.
The thing is, none of this is enforced by the "Bridge" app. We can go as simple or as complex as needed. At least that's what I (wish to) believe is the case right now: https://github.com/tadelv/reaprime/blob/feature/shot-peripherals-introduction-discussion-%2366/doc/plans/beans-equipment-shot-data-schema-proposal.md#116-skin-complexity-tiers

[ebengoechea]

Eveything looks neat to me. Amazing job! Enrique El El lun, 2 mar 2026 a las 16:06, Vid Tadel ***@***.***> escribió:

…

@ebengoechea <https://github.com/ebengoechea> A new version of the draft is available on the same branch (and link) as above, with your comments changes included (elevation, blends, pre/post-shot fields). - also added "addedLiquid*" fields to pre-shot context, among others - new data object(s) for Blends, can be used either on BeanBatch or at workflow context, when you're mixing two bags in a pinch, to get that shot out 😅 These would probably require (or benefit from) most review time. cc @apaperclip <https://github.com/apaperclip>, @miharekar <https://github.com/miharekar>, @graphefruit <https://github.com/graphefruit> — Reply to this email directly, view it on GitHub <#64 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAO3QUKE2S4G2RCMQHCFPD4OWPRDAVCNFSM6AAAAACV63X5PWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKOJXGMYDQMQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[tadelv]

@ebengoechea , I couldn't help - everything seemed a little over-engineered for 90% of use cases, so I tried to make a simplified approach as well.

https://github.com/tadelv/reaprime/blob/feature/shot-peripherals-introduction-discussion-%2366/doc/plans/simplified-schema-proposal.md

Maybe "simplified" is only in the name. The core difference is that the responsibility for the schema of Eqipment, Water and Taste notes as well as other metadata is deferred to the DYE2 plugin. Bridge app only provides the storage mechanisms, APIs and fields on the WorkflowContext.

I think this improves the separation between simple / advanced usage. Less "mental work" for skin developers and users with simple coffee/equipment management, with an optional, "enable all bells and whistles" mode in the bundled plugin.

Is a compromise like that acceptable for you?

[ebengoechea]

@tadelv Is a compromise like that acceptable for you?

Yes. DYE2 will even support only a subset of the simplified api. No additional beans metadata (beyond the 4 fields on current DYE) or equipment (beyond the grinder details), at least on the first version that Pulak is finishing. Still having those in REA is a big step forward and should allow DYE or other plugins to extend the initial functionallity.

[miharekar]

Can't access the file. Next time press y on keyboard to get permalink on GitHub before copying 😉

[tadelv]

@miharekar I'm pressing y but it doesn't get anything? :D

https://github.com/tadelv/reaprime/blob/64307e6e700f5e0a4a42f078337701febb2e0aca/doc/plans/archive/simplified-schema/simplified-schema-proposal.md

[miharekar]

It did - you have 64307e6 in the url now