4 ms·
Well, you didn't read the post apparently and only a title :(
by yankoff 14y ago
Well, 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...