ui-771829_640

En el diseño de los servicios de una empresa, se suelen distinguir dos tipos de servicios:

  1. los que están orientados para su consumo interno por las propias aplicaciones y servicios de la empresa
  2. los que están diseñados para ser consumidos fuera de la emprea

Al primer grupo pertencen los servicios de núcleo, es decir, aquellos servicios simples o compuestos que exponen directamente lógica de negocio del sistema, que podríamos llamar de negocio “puros” y que van a ser usados directamente o que van a formar parte de una composición de servicios.

Estos servicios suelen tener una vida más longeva y ser un poco más “estables”. En la práctica, esto viene a decir que cambiar estos servicios core de una empresa suficientemente grande puede llevar mucho tiempo, incluso años.

En el segundo grupo están aquellos que queremos ofrecer a terceras empresas de todo tipo. Bien mediane acuerdos del tipo B2B con otras grandes empresas, o también a ser expuestos como un API para que cualquier interesado pueda construir sus aplicaciones haciendo uso de nuestra funcionalidades de negocio.

Se suele decir también que estos servicios sean más dinámicos y más cambiantes ya que se tienen que adaptar a las condiciones del mercado. Estos servicios, lo que hacen realmente es exponer la funcionalidad de los servicios de negocio pero adaptándolos al consumidor al que van dirigidos.
¿Y cuáles son estos consumidores realmente? los disposivos móviles, mediante webs o por supuesto, mediante apps. Esto nos lleva a la siguiente reflexión:

¿En qué se diferencian las apps móviles de las webs de escritorio?
Tradicionalmente veníamos considerando la menor capacidad de los dispositivos móviles, sobre todo en lo relativo a CPU y memoria, para ejecutar tanto las apps como las webs móviles. Sin embargo, con el paso del tiempo, quizás estas diferencias ya no son tan significativas, sobre todo en los últimos dispositivos del mercado. Por citar un par de ejemplos, parece que el nuevo Apple 6s es más rápido que el Macbook de escritorio lanzado recientemente. Por otra parte, en el mundo Android, los topes de gama ya incorporan hasta 4Gb de RAM.

Desde el punto de vista del uso de los servicios, los que más nos tiene que ocupar y preocupar cuando van a ser consumidos desde un dispositivo móvil es la disponibilidad de red, la minimización del uso del de datos, y algo en el que quizás no solemos pensar: en la latencia de la red, que es el tiempo que se pasa desde que hacemos una petición al servidor y empezamos a recibir los datos.
Precisamente en este artículo se hace un buen repaso de estas especiales características que hay que tener en cuenta en el diseño de APIs para apps móviles, y por extensión, para web móviles.

El peligro de la latencia

En las redes móviles, la latencia suele ser bastante elevevada, sobre todo cuando la comparemos con la que experimentamos en una conexión fija. Además,esta es mucho más evidente cuando los datos que recibimos es pequeña. En estos casos, es posible que el tiempo de latencia sea superior al de descarga propiamente dicho. Por lo tanto, si tenemos muchos servicios que devuelven poca información, el móvil se verá obligado a hacer varias peticiones, que se verán penalizadas en cada una de ellas por esta latencia.

Fusionar respuestas

Según el artículo citado anteriormente, una posible solución a este problema sería el de fusionar varias respuestas en una. De esta manera, típicamente sólo tendríamos que hacer una petición al servidor y en ésta se descargaría un mayor número de datos (por lo que la importancia relativa de la latencia disminuye).
En mi opinión, este podría ser una de las soluciones en algunos casos, pero como todo, hay que tener en cuenta sus contraindicaciones:

  • La descagar más datos estamos utilizando la cuota de datos contratada por el usuario (si se conecta por redes móviles) que es uno de sus bienes más preciados.
  • Al descargarnos toda la información de una vez, es posible que mucha o parte de estos datos no los necesitamos realemente. Es decir, estamos haciendo trabajar al móvil y al servidor (además de gastar el bono de datos) para nada.
  • Hay que tener en cuenta que lo verdaderamente importante es la experiencia o sensación que tiene el usuario al usar la aplicación, no lo que tarda realmente la app en presentar los datos que descarga del servidor. Quiero decir con esto, que existen técnicas para distraer al usuario haciendo la descarga en segundo plano mientras se le muestra otra información de tal manera que no perciba el problema de la latencia.
  • En ciertos escenarios es mejor desde el punto de vista de experiencia de usuario ir haciendo varias peticiones al servidor e ir presentándolas al usuario según vayan llegando que fusionar todas las respuestas en el servidor y devolverlas de golpe. Aunque esta segunda opción pueda ser más eficienge desde el punto de vista del sistema se puede dar la paradoja de que el usuario perciba un peor rendimiento de la aplicación.

Desglosar respuestas

Quizás por las contraindicaciones expuestas anteriormente, en el citado artículo se da una posible solución al problema que va en la dirección opuesta al de fusionar o juntar las respuestas del servidor: extenderlas o desglosarlas.

La idea de esto es no devolver necesariamente todo el bloque de información en respuesta a una petición de información, sino que sea posible que desde el lado del cliente nos puedan indicar exactamente qué información hay que devolver.

Típicamente, en lugar de devolver todos los datos del cliente en respuesta a un get a /client/{idCliente} podamos indicar por ejemplo que sólo queremos la información básica /client/345?fields=basic.

Usando la características de HATEOAS, si estamos con servicios REST, podemos devolver hiperlinks al resto de información. Por ejemplo, en el caso del cliente podríamos devolver un enlace al recurso de la dirección del cliente. Sólo cuando nos interese realmente presentar esta información al usuario la pediremos.

Otra de las técnicas habituales para desglosar las respuestas, y devolver el mínimo conjunto de datos posible a la aplicación cliente, es el uso de la paginación en las consultas.

Compresión de los datos

En los servidores web es bastante habitual utilizar la compresión de las respuesta mediante gZIP. Aunque como todo, puede tener algunas contraindicaciones en determinados escenarios ya que la compresión implica un tiempo de CPU (sobre todo en la parte del dispositivo móvil) que puede acarrear algún retraso en procesar la respuesta y también un uso más intensivo de su batería para alimentar estos ciclos extra del procesador.

No obstante, en general, se considera que la compresión de datos (sobre todo los datos de tipo texto) se considera una buena práctica para reducir el trasiego de datos por la red.

Resumen de recomendaciones

En definitiva, y como resumen, las recomendaciones para la optimización de APIs para ser consumidas en dispositivos móviles serían las siguientes:

  1. Fusionar las respuestas similares
  2. Dar la posibilidad de pedir al servidor sólo los datos que se necesitan proporcionando el mínimo conjunto de datos posible
  3. Comprimir los datos mediante gZIP
  4. Limitar los datos que se descargan sólo a los que se utilizan verdaramente (típicamente aquellos que se van a mostrar al usuario)
Anuncios