3 ms·

Why don't more web guys use MQTT for pub/sub live data? I saw the PubSubHubBub in the comments already, but most devs are still shoe-horning HTTP into solution

Why don't more web guys use MQTT for pub/sub live data? I saw the PubSubHubBub in the comments already, but most devs are still shoe-horning HTTP into solutions that really aren't request/response based

doublerebel 10y ago
SSE makes HTTP streaming dead simple. MQTT requires a server/broker and for data to be marshaled/unmarshaled at each end. HTTP streaming can be just text. Not to mention HTTP identifies the resource by path in the URI, and easily routes right through proxies. TCP is not nearly that accessible.
jkarneges 10y ago
In general, the API community has consolidated around HTTP for realtime push, mainly because it's what developers know and it's super easy to use (you can just curl a stream for example). Another thing to know about APIs is that the endpoints tend to be resource-oriented, and resources are often abstractions. For example, when you interact with Twitter's streaming API, no doubt there are some pubsub mechanisms going on behind the scenes, but pubsub concepts such as publishers, subscribers, brokers, topics, messages, store-and-forward, etc are hidden away by the API. You just fetch a resource and get tweets. My feeling is that the most successful protocols used in APIs are going to be those that expose very little about the inner workings or topology of the server and other client entities.
- niftich 10y ago
  This; and HTTP has a massive install base, readily available clients on every platform, casual debuggability from tools many people already possess (browser address bar, browser js console, browser addons, curl). Specific protocols have their merits, but they can only really compete in the backend-to-backend space, and even there they have to compete against HTTP endpoints. In anything that can be construed as vaguely front-end, HTTP has a massive first mover advantage with the ecosystem it brings.
  - xg15 10y ago
    I wonder though, doesn't SSE technically violate a lot of HTTP's assumptions? From the point of view of a HTTP middlebox, a SSE response would basically be a single endless entity, transmitted at a very low bandwidth. I'm no expert at real-world deployment of SSE, but that they sounds to me like it could break a lot of proxies that don't have special handling for SSE. (Or at least cause unnecessary resource consumption for those proxies) Also I wonder why there are not more websocket-based APIs. WS has the same widespread support and ready-made debug tools as HTTP and seemed to be designed exactly for push or non request/response use cases. So, out of couriosity, why would SSE be prepared over WS?
    - nitrogen 10y ago
      It looks like you accidentally duplicated your comment when you changed "prepared" to "preferred".
      - xg15 10y ago
        I'm sorry. That was my attempt at "editing" the post after the noprocrast mode kicked in - before an unintelligible post would sit there for ~3 hours... If any mods could delete this, I'd be grateful.
  - xg15 10y ago
    I wonder though, doesn't SSE technically violate a lot of HTTP's assumptions? From the point of view of a HTTP middlebox, a SSE response would basically be a single endless entity, transmitted at a very low bandwidth. I'm no expert at real-world deployment of SSE, but that they sounds to me like it could break a lot of proxies that don't have special handling for SSE. (Or at least cause unnecessary resource consumption for those proxies) Also I wonder why there are not more websocket-based APIs. WS has the same widespread support and ready-made debug tools as HTTP and seemed to be designed exactly for push or non request/response use cases. So, out of couriosity, why would SSE be preferred over WS?
    - niftich 10y ago

doublerebel 10y ago

SSE makes HTTP streaming dead simple. MQTT requires a server/broker and for data to be marshaled/unmarshaled at each end. HTTP streaming can be just text. Not to mention HTTP identifies the resource by path in the URI, and easily routes right through proxies. TCP is not nearly that accessible.

jkarneges 10y ago

In general, the API community has consolidated around HTTP for realtime push, mainly because it's what developers know and it's super easy to use (you can just curl a stream for example). Another thing to know about APIs is that the endpoints tend to be resource-oriented, and resources are often abstractions. For example, when you interact with Twitter's streaming API, no doubt there are some pubsub mechanisms going on behind the scenes, but pubsub concepts such as publishers, subscribers, brokers, topics, messages, store-and-forward, etc are hidden away by the API. You just fetch a resource and get tweets. My feeling is that the most successful protocols used in APIs are going to be those that expose very little about the inner workings or topology of the server and other client entities.

niftich 10y ago
This; and HTTP has a massive install base, readily available clients on every platform, casual debuggability from tools many people already possess (browser address bar, browser js console, browser addons, curl). Specific protocols have their merits, but they can only really compete in the backend-to-backend space, and even there they have to compete against HTTP endpoints. In anything that can be construed as vaguely front-end, HTTP has a massive first mover advantage with the ecosystem it brings.
- xg15 10y ago
  I wonder though, doesn't SSE technically violate a lot of HTTP's assumptions? From the point of view of a HTTP middlebox, a SSE response would basically be a single endless entity, transmitted at a very low bandwidth. I'm no expert at real-world deployment of SSE, but that they sounds to me like it could break a lot of proxies that don't have special handling for SSE. (Or at least cause unnecessary resource consumption for those proxies) Also I wonder why there are not more websocket-based APIs. WS has the same widespread support and ready-made debug tools as HTTP and seemed to be designed exactly for push or non request/response use cases. So, out of couriosity, why would SSE be prepared over WS?
  - nitrogen 10y ago
    It looks like you accidentally duplicated your comment when you changed "prepared" to "preferred".
    - xg15 10y ago
      I'm sorry. That was my attempt at "editing" the post after the noprocrast mode kicked in - before an unintelligible post would sit there for ~3 hours... If any mods could delete this, I'd be grateful.
- xg15 10y ago
  I wonder though, doesn't SSE technically violate a lot of HTTP's assumptions? From the point of view of a HTTP middlebox, a SSE response would basically be a single endless entity, transmitted at a very low bandwidth. I'm no expert at real-world deployment of SSE, but that they sounds to me like it could break a lot of proxies that don't have special handling for SSE. (Or at least cause unnecessary resource consumption for those proxies) Also I wonder why there are not more websocket-based APIs. WS has the same widespread support and ready-made debug tools as HTTP and seemed to be designed exactly for push or non request/response use cases. So, out of couriosity, why would SSE be preferred over WS?
  - niftich 10y ago