2 ms·

Neat! Is the idea to subscribe to the websocket directly from frontend code or from an application server? It sounds like it's the latter, which seems like an

Neat! Is the idea to subscribe to the websocket directly from frontend code or from an application server? It sounds like it's the latter, which seems like an unusual use case for websockets. (or at least I can't think of anything else that does ws for a server-to-server API)

cookguyruffles 5y ago
As far as getting cheap framing and bidirectional communication over an HTTP port goes, there's nothing to stop you using websocket server->server. For example users, many crypto exchanges publish their feed this way
- codeflo 5y ago
  But why, except to claim “web-scale”? Especially for publishing events, isn’t something like MQTT a lot saner?
  - cookguyruffles 5y ago
    I already listed two, because you need - cheap framing - bidirectional comms - are already exposing an HTTP port - can make no assumptions about the client's networking than port 443 available, even if only via a HTTPS proxy - can make no assumptions about the client's software except they can speak an extremely common protocol - want security to work the same way it does for the rest of your services "web-scale" doesn't come into it. Websockets are inherently difficult to scale because they're stateful, but in return you get the lowest latency in both directions the underlying network can provide with extremely reasonable (2-4 bytes) overhead compared to raw TCP or SSL
  - megous 5y ago
    No broker.
jordan801 5y ago
Yeah! Front end apps can skip the server and get data from the db directly. There's OAuth2 setup and you can authorize users to have crud access to tables, or even a granular as rows.
throwdbaaway 5y ago
For me, this looks like the perfect implementation of a very scalable config service, where the read RPS can get very high, but the config values are rarely changed. The consumers of the config service can be either frontend applications or backend application, thus websocket is a great choice.

cookguyruffles 5y ago

As far as getting cheap framing and bidirectional communication over an HTTP port goes, there's nothing to stop you using websocket server->server. For example users, many crypto exchanges publish their feed this way

codeflo 5y ago
But why, except to claim “web-scale”? Especially for publishing events, isn’t something like MQTT a lot saner?
- cookguyruffles 5y ago
  I already listed two, because you need - cheap framing - bidirectional comms - are already exposing an HTTP port - can make no assumptions about the client's networking than port 443 available, even if only via a HTTPS proxy - can make no assumptions about the client's software except they can speak an extremely common protocol - want security to work the same way it does for the rest of your services "web-scale" doesn't come into it. Websockets are inherently difficult to scale because they're stateful, but in return you get the lowest latency in both directions the underlying network can provide with extremely reasonable (2-4 bytes) overhead compared to raw TCP or SSL
- megous 5y ago
  No broker.

jordan801 5y ago

Yeah! Front end apps can skip the server and get data from the db directly. There's OAuth2 setup and you can authorize users to have crud access to tables, or even a granular as rows.

throwdbaaway 5y ago

For me, this looks like the perfect implementation of a very scalable config service, where the read RPS can get very high, but the config values are rarely changed. The consumers of the config service can be either frontend applications or backend application, thus websocket is a great choice.