[pyar] Django como servicio web

Angel Java Lopez ajlopez2000 en gmail.com
Mar Jun 24 13:14:14 ART 2014


Muy interesante el tema!

Ni idea de Django, no se si se puede hacer en Django, pero en un
Node.js/Express, en un web framework que maneje middleware, pondria un
middleware que popule al request con los settings, de acuerdo al dominio
pedido. Los controladores/actions lo reciben, y lo pasarian (los settings)
a los servicios correspondientes. Y renderezarian los templates
correspondientes al setting recibido.

Algo como un action:

function customers(req, res) {
      customerservices.getCustomers(getTenantData(req.tenant), function
(err, list) {
.....
            res.render(getTenantPrefix(req.tenant) + '/customerlist', {
title: 'Customers', list: list, settings: getTenantViewSettings(req.tenant)
});
      }
}

o algo asi. O req.tenant que sea un objeto, con mas behavior, tipo

req.tenant.getViewPrefix()  // con el nombre a prefijar un template de view
req.tenant.getServiceData() // con informacion de la base de datos, etc...
req.tenant.getViewSettings() // con la informacion del tenant que le
interesa a la view (tipo estilo a aplicar, etc)

Mas sofisticado, en vez de usar prefijo para el nombre logico de la view a
renderizar, que calcule cual es la view:

req.tenant.getViewName(name) // dado el nombre 'customerlist', me devuelva
'acme/customerlist' si tiene una view personalizada o
'default/customerlist' si usa la view default

Pero me imagino que el settings.py debe estar incrustado en el corazon de
Django (que para mi es el que canta con Pimpinela ;-)

Nos leemos!

Angel "Java" Lopez
@ajlopez

2014-06-24 12:51 GMT-03:00 Alejandro Santos <listas en alejolp.com>:

> 2014-06-23 21:17 GMT+02:00 Manuel Kaufmann <humitos en gmail.com>:
> >
> >  * django-easyconfig (un objeto Config por cada sitio -cada sitio
> > sería una mini-django-app con View, Model y Forms específicos para
> > ella)
> >  * diferentes settings.py (para algunas pequeñas cosas que
> > django-easyconfig no cubra) con su DB particular
> >  * múltiples instancias de uwsgi con diferentes settings
> >  * un server nginx con múltiples hosts apuntando a los diferentes uwsgi
> >
>
> Nicolás Echaniz en la PyConAr Córdoba 2010 contó que estaba trabajando
> con algo así, ellos hicieron un portal personalizable por cada
> "cliente" y cada sitio sea un proyecto Django independiente, con su
> propia base de datos y tablas independientes, y su propio settings.py.
>
> Si bien tenían un servidor polenta (8 GB de ram), el problema que
> tenían era que con suficientes clientes el servidor se les quedaba sin
> RAM, porque tenían procesos django corriendo de sitios que no se
> estaban usando.
>
> Acá está el mail de Nicolás:
> http://listas.python.org.ar/pipermail/pyar/2010-October/005396.html
>
> Una de las cosas que le plantié era hacer algo al estilo de lo que
> hace "Google Apps", donde el primer "hit" al sitio hace que se levante
> el proceso Django, y después de un tiempo cuando ya no tenga
> actividad, el proceso se mate. Entonces mitad de camino entre el
> servidor web y el proceso django que haya un proceso proxy intermedio
> que hable y entienda (u)wsgi, y levante y tire automáticamente las
> instancias de Django.
>
> Me quedé un poco en el tiempo con Django, uWsgi, gunicorn, etc., y la
> verdad que ni idea si ya existe algo así, porque de otra forma habría
> que programarlo.
>
> --
> Alejandro Santos
> _______________________________________________
> pyar mailing list pyar en python.org.ar
> http://listas.python.org.ar/listinfo/pyar
>
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>
> 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/20140624/cb816f47/attachment.html>


More information about the pyar mailing list