2010-01-24 12 views
14

Me gustaría crear una aplicación Django reutilizable que maneje las actualizaciones de estado de los Usuarios. Muy parecido al "feed de noticias" de Facebook.Django-way para crear un "News Feed"/"Actualización de estado"/"Activity Stream"

Los casos de uso incluyen, por ejemplo:

  • Un profesor puede crear una asignación debido a una fecha específica y cada estudiante puede ver en el canal de noticias que se creó la asignación, con una breve descripción, la fecha que es debido y un enlace para ver la descripción completa.
  • También puede cargar un nuevo PDF que encuentre interesante para sus alumnos. En el feed de noticias, debe mostrarse la información al respecto, por ejemplo, la descripción del pdf, un enlace para descargar y un enlace para obtener una vista previa de él.
  • Un enlace a un vídeo de YouTube puede ser publicado y en el News Feed es muestra una pequeña miniatura y, con un clic, el vídeo se embbeded usando javascript y el usuario puede ver de inmediato.

Una preocupación es cómo manejar diferentes tipos de actualizaciones y mostrar el "fragmento de html" correcto para ello. El otro, que es más importante, es cómo diseñar los modelos de esta "manera de Django".

Sobre la primera, lo que podía pensar dos maneras de hacerlo:

  1. utilizando la herencia Modelo;
  2. Uso de relaciones genéricas.

He buscado antes de publicar aquí, pero no he encontrado nada. Revisé Pinax para ver si lo habían implementado, pero no es así. Por lo tanto, estoy buscando más sugerencias sobre cómo manejar esto de una manera agradable y no hacky.

Gracias de antemano,

+1

Tener una mirada un t cómo hacemos la creación de plantillas aquí: https://github.com/GetStream/stream-django#templating La etiqueta de la plantilla personalizada lo hace todo muy limpio. – Thierry

Respuesta

6

que se me ocurre de dos maneras:

En primer lugar, tal vez usted podría hacer feeds para sus modelos Assigments, PdfFiles y Youtube link, y el uso de la biblioteca feedparser para incrustarlo en sus puntos de vista de usuarios, esta es la manera fácil porque puede definir en las plantillas el código para cada clase de actividad nueva.

La segunda cosa que se me ocurre es hacer una clase Activity:

class Activity(models.Model): 
    date = models.DateTimeField(auto_now_add = True) 
    content_type = models.ForeignKey(ContentType) 
    object_id = models.PositiveIntegerField() 
    content_object = generic.GenericForeignKey('content_type', 'object_id') 

Y a través de la signals crea una nueva instancia de la Actividad cada vez que tenga una nueva assigment o pdf carga o link de youtube, y para cada clase de realizar un método como render_to_html, de esta manera, en su opinión, se puede hacer una de más de Actividades y llame al método render_to_html

+0

¡Hola, diegueus9! Gracias por señalar el marco de alimentación. Lo he visto vinculado en los documentos, pero nunca lo he comprobado. Acerca del modelo de actividad, parece ser la mejor manera de hacerlo. – Tiago

+1

Hola Tiago, es un placer, si necesitas más ayuda con ContentType framework o señales, no dudes en contactar con mw. – diegueus9

+0

Ambos enlaces están muertos:/ – Hankrecords

3

Las relaciones genéricas sería el camino a seguir aquí. Solo asegúrese de resolver el modelo usted mismo en lugar de unirse contra la tabla de actualización.

+0

Hola Ignacio, ¿qué quieres decir con "resolver el modelo tú mismo"? ¡Gracias por la respuesta! – Tiago

+1

Utilice los diversos métodos 'ContentType' para obtener la clase de modelo adecuada en lugar de introducir el campo' GenericForeignKey' directamente. –

+0

Gracias por la aclaración, Ignacio! – Tiago

4

Después de más googlear y una palabra clave útil ("Actividad") que diegueus9 mencionado y que no he pensado antes, pude encontrar material más relevante.

En primer lugar, dos entradas de blog sobre cómo construir un tumbleblog usando Django usando la ContentType marco:

Después de eso, otro post que da sugerencias sobre cómo reducir el problema de consultas (1 + n) (que fue una de mis preocupaciones al principio, pero no lo mencioné para evitar abarrotar la pregunta).

