nexblu va a ser una aplicación de Internet que ofrecerá a sus usuarios una colección de funciones (crecientes y a su gusto, como comentamos el primer día), accesibles tras su autorización mediante usuario y contraseña: facturación, contabilidad, estadísticas, etc.
Pero nosotros, como organización que pone en marcha y distribuye la aplicación nexblu, necesitamos un sistema propio para gestionar a sus usuarios. Por lógica de diseño, no podemos incorporar esta segunda aplicación dentro de nexblu, aunque tienen que poder comunicarse entre si en determinados momentos. Por ejemplo:
- Cuando un usuario intente entrar en nexblu, alguien tiene que saber que puede entrar o no, qué funciones debe encontrar disponibles o en qué idioma va a trabajar.
- Queremos también hacer un seguimiento estadístico de la actividad de cada usuario, entre otras cosas para poder saber qué funciones son más utilizadas, cuáles dan más molestias, etc. En caso de poner en marcha un sistema de pago por uso, está claro que esta información de seguimiento será imprescindible.
Todas estas funciones, independientes de nexblu pero que actuarán, dentro del sistema global, como metafunciones sobre nexblu, las hemos agrupado en una segunda aplicación que hemos bautizado como… greenblade.
La comunicación entre greenblade, que será un sistema completamente interno, y nexblu la haremos mediante APIs. Hoy en día crear APIs es algo muy común, y su importancia ha ido creciendo conforme lo hacían las aplicaciones distribuidas en Internet. De hecho, una de las ventajas que ofrece Ruby on Rails sobre otros lenguajes y entornos de programación es la facilidad para el desarrollo de APIs.
Es el ejemplo también de Twitter o de Facebook, aunque en nuestra opinión es preferible el de Twitter porque es mucho menos intrusivo: al fin y al cabo todo lo que da Facebook es una excusa para fagocitarnos a su interior, cosa que Twitter, al menos hoy por hoy, no intenta.
Nosotros hemos preferido utilizar APIs en lugar de, por ejemplo, Servicios web porque éstos últimos son demasiado complicados para lo que acaban aportando. En realidad, las APIs son servicios web pero con menos “parafernalia técnica” (recordemos que montar un servicio web requiere tres protocolos distintos: SOAP, WSDL y UDDI, ¡ahí es nada!), lo que les hace la solución perfecta cuando no se trata de establecer comunicaciones complejas.
Cualquiera que haya usado los estupendos Servicios Web de Amazon, o haya tratado con aplicaciones REST-ful, sabe lo fácil que resulta desarrollarlas y ponerlas en marcha en comparación con los servicios web convencionales.
Ahora mismo estamos en pleno desarrollo de las primeras APIs de comunicación entre greenblade y nexblu, imprescindibles para que el módulo de login funcione como es debido y cargue todo aquello que un usuario ha solicitado. Como decíamos más arriba, funciones disponibles, lenguaje, etc.
Un abrazo desde Nex-Software.
