Live data from Hacker News

Telegraphy: Real-time events for WSGI Python applications

telegraphy.machinalis.com

1–10 of 12 posts

Re: Telegraphy: Real-time events for WSGI Python applications

#3
This seems to really help bridge a gap in django's toolbox. Working with async actions with pretty much anything other than celery processes is pretty painful. That said I'm not sure I'm a huge fan of tying the events directly to the models, I think I'd rather be able to define the events separately and call the event-firing methods via on save / on delete model methods if I wanted to the model to fire events. Seems a lot more flexible to break that apart so I can reuse the events or fire those events from somewhere other the models if needed. I bet there is a way to do this already in the project I just haven't had enough time to piece it together yet.

Re: Telegraphy: Real-time events for WSGI Python applications

#4
Sounds cool. I have also been thinking about developing a ready-made Django skeleton with an architecture similar to this. Our publishing looks like this: Django -> Redis -> Express.js -> Browser

Redis really just serves as our bridge, the actual pub/sub happens in socket.io in the express app. The coolest part of this is that when a Django model is updated, we serialize it to its API representation, send that through the wire. On the client, the Backbone model is bound to this event and updates in place.

Re: Telegraphy: Real-time events for WSGI Python applications

#5
post #2

I think this link http://telegraphy.readthedocs.org/en/latest/intro.html is far more informative than op's. I had no idea what telegraphy was after reading the posted link.

Yeah the architecture diagram helps out a lot. The XML-RPC link from the app to the gateway seems a bit old-fashioned. Is that common in Django?

Re: Telegraphy: Real-time events for WSGI Python applications

#8

This seems to really help bridge a gap in django's toolbox. Working with async actions with pretty much anything other than celery processes is pretty painful. That said I'm not sure I'm a huge fan of tying the events directly to the models, I think I'd rather be able to define the events separately and call the event-firing methods via on save / on delete model methods if I wanted to the model to fire events. Seems…

Custom events are easy to implement, though we focused in model events as we wanted something with minimal effort to push data to the client. The event class only needs to know what the django->gateway transport is (xmlrpc as for now).

Re: Telegraphy: Real-time events for WSGI Python applications

#9

Sounds cool. I have also been thinking about developing a ready-made Django skeleton with an architecture similar to this. Our publishing looks like this: Django -> Redis -> Express.js -> Browser Redis really just serves as our bridge, the actual pub/sub happens in socket.io in the express app. The coolest part of this is that when a Django model is updated, we serialize it to its API representation, send that throug…

One of telegraphy's milestones is to generalize the event tansport in the server side. Redis, ZMQ and other pub/sub libs can offer more flexibility and performance than xmlrpc.

Re: Telegraphy: Real-time events for WSGI Python applications

#10
post #2

I think this link http://telegraphy.readthedocs.org/en/latest/intro.html is far more informative than op's. I had no idea what telegraphy was after reading the posted link.

Yeah the architecture diagram helps out a lot. The XML-RPC link from the app to the gateway seems a bit old-fashioned. Is that common in Django?

Not at all - I don't think I've ever seen XML-RPC used in a Django project or library. It's more common in the Twisted world though, and this project's default implementation uses Twisted.
Post reply on HN