ADR 32: Typed Events #7474

jackzampolin · 2020-10-07T13:45:44Z

Update Events ADR

docs/architecture/adr-032-typed-events.md

Co-authored-by: Aaron Craelius <aaron@regen.network>

aaronc

ACK

I'm not sure the detailed code example at the bottom is necessary (it's hard to assess correctness) but I guess it could be useful to some people.

docs/architecture/adr-032-typed-events.md

robert-zaremba

Very clear and well structured proposal. I left few comments to:

add abstract
see if Message subscription mechanism would be better / more powerful
validate the JSON usage.

robert-zaremba · 2020-10-09T11:19:39Z

docs/architecture/adr-032-typed-events.md

+
+As the SDK gets used more extensively for apps like `peggy`, other peg zones, IBC, DeFi, etc... there will be an exploding demand for event driven applications to support new features desired by users. We propose upstreaming our findings into the SDK to enable all SDK applications to quickly and easily build event driven apps to aid their core application. Wallets, exchanges, explorers, and defi protocols all stand to benefit from this work.
+
+If this proposal is accepted, users will be able to build event driven SDK apps in go by just writing `EventHandler`s for their specific event types and passing them to `EventEmitters` that are defined in the SDK.


Agree, event driven API is very useful for app developers.
That being said, I'm wondering if designing a subscription mechanism for messages (emitted when a Msg lands into the blockchain) would solve it in a better way? Msgs already have a well defined structure and an "url" (type).

There does seem to be a lot of redundancy I agree, but events are already used pretty widely in the ecosystem and sometimes communicate things not covered in Msgs. For instance a cosmwasm contract could have the side effect of creating a gov proposal, even if the Msg submitted to the blockchain was just to call a contract.

For instance a cosmwasm contract could have the side effect of creating a gov proposal, even if the Msg submitted to the blockchain was just to call a contract.

If we go with Msg-based OCAPS (i.e. assuming both ADR031 and ADR033 get merged), this contract would need to send a MsgSubmitProposal, which in turn will emit the corresponding Msg Response.

I'd like to see a use-case in this ADR where a message subscription mechanism is not enough, as I feel ADR031 and ADR033 can get to the same goal in a more elegant way. We could of course still emit events, because of inertia in the ecosystem, but they will be Msg Responses and not typed events.

I'd like to see a use-case in this ADR where a message subscription mechanism is not enough, as I feel ADR031 and ADR033 can get to the same goal in a more elegant way. We could of course still emit events, because of inertia in the ecosystem, but they will be Msg Responses and not typed events.

I don't think it's just inertia. Does the cosmwasm use case I mentioned above not seem like something unaddressed by Msg responses?

Possibly with ADR 033 though, we can capture all of the nested Msgs that get sent between different modules and maybe it would have the same result...

Can someone link to ADR 33? I don't see the open PR...

Also this is a basic improvement to the current event system that is really low impact. It can be additive with other changes, but will make using the tendermint websocket easier for developers. I would also personally like this change for the relayer and the IBC code specifically.

One thing that isn't covered by Msg subscription is the emission of events in EndBlock. See the band protocol example: https://blog.cosmos.network/guide-to-building-defi-using-band-protocol-oracle-and-cosmos-ibc-fa5348832f84

If this proposal is accepted, users will be able to build event driven SDK apps

To clarify, these typed events are designed for external/client-side applications? I think it is very good to provide the best event support possible for them... working on consuming this since early 2018 and it has been rough getting much working out of it... almost never well tested or structured. I am very happy for such improvements.

If you are saying, as I believe some are interpreting, of using Events to communicate between modules in the SDK, then I have some hesitation. Not that it is bad, but adds a lot of potentials that need to be considered.

