Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor event struct for clarity #7

Merged
merged 3 commits into from
Oct 16, 2024
Merged

Refactor event struct for clarity #7

merged 3 commits into from
Oct 16, 2024

Conversation

ericvolp12
Copy link
Collaborator

@ericvolp12 ericvolp12 commented Oct 16, 2024

This change updates the event struct to be more human-readable now that we support compression and don't need to save characters as greedily.

Motivation behind this change is to make the event stream readable for someone without having to go lookup docs on event structure. Some existing fields have been a bit cryptic with naming and with value abbreviations, making the stream less understandable to new developers.

Deprecated fields:

  • event.type -> event.kind
    • com, id, acc -> commit, identity, account
  • commit.type -> commit.operation
    • c, u, d -> create, update, delete

To support backwards compatibility for a brief window, the old fields and values will still be emitted during a migration window.

@ericvolp12 ericvolp12 changed the title Refactor event struct for clarity [WIP] Refactor event struct for clarity Oct 16, 2024
@bnewbold
Copy link

great! glad that we found a migration path. and additionally I like that there are now different words for the overall event and commit "type"; and that the field "type" won't be used in commit operations (they could be redundant/confusing with $type for records, which is what is in the collection field)

@ericvolp12 ericvolp12 changed the title [WIP] Refactor event struct for clarity Refactor event struct for clarity Oct 16, 2024
@ericvolp12 ericvolp12 merged commit 011b545 into main Oct 16, 2024
1 check passed
@mackuba
Copy link

mackuba commented Oct 16, 2024

Btw, regarding compression - are other more classic compression types like gzip or something available too, which don't require a custom dictionary and might be supported more natively by a websocket library? (I don't know if this is a thing in general in websockets)

ricardojmendez added a commit to ricardojmendez/morat-atproto that referenced this pull request Oct 17, 2024
mackuba added a commit to mackuba/skyfall that referenced this pull request Oct 19, 2024
@bnewbold
Copy link

@mackuba I don't think there is too much gain compressing individual messages with something like gzip: the messages are too short for compression to work well. in theory stream compression might work, but that doesn't fit well with the current jetstream architecture. I would recommend just disabling compression.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants