-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
Cool! We have been building feeds on braid, too! See the "feed" spec in Braidmail: 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 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#issuecomm...
We're about to release a new braid-text library:
https://github.com/braid-org/braid-text/
This is the easiest way to add collaborative editing to a web app. You can add it to any (req, res) handler in your nodejs app.
Plus, it features a new `simpleton` merge-type that requires zero history overhead on the client, and you can implement support for in just 45 lines of client code. There's no reason not to add collaborative editing to every user-editable string in your app now!
Plus, all the network traffic is just HTTP, with an open, easy-to-read protocol that supports any OT or CRDT. You can even read and write the data directly using the Braid-Chrome extension https://github.com/braid-org/braid-chrome.
I'm really excited about this library. We were going to announce it tomorrow, but since this hacker news discussion is happening... I can't hold myself back from talking about it now!
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).
I have been using something 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
Cool! We have been building feeds on braid, too! See the "feed" spec in Braidmail: 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 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#issuecomm...