would it be possible to bundle this into browser code (e.g. with webpack)

[kulicuu]

Recently I've been doing diverse R&D on web-apps. I wanted to look into what it would take to bundle a redis-client module into a webpack-built browser application.

I had some idea that maybe, given the pub/sub capabilities and the Lua capabilities, that a redis/disque system could serve in the place of a realtime/websockets-esque web-server.

(serving the static assets constituting the app would be handled by an eviscerated (simple without controller logic or much of anything) server or even pure-CDN)

So, I'm adding this partly as a feature request, but also just looking for feedback on what it would take to implement, potential problems etc.

Hiredis seems to be an obstacle but I'm not sure how much of one.

I'm interested in working on this in a fork as a side project. Even if it wouldn't be merged, it could be something interesting, and, to me at least, probably very useful.

(edit)

Looks like the net module would be an issue also. ... Maybe a bridge to far and I'll just drop it for the time being. Still, I think it's an interesting idea and would like to hear opinions about future viability of such a goal.

edit-2

groping towards answering my own question:

• redis server using persistent TCP, browser limited to WebSocket connections.
• outside of an implementation of redis-server that can accomodate websocket connections, ... and outside of browser capabilities matching ionode's net module, nada posible
• maybe solution would be to make a minimal websocket server which is designed from the start to serve precisely & solely as a wrapper around a redis-client implementation. like a node websocket implementation on the same linode box as the redis-server(s).

[luin]

What's your purpose to run this module on the browser side?

[kulicuu]

hi ( & thanks for responding to this semi-ridiculous thread )

What's your purpose to run this module on the browser side?

Right so, I do 'fullstack' design+build of complex social-media systems (more complex featurewise than Twitter or Facebook). Realtime interaction+collaboration between multiple user-nodes is the general essential characteristic of these systems.

I'm looking at re-engineering some systems I built in the past (Bartr/Britvic). Moving from ugly mess to pristine nirvana is the goal.

My stack for Bartr/Britvic consisted of SocketStream (a NodeJS WebSocket server with some additional frameworky stuff), Redis, and AngularJS on the front end. Web-app clients are in touch with SocketStream server via WS; this handles all the logic, data layer entirely Redis.

Initially the server-side was pretty MVC flavoured, but without the direct view computations; sending just data to Angular to compute.

I realised long ago that I could eliminate most (IO) transactions to Redis by factoring out the server Model logic into Lua on Redis.

Recently I realised that if I had a direct connect from the browser to Redis I could cut out the middleman (WS server) entirely, provided static assets and initial application load service could be passed to e.g. a CDN.

Probably OT, but included for context: my ideas for ideal web-app are totally changed from last year. Then it was Angular, Jade templates, Browserify. Did some stuff with Grunt and Gulp, then early this year went to a React + Webpack build with inline CSS and markup (all CoffeeScript, no JSX); then I dropped HTML/CSS entirely and developed an all-SVG / React approach to client build, which got great results, but now I'm convinced that the future of webapp graphics presentation (talking strictly 2D) has to be WebGL (because of the performance benefits of assigning all render computation to GPU; (if there is a shim to send React.render comps to GPU that's something to look into) ). The rise of many-core systems means we need to have a concurrency /parallel-comp strategy for the browser; hoping advanced exploit of WebWorker capabilities will be adequate. WebRTC capabilities are too good to pass up (my ideal network topology is composition of P2P stuff and a centralised signals network (probably based on Redis/Disque)). Want to take advantage of cognitive bandwidth of audio channel so WebAudio. ... So, the client stack is looking like Flux (no React, just Flux), WebGL, WebAudio(lots of processing via WebRTC uptake of mic channel), WebRTC for P2P, some kind of connection to a Redis/Disque grid, and that's it. Except WebWorkers. If I can't siphon all of this stuff out to various WebWorkers, the single thread will choke on everything it's going to be attending to.

[dkrieger]

@kulicuu did you end up pursuing this approach? I am looking to do the same, as I'd rather not use a websocket server when 1) I'd need to duplicate logic in redis to scale out and 2) redis is more adaptable, compatible, and performant. The only solution I've found is to use websockify as a WS -> TCP proxy, but I worry about its performance and scalability.

Especially with the addition of streams to redis, it seems like the way to go compared with a more conceptually-heavy and rigid solution like RabbitMQ w/ webstomp plugin

[kulicuu]

I never was able to realise this idea technically; I'm still not sure if it's feasible, I've never heard anyone in the Redis community mention it, though I'm not keeping up to date totally with everything going on there.
Currently I'm researching architecture for a commercial realtime marketplace/social system, and while I was originally going with a two-layered PostgreSQL & Redis approach, I'm looking now into RethinkDB, which would reduce complexity and time to develop. Since RethinkDB push notifies the connected server, the realtime angle is well-covered.