4 ms·

Thinking about events to me is a sign that you are probably concerned with the wrong level of abstraction. Instead, you should be thinking about building protoc

Thinking about events to me is a sign that you are probably concerned with the wrong level of abstraction. Instead, you should be thinking about building protocols, of which events may be part. To me at least, a protocol combines notions of both the means of communication, as well as the semantics of that communication. In this context of this article, I would prefer to version a protocol. That version subsumes the particular schema of the events used for that version of the protocol. If your protocol is well-designed then many of the assumptions of semantic versioning can be applied and relied on, so that parts of your system can speak an older version compatibly with a parts that speak a slightly newer version. I really wish there was more support in the major ecosystems for creating protocols and a less obsessive focus on message encodings. Oh well.

proc0 7y ago
> so that parts of your system can speak an older version compatibly with a parts that speak a slightly newer version. I think this doesn't guarantee bug-free event code at all. The usual problems would still arise, I can see at least this would create repetition in logic which doesn't scale properly with large apps. Additionally versioning is needless if you have strongly typed events that get checked at compile time. Any time you need to add an abstract feature to the event architecture, the compiler would tell you what other part of the app broke as a result.
- thelittlenag 7y ago
  > I think this doesn't guarantee bug-free event code at all. Please don't misinterpret me. The goal is to have fewer issues, not zero issues. > Additionally versioning is needless if you have strongly typed events that get checked at compile time. Any time you need to add an abstract feature to the event architecture, the compiler would tell you what other part of the app broke as a result. I disagree. Most type systems, especially those describing data, are really only good for checking syntactic consistency and not very good at semantic consistency. That is, it can tell if field changes from an Int to a String, but not if the content of a String field changes it's semantic, i.e. from a user id to an email address. Lack of ability to validate content pervades wire-appropriate encodings.
  - Archit3ch 7y ago
    Semantic consistency is at least an order of magnitude harder, in my experience.
caleb-allen 7y ago
Is this what session types are aiming to resolve?
- thelittlenag 7y ago
  From what I understand session types capture the valid state transitions, and messages for each, that define the hyper-state of the two parties communicating. This means that they are only capable of describing session-oriented protocols. But a protocol can, in theory, involve more than two parties, and not involve any kind of logical or persistent notion of a session. It's just that sessions are really, really common. That doesn't mean that session types aren't worthwhile, only that they attack the problem of safely representing one particular next-higher-level abstraction. Session types also predicated somewhat on formal guarantees being something worthwhile. As an academic exercise I'm in favor, but in terms of having practical, working tools that I can use today that useful but lack formal guarantees, well I'd rather have good tools today rather than perfect tools never. And that's my lament. I've yet to see good tools for building protocols.
  - naasking 7y ago
    > From what I understand session types capture the valid state transitions, and messages for each, that define the hyper-state of the two parties communicating. Multiparty session type systems are available [1]. [1] http://mrg.doc.ic.ac.uk/publications/less-is-more-multiparty-session-types-revisited/preprint.pdf http://mrg.doc.ic.ac.uk/publications/less-is-more-multiparty...

proc0 7y ago

> so that parts of your system can speak an older version compatibly with a parts that speak a slightly newer version. I think this doesn't guarantee bug-free event code at all. The usual problems would still arise, I can see at least this would create repetition in logic which doesn't scale properly with large apps. Additionally versioning is needless if you have strongly typed events that get checked at compile time. Any time you need to add an abstract feature to the event architecture, the compiler would tell you what other part of the app broke as a result.

thelittlenag 7y ago
> I think this doesn't guarantee bug-free event code at all. Please don't misinterpret me. The goal is to have fewer issues, not zero issues. > Additionally versioning is needless if you have strongly typed events that get checked at compile time. Any time you need to add an abstract feature to the event architecture, the compiler would tell you what other part of the app broke as a result. I disagree. Most type systems, especially those describing data, are really only good for checking syntactic consistency and not very good at semantic consistency. That is, it can tell if field changes from an Int to a String, but not if the content of a String field changes it's semantic, i.e. from a user id to an email address. Lack of ability to validate content pervades wire-appropriate encodings.
- Archit3ch 7y ago
  Semantic consistency is at least an order of magnitude harder, in my experience.

caleb-allen 7y ago

Is this what session types are aiming to resolve?

thelittlenag 7y ago
From what I understand session types capture the valid state transitions, and messages for each, that define the hyper-state of the two parties communicating. This means that they are only capable of describing session-oriented protocols. But a protocol can, in theory, involve more than two parties, and not involve any kind of logical or persistent notion of a session. It's just that sessions are really, really common. That doesn't mean that session types aren't worthwhile, only that they attack the problem of safely representing one particular next-higher-level abstraction. Session types also predicated somewhat on formal guarantees being something worthwhile. As an academic exercise I'm in favor, but in terms of having practical, working tools that I can use today that useful but lack formal guarantees, well I'd rather have good tools today rather than perfect tools never. And that's my lament. I've yet to see good tools for building protocols.
- naasking 7y ago
  > From what I understand session types capture the valid state transitions, and messages for each, that define the hyper-state of the two parties communicating. Multiparty session type systems are available [1]. [1] http://mrg.doc.ic.ac.uk/publications/less-is-more-multiparty-session-types-revisited/preprint.pdf http://mrg.doc.ic.ac.uk/publications/less-is-more-multiparty...