What are the best practices for creating events? - Answered

Technical Support
1

What’s the best practice for creating events?
Should I add all the data I can add?
What is the cost of creating events?
How do I balance this?

For the basics of events:
foundation sui move intro course
docs - sui events API

1 Like
2

Sam on Telegram:
The rule of thumb I suggest is to create events for information external observers need to know about that is not present in (or easily derivable from) the transaction effects.
This usually means you’ll need events a lot less often than in other platforms because the effects include all changes to objects.
The events in kiosk and DeepBook are good examples to look at I think.

1 Like
3

Damir on telegram:
We had a lot of discussions around pricing for events, and what you see today and claims that “events are cheap” may eventually change. Currently it feels like events are being abused and I see a lot of projects duplicating Kiosk events and emitting even more data around it which is hardly a good practice.

Few random notes on the events and their application:

  • for a decentralized system where one needs to track everything that is happening (eg Kiosk) events are a necessity and they should be present

  • for centralized applications I would suggest to look at what data can be fetched from tx effects and then go from that as @sblackshear correctly noted; there’re also other ways of fetching data like dryRuns

  • for some applications where a temporary state is needed only for the current user I would recommend reading objects on the spot (eg imagine a p2p game where two players challenge each other and they can read data from a shared arena w/o any events)

  • “object markers” is a fun pattern where one can store / send an object which points somewhere for the duration of a “match” or event and then the object can be burned for a storage rebate; these usually work when you need to show something in an interface for this specific user but don’t really need everyone to know

  • a common pattern that should be avoided but that I seeregurarly in events is that people add sender field while the event being a part of a transaction always has transaction sender (and a timestamp - relative to each node but precise enough)

1 Like