API faq (memoria técnica 1º hangout) - mgaitan/preciosa GitHub Wiki

Este apunte es resultado de la charla via Hangout el jueves 20 de febrero

Los temas que charlamos tienen que ver con la arquitectura de la API relacionados con los casos de uso de la aplicación movil

Es obligatorio que el usuario se geolocalice y esté en una sucursal de super? o le dejamos consultar precios desde su casa? y para enviar precios, puede desde cualquier lado?

El usuario podrá consultar (usar la aplicación) desde donde quiera. La app le devolverá los resultados de una la sucursal mas cercana detectada.

Para enviar datos (precios) el usuario deberá previamente confirmar la sucursal, que será ofrecida en orden de probabilidad a traves de geolocalizacion "¿Estás en el Coto de Paternal?. El usuario debe poder configurar otra sucursal y agregarla.

Una vez que el usuario eligió la sucursal queda registrado en Storage/cookie y es el que se asocia a los precios que el usuario mande.

  • Tarea: Estudiar el funcionamiento de la API de geolocalizacion de Phonegap y como se consulta con estos datos a GeoDjango (sucursales más cercanas a mi ubicación)

tiene que estar autenticado para recibir precios, sólo para enviar? o es totalmente anónimo?

Debido a que es primordial la masividad de usuarios que envien precios para tener información suficiente, debemos simplificar todo lo posible.

Lo ideal es simplificar el proceso de registracion y autenticación de usuarios con google o facebook (ver ticket 73 ). Esto no sólo "hace la vida más fácil al usuario" sino que reduce en parte los potenciales usuarios vandálicos (es más costoso hacer un usuario de "facebook" para atacar preciosa)

Sin embargo, se concluyó que, para una primera etapa, es factible dejar abierto tanto para lectura como para escritura, priorizando el envio de datos por sobre la "autodefensa".

Al permitir la escritura de datos anónimos, una protección minima, contra el flooding, es limitar por IP la cantidad de consultas realizables.

  • Tarea: estudiar la factibilidad del ticket 73 y como puede utilizarse el usuario registrado de google desde teléfonos android.

la api puede recibir un request POST por cada sucursal-producto-precio o puede mandar muchos de estos datos juntos?

Se va a utilizar Storage para enviar y recibir datos en bulk.

La razón es que en los requests http la limitación actual es la latencia y no el ancho de banda: "es más rapido para un usuario recibir 50kb en 1 request, que hacer 3 requests de 3kb cada uno

Entonces: cuando un usuario configura/confirma una sucursal recibe un json con todos o un X top de productos más consultados asociados a esa sucursal, que contendrá toda la información a mostrar en cada "vista detalle" de un producto.

Asimismo, cuando el usuario confirma, agrega o corrige un precio (o crea otro objeto, ver más abajo) no impacta directamente a la API sino que queda en storage (como una cola) y en segundo plano se van enviando los precios. Esto hace que para el usuario es automatica la interacción, tanto para recibir como para enviar.

Una excepción a esto pueden ser los thumbnails de los productos, que a priori se mostrarian "bajo demanda" en la pantalla de detalle del producto. (incluso, puede ser luego de un botón "mostrar foto")

qué muestra la pantalla de detalle de un producto

Además de la descripción, url a la foto y otros detalles del producto

Se devolverá:

  • los últimos precios distintos registrados para la sucursal ordenados de más nuevo a más viejo. En la interfaz el precio más reciente aparecerá más detacado.

  • Si no hay precios para la sucursal, precio más probable para esa sucursal (puede calcularse en función de precios de la misma cadena). Será utilizado de la misma manera que el anterior.

  • Mejores X precios para un radio predefinido. Por defecto, la ciudad en la que se encuentre el usuario. (¿como se configuraría este radio?).

  • Si no hay datos para el radio/ciudad, enviar precio online de la misma cadena

Se podrán CREAR objetos que no sean "precio" ?

Sí, sucursales y productos. Esta información tendrá que quedar "marcada" como "no confirmada". Sobre todo en el caso de un precio asociado a una sucursal enviada por un usuario que entra dentro de "los mejores para un radio", debe advertirse al usuario que no estamos seguros de esa validez.

Una posibilidad para descartar sucursales "inexistentes" es evaluar a traves de su frecuencia de uso. Si aun siendo "dectactada" como la más cercana a un punto, el usuario la cambia puede considerarse como un "voto en contra". O directamente puede preguntarsele al usuario ¿Conocés este super?"

Otras cosas charladas

  • La optimización

  • Facundo Batista recomendó el libro RESTful Best Practices como "material teorico" para diseñar la arquitectura.

  • Para hacer requests ajax desde la app mobile hay que configurar el cross domain

  • A priori, que Jquery UI está bien para la interfaz, pero eso debe definirlo más quien vaya a meter más manos en la masa. Idealmente debería complementarse con Backbone para tener que manipular menos explicitamente la utilización de los datos recibidos. Ver este doc

  • El espíritu fue "todo dato nos sirve". Si hay vandalización tendrá que ver con el éxito de la app, y "entonces tu problema es otro". Los criterios de optimización a aplicar tienen que ser en función de facilitarle la vida al usuario.

¿me olvide de algo?