Y por último, una aplicación Django reutilizable que tiene algunas de las características que necesitaba y puede ser útil para mayor referencia:

+4

Aquí hay otra aplicación de secuencia de actividad (vinculada a la que se pegó más arriba) que podría ser mejor (supuestamente más simple + más autores, más actividad) https://github.com/justquick/django-activity-stream – toast38coza

14

Python es en realidad un excelente lenguaje para crear Flujos de actividades y Noticias. Tommaso y yo escribimos el paquete de Stream Framework. https://github.com/tschellenbach/stream-framework Actualmente es la solución de Python más utilizada para generar noticias. También estamos ofreciendo una solución alojada en https://getstream.io. El cliente Django es, con mucho, el más fácil de empezar a trabajar con: https://github.com/GetStream/stream-django y Python se puede encontrar aquí (https://github.com/getstream/stream-python)

La parte de plantillas funciona así

{% load stream_django %} 

{% for activity in activities %} 
    {% render_activity activity %} 
{% endfor %} 

Esto hará que una plantilla situada en la actividad/tweet.html con la actividad como contexto. Por ejemplo

{{ activity.actor.username }} said "{{ activity.object.body }} {{ activity.created_at|timesince }} ago" 

Los documentos completos están aquí: https://github.com/GetStream/stream-django#templating

El Marco de corriente le permite construir cualquier tipo de suministro de noticias usando Redis o Cassandra. Se desarrolla a escala y crea las fuentes de noticias individuales mediante un proceso de fanout.

Además de Stream Framework (que obviamente prefiero), existen muchas otras soluciones.Hay una lista completa disponible en los paquetes django: https://www.djangopackages.com/grids/g/activities/

Tenga en cuenta que con las fuentes de noticias hay que tener en cuenta algunos problemas de escala. En general hay 3 enfoques comunes:

estrategias Denormalization

Tire La mayoría de los usuarios comienzan a cabo de esta manera. Cuando abre la página de alimentación, simplemente consulta los feeds de todos los usuarios que sigue. Si las fuentes de los usuarios se almacenan en la memoria, esto seguirá funcionando durante bastante tiempo. Finalmente, es bastante difícil seguir usando estrategias, ya que a menudo tiene que consultar la mayoría de los nodos que almacenan los feeds de sus usuarios.

Empuje El enfoque push escribe su actividad en todos los seguidores de sus seguidores. Por supuesto, esto significa que está desperdiciando una tonelada de recursos, pero el resultado final es un feed pre calculado por usuario. Este enfoque (aunque inicialmente no es muy eficiente) escala muy bien.

Combinación Algunos sistemas optimizados utilizan una combinación de estos dos enfoques. También vea el documento de Yahoo sobre este tema.

Las opciones de almacenamiento

En términos de almacenar todos estos datos las opciones más comunes son Redis, Cassandra y MongoDB. Vamos a comparar rápidamente los siguientes:

Redis Redis es extremadamente fácil de instalar y mantener. Sin embargo, solo almacena datos en la memoria. Esto significa que tendrá que optimizar la forma en que serializa los datos y tal vez recurrir a la base de datos para buscar datos con menor frecuencia. Otro problema es que no es trivial agregar máquinas a su clúster de Redis.

MongoDB Mongo DB es utilizado principalmente por unos pocos proyectos de rubí y también está disponible como backend para pump.io por e14n. Personalmente, nunca lo ejecuté en producción, por lo que no puedo evaluar correctamente esta opción. Sin embargo, hay una gran cantidad de publicaciones de blog que cubren problemas con el rendimiento, la escalabilidad y la facilidad de mantenimiento de mongo.

Cassandra Fashiolista, Instagram y Spotify usan Cassandra. Nuestra solución alojada también usa Cassandra como un back-end. Es extremadamente rentable operar y puede agregar más nodos con facilidad. El único problema es que es difícil de configurar y mantener.

artículos

Además tienen un vistazo a este alto cargo escalabilidad se nos explican algunas de las decisiones de diseño que participan: http://highscalability.com/blog/2013/10/28/design-decisions-for-scaling-your-high-traffic-feeds.html

Para aprender más acerca de diseño de alimentación le recomiendo la lectura de algunos de los los artículos que nos basamos en Feedly: