5 ms·
So, TCP over HTTP, which is a protocol built on top of TCP. Does anyone see that this is rather silly? If you want a client-side app that uses TCP, why must yo
by chewxy 14y ago
So, TCP over HTTP, which is a protocol built on top of TCP. Does anyone see that this is rather silly?
If you want a client-side app that uses TCP, why must you do it over the web? The appeal of write-once-run-everywhere?
- yankoff 14y agoWell, you didn't read the post apparently and only a title :(
- chewxy 14y agoI actually did. I was quite interested in the redis example. For about 10 seconds, which I then went "wtf is this useful for?" We really need to stop reinventing the wheel
- yankoff 14y agoWhat would you use to achieve the same thing with Redis?
- sebastianmck 14y agoThe XY Problem http://www.perlmonks.org/index.pl?node_id=542341 http://www.perlmonks.org/index.pl?node_id=542341
- chewxy 14y agoI wouldn't. I'd make a HTTP call to the server, and let the server handle it. (i.e. your "what's so different from the backend method")?
- yankoff 14y agoYep, and i wrote about differences to such approach in the post. Don't get me wrong, this is definitely a hack, I'm not saying people should stop doing it the old way.
- chewxy 14y agoLikewise. While I appreciate the concept of a bridge (I'm a strong believer that the fastest app is the app that does practically nothing at all, and I can see the benefit of using a TCP-bridge like thing to make something faster), I just think we should not be reinventing the wheel. That is to say, if you need a TCP connection to any server, you probably should not be implementing it over HTTP (well, this is where definitions get difficult, since you know, HTTP is technically TCP. Fuck)
- lttlrck 14y agoREST is far more appropriate for databases. Pub/sub is well catered for by socket.io (websockets). This glue belongs on the server. If I did need arbitrary TCP connections my first thought would be a websocket proxy...
- khakimov 14y agoit's not about pure tcp, as i get it - it allows you communicate from browser directly (via webtcp server as a bridge) with any servers such as redis, mongodb, rabbitmq and so on. WebBrowser --- data ---> WebTCP bridge (translate data to servers) --- data ---> redis/rabbitmq/any_tcp(and i think udp also possible?)_server_even_smtp
- sneak 14y agoIt's not TCP over HTTP, that would require a TCP stack. It's the io bytestream from a specific TCP connection, shuttled over HTTP. It's not entirely bogus, just mostly so. I really dislike this whole "the internet == the web" way of thinking, though.
- javajosh 14y agoOn the contrary, this sort of things allows us to write clients in a uniform way. It will be nice to be able to debug the redis client in a jsfiddle. :)
- icebraining 14y agoIt uses Websockets, which are only HTTP for the handshake: the rest of the connection is just a TCP stream. So it's really more like a NAT bridge.