5 ms·
There's a much better approach than /events or webhooks: add synchronization directly into HTTP itself. The underlying problem is that HTTP is a state transfer
by toomim 5y ago
There's a much better approach than /events or webhooks: add synchronization directly into HTTP itself.
The underlying problem is that HTTP is a state transfer protocol, not a state synchronization protocol. HTTP knows how to transfer state between client and server once, but doesn't know how to update the client when the state changes.
When you add a /events resource, or a webhooks system, you're trying to bolt state synchronization onto a state transfer protocol, and you get a network-layer mismatch. You end up with the equivalent of HTTP request/response objects inside of existing HTTP request/responses, like you see in /events! You end up sending "DELETE" messages within a GET to an /events resource. This breaks REST.
A much better approach is to just fix HTTP, and teach it how to synchronize! We're doing that in the Braid project (https://braid.org https://braid.org) and I encourage anyone in this space to consider this approach. It ends up being much simpler to implement, more general, and more powerful.
Here's a talk that explains the relationship between synchronization and HTTP in more detail:
https://youtu.be/L3eYmVKTmWM?t=235 https://youtu.be/L3eYmVKTmWM?t=235
- derptron 5y agoThe website seems to be crammed into the left side of my screen unnecessarily.
- top_kekeroni_m8 5y agoCentering a div is hard!
- hnbad 5y agoNot really. They could have slapped a `margin: 0 auto` on that div they decided to set a `max-width` on and called it a day.
- wruza 5y agoYou may send POST /events instead. It also breaks “REST”, which is just a sort of obsession rather than a requirement here, but more importantly it wouldn’t break idempotence and proxy caching that GET implies. Edit: from the network point of view, it’s either call-back or a persistent call-wait/socket, or polling. The exact protocol is irrelevant, because it’s networking limits and efficiency that prevent everyone from having a persistent connection to everyone. A persistent connection can’t be much better than any other persistent connection in that regard, and what happens inside is unrelated story. Or am I missing something?
- jonny_eh 5y ago> just fix HTTP Oh yes, changing HTTP is so easy.
- toomim 5y agoHTTP is actually quite malleable, and adding synchronization is easy. You can add it to your own website with a few simple headers, and a response that stays open (like SSE) to send multiple updates when state changes: https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-braid-http https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-b... ...and you can get these features for free using off-the-shelf polyfill libraries. If you're in Javascript, try braidify: https://www.npmjs.com/package/braidify https://www.npmjs.com/package/braidify