[pyar] Usar cache en Django

Augusto adtononi en gmail.com
Lun Sep 16 12:44:31 -03 2019


Entiendo lo que me decís. Eso claramente debería hacerlo antes de que el
usuario se loguee, pero en qué parte?
Porque las noticias que un usuario puede ver están sujetas a su plan de
suscripción, no podría cachear todas de manera indiscriminada.
Debería armar un proceso que corra cada determinado tiempo, para cada
usuario, que vaya cacheando? Si es así, como lo implentearía en Django?
Tendía que ir en alguna parte en especial?

Gracias!

El lun., 16 sept. 2019 a las 12:39, Francisco J Capdevila (<
fjcapdevila en gmail.com>) escribió:

> Podrías "precalentar" la caché haciendole un requests a cada una de las
> noticias, de esa forma las noticias ya estarían cargadas en la caché antes
> de que los clientes reales las pidan. En el peor de los casos, si alguna
> noticia es nueva o no fue pre-cargada por algún motivo, en el primer
> request seguirá el camino lento de pegarle a la API detrás, cachear la
> respuesta y servir el contenido.
> Es medio hackish, pero como primera aproximación debería alcanzar.
>
> Francisco J. Capdevila
>
>
> El lun., 16 sept. 2019 a las 12:34, Augusto (<adtononi en gmail.com>)
> escribió:
>
>> Bueno, encontré en la documentación sobre memcached. Configure como
>> indica y pude notar que ahora es mucho más óptimo. Solo hace el request la
>> primera vez, después accede muy rápido.
>>
>> Ahora tengo una duda,hay alguna forma de que todas las noticias (porque
>> los links son noticias en distintas categorías) estén ya cargadas? Para
>> leer cada noticia se hace un request, lo cual no es nada óptimo. Como
>> podría evitar esto? Acuerdense que no tengo acceso a la BBDD, solo una API
>> que hace el request a ella: la url recibe el ID de la noticia.
>>
>> El lun., 16 sept. 2019 a las 11:50, Augusto (<adtononi en gmail.com>)
>> escribió:
>>
>>> Buenas grupo, perdón por tantos mails pero todo esto es nuevo para mi y
>>> me lo pidieron en el laburo, así que voy aprendiendo a patadas jaja
>>>
>>> Les comentó la situación: estoy desarrollando un sitio y como sabrán
>>> (por los mails anteriores) decidí usar Django. Este sitio solo es accesible
>>> por usuarios suscriptos.
>>>
>>> Cuando un usuario se loguea, el usuario y password van a parar a una URL
>>> de una API la cual a su vez se conecta con una BBDD.
>>> El sitios es de noticias, así que el mayor problema acá es el siguiente:
>>> Cada vez que un usuario quiere ver una noticia, una sección, una
>>> categoría, etc, le pega a la API. O sea que hace un request en cada acción.
>>> Esto está hecho así de antes, y me dijeron que no puedo tener acceso a la
>>> BBDD.
>>>
>>> Por eso se me ocurrió usar cache. La idea sería primero que la
>>> información disponible del usuario se cargue cuando este se loguea, y no a
>>> medida que hace un request.
>>> Y después, usar cache para que por ejemplo si apriete sobre una noticia
>>> ya leída, que no haga un request sino que acceda por cache.
>>>
>>> No sé si me explique bien, y si cache es justamente lo que estoy
>>> buscando. Cualquier ayuda es bienvenida, al ser nuevo en esto de backend
>>> tampoco sé muy bien como googlearlo.
>>>
>>> Saludos!
>>>
>> _______________________________________________
>> Lista de Correo de PyAr - Python Argentina - pyar en python.org.ar
>> Sitio web: http://www.python.org.ar/
>>
>> Para administrar la lista (o desuscribirse) entrar a
>> http://listas.python.org.ar/listinfo/pyar
>>
>> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
>> Argentina - http://www.usla.org.ar
>
> _______________________________________________
> Lista de Correo de PyAr - Python Argentina - pyar en python.org.ar
> Sitio web: http://www.python.org.ar/
>
> Para administrar la lista (o desuscribirse) entrar a
> http://listas.python.org.ar/listinfo/pyar
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
> Argentina - http://www.usla.org.ar
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20190916/0264629a/attachment.html>


Más información sobre la lista de distribución pyar