Anyway the use of "SDK apps" can be interpretted two ways. I would prefer "SDK modules" or "SDK clients" (and we have strong support for such clients in JS/TS... not just Go.

@jackzampolin , could you add a note that subscription to Msg doesn't solve all use cases?

@ethanfrey this work would also allow for better TS/JS libs around events as well.

docs/architecture/adr-032-typed-events.md

robert-zaremba · 2020-10-09T12:06:35Z

Improving DevX for better event driven API is really desirable. As I wrote in the comment, I would like to see if adding Msg subscription mechanism wouldn't surpass this proposal.

docs/architecture/adr-032-typed-events.md

amaury1093 · 2020-10-09T13:30:14Z

docs/architecture/adr-032-typed-events.md

+
+As the SDK gets used more extensively for apps like `peggy`, other peg zones, IBC, DeFi, etc... there will be an exploding demand for event driven applications to support new features desired by users. We propose upstreaming our findings into the SDK to enable all SDK applications to quickly and easily build event driven apps to aid their core application. Wallets, exchanges, explorers, and defi protocols all stand to benefit from this work.
+
+If this proposal is accepted, users will be able to build event driven SDK apps in go by just writing `EventHandler`s for their specific event types and passing them to `EventEmitters` that are defined in the SDK.


For instance a cosmwasm contract could have the side effect of creating a gov proposal, even if the Msg submitted to the blockchain was just to call a contract.

If we go with Msg-based OCAPS (i.e. assuming both ADR031 and ADR033 get merged), this contract would need to send a MsgSubmitProposal, which in turn will emit the corresponding Msg Response.

I'd like to see a use-case in this ADR where a message subscription mechanism is not enough, as I feel ADR031 and ADR033 can get to the same goal in a more elegant way. We could of course still emit events, because of inertia in the ecosystem, but they will be Msg Responses and not typed events.

ethanfrey

Okay, the encoding of proto -> json events and json event -> proto makes sense to me. That does seem very clean.

The one question I have is how the tendermint indexer handles these matches. How to search for 1 (uint64) vs. "1" (string). And how to search for addresses. I have no idea how this works now. I remember logs being string/string at some point now attributes are bytes/bytes. I am not the best one to answer how or if it works, it would just be good if this was tested (ideally with unit tests). No need to implement this ADR to do so. Just write some events and see how to search.

docs/architecture/adr-032-typed-events.md

jackzampolin · 2020-10-09T19:26:25Z

@amaurymartiny one usecase, Band Protocol's IBC oracle implementation that emits events in EndBlock comes to mind immediately in terms of usecases that wouldn't be met by just Msg subscriptions. I think Msg subscriptions would be useful, and a good thing. I also don't think they would replace the current event system. That will remain. We should endeavor to make it much easier to use for devs for the reason outlined in this proposal.

aaronc · 2020-10-09T21:02:56Z

I think Msg subscriptions would be useful, and a good thing. I also don't think they would replace the current event system. That will remain. We should endeavor to make it much easier to use for devs for the reason outlined in this proposal.

One thing we could do in the SDK, is just automatically emit typed events for every Msg that gets processed. Whether it's from a transaction or under the hood in the Ocaps layer (#7459). And modules can emit additional typed events if needed. What do you think @jackzampolin @amaurymartiny ?

alessio · 2020-10-10T12:13:54Z

This is indeed a great proposal!

@robert-zaremba dixit:

event driven API is very useful for app developers

I very much agree with that. and as long as we don't aim to

@ethanfrey dixit:

using Events to communicate between modules in the SDK

which this proposal doesn't seem to be about anyway (there would loads of implications that we should account for in that case) then +1 from me.

@jackzampolin thoughts? If you are OK with this, would you mind clarifying the ADR and explicitly exclude such a use case (events as inter-module communications means) from its scope?

docs/architecture/adr-032-typed-events.md

jackzampolin · 2020-10-10T15:07:50Z

@aaronc that could work. What I need is one interface I can subscribe to and get all those events as types. Currently that place is the tendermint websocket and this ADR offers an affordance for doing that. The other changes seem to be for a different purpose.

@alessio I've added the following:

This proposal is specifically about how to consume these events as a client of the blockchain, not for intermodule communication.

Also reading ADR 31, it seems like the concerns here are seprate.

… jack/typed-events

alessio

Nihil obstat from me.

ethanfrey

Thanks for the clarifications

amaury1093

One thing we could do in the SDK, is just automatically emit typed events for every Msg that gets processed. Whether it's from a transaction or under the hood in the Ocaps layer (#7459). And modules can emit additional typed events if needed. What do you think @jackzampolin @amaurymartiny ?

Yes this should cover all use cases.

Pre-approving, but I'd like to see #7474 (comment)

amaury1093 · 2020-10-12T09:04:56Z

docs/architecture/adr-032-typed-events.md

+message EventSubmitProposal {
+    string from_address   = 1;
+    uint64 proposal_id    = 2;
+    TextProposal proposal = 3;
+}


EventSubmitProposal is typically a use-case where I believe a Msg response makes more sense. With ADR031+ADR033, I would call this struct MsgSubmitProposalResponse.

Could we maybe put an example that's not directly a response from a Msg?

I think MsgSubmitProposalResponse would only include proposal_id in ADR 031. There's overlap for sure. Combining MsgSubmitProposal + MsgSubmitProposalResponse would give the same info but is maybe more cumbersome.

aaronc

@jackzampolin please add an entry to docs/architecture/README.md

jackzampolin · 2020-10-13T15:17:02Z

Ok @aaronc thanks for catching that. Ready to roll!

jackzampolin · 2020-10-13T17:12:17Z

LGTM

jackzampolin and others added 9 commits September 28, 2020 18:13

Typed events ADR

330e0ce

Update spacing in code examples

85b582f

Update context

9adaf97

Merge branch 'master' into jack/typed-events

df6e60d

Update Events ADR

2fc1cf9

Update ADR number

f633046

Rename and update ADR

027995e

Modify parseTypedEvent code in ADR

8b95d42

Merge PR #2: Update Typed Events ADR

6e5e9c1

Update Events ADR

jackzampolin requested review from aaronc, alessio and alexanderbez as code owners October 7, 2020 13:45

aaronc requested review from amaury1093, anilcse, blushi, robert-zaremba and clevinson October 7, 2020 18:29

aaronc reviewed Oct 7, 2020

View reviewed changes

docs/architecture/adr-032-typed-events.md Outdated Show resolved Hide resolved

jackzampolin and others added 2 commits October 7, 2020 12:37

Update docs/architecture/adr-032-typed-events.md

3bf2ab8

Co-authored-by: Aaron Craelius <aaron@regen.network>

Merge branch 'master' into jack/typed-events

4ca6eef

aaronc approved these changes Oct 8, 2020

View reviewed changes

docs/architecture/adr-032-typed-events.md Show resolved Hide resolved

aaronc added T: ADR An issue or PR relating to an architectural decision record T: Dev UX UX for SDK developers (i.e. how to call our code) C:baseapp C:Types labels Oct 8, 2020

robert-zaremba reviewed Oct 9, 2020

View reviewed changes

amaury1093 reviewed Oct 9, 2020

View reviewed changes

aaronc requested a review from ethanfrey October 9, 2020 15:04

ethanfrey reviewed Oct 9, 2020

View reviewed changes

docs/architecture/adr-032-typed-events.md Show resolved Hide resolved

docs/architecture/adr-032-typed-events.md Show resolved Hide resolved

docs/architecture/adr-032-typed-events.md Show resolved Hide resolved

docs/architecture/adr-032-typed-events.md Show resolved Hide resolved

Merge branch 'master' into jack/typed-events

73688cb

jackzampolin added 2 commits October 9, 2020 13:26

Merge branch 'master' into jack/typed-events

b711a7b

Address PR Comments

8504398

alexanderbez reviewed Oct 10, 2020

View reviewed changes

docs/architecture/adr-032-typed-events.md Outdated Show resolved Hide resolved

jackzampolin added 3 commits October 10, 2020 09:07

Merge branch 'master' into jack/typed-events

5e6c32e

Address PR comments

64b5ee9

Merge branch 'jack/typed-events' of github.com:ovrclk/cosmos-sdk into…

6d48bc1

… jack/typed-events

alessio approved these changes Oct 10, 2020

View reviewed changes

ethanfrey approved these changes Oct 10, 2020

View reviewed changes

amaury1093 approved these changes Oct 12, 2020

View reviewed changes

jackzampolin added 2 commits October 12, 2020 08:44

Merge branch 'master' into jack/typed-events

7b340e1

Merge branch 'master' into jack/typed-events

27442f4

aaronc requested changes Oct 12, 2020

View reviewed changes

jackzampolin added 2 commits October 13, 2020 09:15

Merge branch 'master' into jack/typed-events

9b3ca99

Add link to adr in readme

b3325ff

aaronc approved these changes Oct 13, 2020

View reviewed changes

robert-zaremba approved these changes Oct 13, 2020

View reviewed changes

alessio merged commit 36c1b24 into cosmos:master Oct 13, 2020

jackzampolin deleted the jack/typed-events branch October 14, 2020 16:08

akhilkumarpilli mentioned this pull request Oct 15, 2020

Implement ADR 032: Typed Events #7563

Open

13 tasks

anilcse mentioned this pull request Jan 26, 2021

Allow querying events by strings with double quotes tendermint/tendermint#5978

Closed

aaronc mentioned this pull request Apr 20, 2021

Add hooks to governance actions #9133

Merged

9 tasks

aaronc mentioned this pull request Aug 15, 2024

[Feature]: Consider using schema/appdata event model in core/app #21312

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

ADR 32: Typed Events #7474

ADR 32: Typed Events #7474

jackzampolin commented Oct 7, 2020 •

edited

Loading

aaronc left a comment

robert-zaremba left a comment

robert-zaremba Oct 9, 2020

aaronc Oct 9, 2020

amaury1093 Oct 9, 2020 •

edited

Loading

aaronc Oct 9, 2020 •

edited

Loading

aaronc Oct 9, 2020

jackzampolin Oct 9, 2020 •

edited

Loading

jackzampolin Oct 9, 2020

ethanfrey Oct 9, 2020

robert-zaremba Oct 12, 2020

jackzampolin Oct 12, 2020

robert-zaremba commented Oct 9, 2020

amaury1093 Oct 9, 2020 •

edited

Loading

ethanfrey left a comment

jackzampolin commented Oct 9, 2020 •

edited

Loading

aaronc commented Oct 9, 2020

alessio commented Oct 10, 2020

jackzampolin commented Oct 10, 2020 •

edited

Loading

alessio left a comment

ethanfrey left a comment

amaury1093 left a comment

amaury1093 Oct 12, 2020 •

edited

Loading

aaronc Oct 12, 2020

aaronc left a comment

jackzampolin commented Oct 13, 2020

jackzampolin commented Oct 13, 2020


		As the SDK gets used more extensively for apps like `peggy`, other peg zones, IBC, DeFi, etc... there will be an exploding demand for event driven applications to support new features desired by users. We propose upstreaming our findings into the SDK to enable all SDK applications to quickly and easily build event driven apps to aid their core application. Wallets, exchanges, explorers, and defi protocols all stand to benefit from this work.

		If this proposal is accepted, users will be able to build event driven SDK apps in go by just writing `EventHandler`s for their specific event types and passing them to `EventEmitters` that are defined in the SDK.

ADR 32: Typed Events #7474

ADR 32: Typed Events #7474

Conversation

jackzampolin commented Oct 7, 2020 • edited Loading

aaronc left a comment

Choose a reason for hiding this comment

robert-zaremba left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

amaury1093 Oct 9, 2020 • edited Loading

Choose a reason for hiding this comment

aaronc Oct 9, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jackzampolin Oct 9, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

robert-zaremba commented Oct 9, 2020

amaury1093 Oct 9, 2020 • edited Loading

Choose a reason for hiding this comment

ethanfrey left a comment

Choose a reason for hiding this comment

jackzampolin commented Oct 9, 2020 • edited Loading

aaronc commented Oct 9, 2020

alessio commented Oct 10, 2020

jackzampolin commented Oct 10, 2020 • edited Loading

alessio left a comment

Choose a reason for hiding this comment

ethanfrey left a comment

Choose a reason for hiding this comment

amaury1093 left a comment

Choose a reason for hiding this comment

amaury1093 Oct 12, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aaronc left a comment

Choose a reason for hiding this comment

jackzampolin commented Oct 13, 2020

jackzampolin commented Oct 13, 2020

jackzampolin commented Oct 7, 2020 •

edited

Loading

amaury1093 Oct 9, 2020 •

edited

Loading

aaronc Oct 9, 2020 •

edited

Loading

jackzampolin Oct 9, 2020 •

edited

Loading

amaury1093 Oct 9, 2020 •

edited

Loading

jackzampolin commented Oct 9, 2020 •

edited

Loading

jackzampolin commented Oct 10, 2020 •

edited

Loading

amaury1093 Oct 12, 2020 •

edited

Loading