3 ms·

This allows subscriptions of changes to individual resources... but is more general event streaming a goal? Could it become so? (as in, "give me updates to all

by dagss 2y ago

This allows subscriptions of changes to individual resources... but is more general event streaming a goal? Could it become so? (as in, "give me updates to all resources", not just one). We have been using our own protocol "FeedAPI" for broker-less, multi-service event sourcing over HTTP. But it is a bit home-grown, would be great if event sourcing over HTTP was a more widespread thing with a common standard. There are so many scenarios where event streaming is a great model, but deploying Kafka is overkill, or would couple together the infra too much of publisher and consumer (e.g. different between organizations). https://github.com/vippsas/feedapi-spec https://github.com/vippsas/feedapi-spec

toomim 2y ago
Cool! We have been building feeds on braid, too! It would be very interesting to support FeedAPI with Braid -- you would get much faster pushed updates than you currently do with client-pulled updates! See our current work on the "feed" spec in Braidmail: https://braid.org/apps/braidmail/spec2 https://braid.org/apps/braidmail/spec2. To support event-sourcing, you could replace those {link: ...} objects with event objects, and just treat each event as data. Then you'd have a url like /event-stream that peers would subscribe to. Or, you could go deeper, and come up with a custom `Patch-Type:` for your events, which could make your events first-class HTTP citizens that could also be applied to a server using the PATCH method. Then your url might be /system-state, and represent the state for the whole system. Braid supports such custom events, but be aware that this model is limited in a few ways: - It's less interoperable, because all peers must know and implement the custom event types (aka patch-type) in order to read or write state. - You don't get to re-use the beautiful and complicated merge algorithms that support eventual consistency with multiple writers (the OT/CRDT algorithms). - It doesn't allow summarization of history. It's hard to prune history when each peer needs to know all events in order to do anything. You might also be interested in PREP, which is a pure event-update protocol being worked on by my colleague Rahul Gupta: https://github.com/CxRes/prep https://github.com/CxRes/prep We're trying to merge our work together, if we can. You might also be interested in our deliberation on the pros/cons of "events" vs. "state updates" here: https://github.com/braid-org/braid-spec/issues/102#issuecomment-1770468174 https://github.com/braid-org/braid-spec/issues/102#issuecomm...

by dagss 2y ago

toomim 2y ago

Cool! We have been building feeds on braid, too! It would be very interesting to support FeedAPI with Braid -- you would get much faster pushed updates than you currently do with client-pulled updates! See our current work on the "feed" spec in Braidmail: https://braid.org/apps/braidmail/spec2 https://braid.org/apps/braidmail/spec2. To support event-sourcing, you could replace those {link: ...} objects with event objects, and just treat each event as data. Then you'd have a url like /event-stream that peers would subscribe to. Or, you could go deeper, and come up with a custom `Patch-Type:` for your events, which could make your events first-class HTTP citizens that could also be applied to a server using the PATCH method. Then your url might be /system-state, and represent the state for the whole system. Braid supports such custom events, but be aware that this model is limited in a few ways: - It's less interoperable, because all peers must know and implement the custom event types (aka patch-type) in order to read or write state. - You don't get to re-use the beautiful and complicated merge algorithms that support eventual consistency with multiple writers (the OT/CRDT algorithms). - It doesn't allow summarization of history. It's hard to prune history when each peer needs to know all events in order to do anything. You might also be interested in PREP, which is a pure event-update protocol being worked on by my colleague Rahul Gupta: https://github.com/CxRes/prep https://github.com/CxRes/prep We're trying to merge our work together, if we can. You might also be interested in our deliberation on the pros/cons of "events" vs. "state updates" here: https://github.com/braid-org/braid-spec/issues/102#issuecomment-1770468174 https://github.com/braid-org/braid-spec/issues/102#issuecomm...