{"id":1666,"date":"2015-12-16T01:06:17","date_gmt":"2015-12-16T01:06:16","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=1666"},"modified":"2023-06-27T05:50:04","modified_gmt":"2023-06-27T12:50:04","slug":"json-anywhere-revolutionizes-mobile-developer-productivity","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/es\/json-anywhere-revolutionizes-mobile-developer-productivity\/","title":{"rendered":"JSON Anywhere revoluciona la productividad de los desarrolladores m\u00f3viles"},"content":{"rendered":"

La tecnolog\u00eda m\u00f3vil que Couchbase anuncia hoy marca el inicio de una transici\u00f3n para los desarrolladores de aplicaciones m\u00f3viles: alejarse de la pila LAMP centrada en la web y acercarse a una pila m\u00f3vil integrada. Con JSON Anywhere, los desarrolladores pueden concentrarse en crear valor para los usuarios, en lugar de escribir montones de c\u00f3digo dedicado a enviar datos entre los dispositivos y la nube. Nuestros ingenieros se han centrado en la experiencia del desarrollador desde el principio de este proyecto, por lo que hay un mont\u00f3n de detalles que deber\u00edan hacerte feliz, desde compatibilidad con el inicio de sesi\u00f3n social<\/a> a vinculaci\u00f3n de datos en vivo para UITableView de iOS<\/a>pero los dos aspectos que m\u00e1s repercutir\u00e1n en la productividad son la flexibilidad de los esquemas JSON y la perfecta sincronizaci\u00f3n de JSON con otros dispositivos y la base de datos backend.<\/p>\n

Como a muchos desarrolladores, me atrajo primero NoSQL por la flexibilidad de JSON como formato de base de datos. Como se pueden a\u00f1adir nuevos campos a los documentos en cualquier momento, los desarrolladores de aplicaciones nunca tienen que esperar a una migraci\u00f3n de la base de datos. Ha habido abundancia dijo<\/a> acerca de uso de JSON con pr\u00e1cticas de desarrollo \u00e1gil<\/a>as\u00ed que no lo repetir\u00e9 aqu\u00ed. Lo importante de Couchbase Lite es que lleva la potencia y flexibilidad de JSON al m\u00f3vil.<\/p>\n

JSON es especialmente valioso para las aplicaciones m\u00f3viles, porque a menudo tienes que tratar con una mezcla de usuarios, algunos ejecutando versiones antiguas de tu software y otros con la \u00faltima actualizaci\u00f3n. Con JSON, la mayor\u00eda del c\u00f3digo ignorar\u00e1 los campos \"extra\" que no utilice. A medida que los usuarios se actualizan a una versi\u00f3n m\u00e1s reciente de su aplicaci\u00f3n, pueden seguir interactuando con los que todav\u00eda est\u00e1n ejecutando una versi\u00f3n anterior. Los campos utilizados por la nueva versi\u00f3n de la aplicaci\u00f3n ser\u00e1n simplemente ignorados por la versi\u00f3n antigua. Esto permite a los usuarios actualizar a su propio ritmo, en lugar de obligarles a dejar lo que est\u00e1n haciendo y actualizar de inmediato. Aunque es posible realizar actualizaciones continuas con una arquitectura tradicional, esto requerir\u00eda trabajo adicional por parte del equipo de desarrollo del servidor, en lugar de ser una consecuencia natural del uso de una base de datos flexible.<\/p>\n

Los desarrolladores de aplicaciones est\u00e1n siempre a la b\u00fasqueda de herramientas y t\u00e9cnicas que puedan aumentar su productividad o permitirles construir una mejor experiencia de usuario con menos c\u00f3digo. Ya hemos visto estas transiciones en la arquitectura web: de los scripts CGI ad hoc a los servidores de aplicaciones gestionados, y de Java a lenguajes como Ruby o JavaScript que se centran en la felicidad del desarrollador. Una transici\u00f3n de este tipo s\u00f3lo tendr\u00e1 \u00e9xito si conduce a grandes saltos en la productividad de los desarrolladores, que es exactamente lo que prometen estas nuevas plataformas. Cuando se anunci\u00f3 por primera vez Ruby on Rails, se produjo una avalancha de desarrolladores con la esperanza de sacar partido de un oportunidad de arbitraje de productividad<\/a> lo que les permite cobrar menos a los clientes por el mismo trabajo y ganar m\u00e1s dinero haci\u00e9ndolo que un equipo Java comparable.<\/p>\n

La sincronizaci\u00f3n sin fisuras ofrece a\u00fan m\u00e1s ganancias de productividad que el paso de relacional a JSON. Con una sincronizaci\u00f3n tan sencilla que es m\u00e1s f\u00e1cil sincronizar que crear un backend de servicios web tradicional para tu aplicaci\u00f3n m\u00f3vil, veremos muchas m\u00e1s aplicaciones que dar\u00e1n a sus usuarios acceso a sus datos a trav\u00e9s de dispositivos y sistemas operativos. Sync tiene fama de ser muy dif\u00edcil de implementar. No hay que buscar mucho para encontrar historias de empresas que dedicaron importantes recursos a crear la sincronizaci\u00f3n, y incluso despu\u00e9s de a\u00f1os de desarrollo, siguen encontrando fallos y casos extremos<\/a>. No ser\u00eda justo comparar una aplicaci\u00f3n que usa Couchbase Lite para sincronizarse con Couchbase Server con Couchbase Sync Gateway, con una aplicaci\u00f3n que construye su propia instalaci\u00f3n de sincronizaci\u00f3n personalizada. Cualquiera que construya la sincronizaci\u00f3n desde cero se est\u00e1 embarcando en un proceso de varios a\u00f1os, y llegar a \"hola mundo\" con Couchbase s\u00f3lo deber\u00eda llevar unos minutos.<\/p>\n

Aunque la sincronizaci\u00f3n se est\u00e1 convirtiendo r\u00e1pidamente en la nueva normalidad, la mayor\u00eda de las aplicaciones m\u00f3viles colaborativas de hoy en d\u00eda dependen de estar conectadas a un servidor en la nube. Para ser justos, compararemos el backend de una de nuestras aplicaciones de ejemplo con la misma aplicaci\u00f3n utilizando un backend Ruby on Rails. Nuestro objetivo es construir una tecnolog\u00eda que suponga un salto en productividad para los desarrolladores, como lo fue Rails en comparaci\u00f3n con sus predecesores. Veamos las diferencias entre una aplicaci\u00f3n JSON Anywhere y una aplicaci\u00f3n m\u00f3vil tradicional con servicios web.<\/p>\n

El c\u00f3digo fuente del backend de nuestro ejemplo de aplicaci\u00f3n Todo Lite se encuentra en una \u00fanica funci\u00f3n JavaScript de 33 l\u00edneas<\/a>. Su principal responsabilidad es garantizar que a cada lista de tareas s\u00f3lo puedan acceder las personas que el propietario de la lista haya designado como miembros de la misma. Tambi\u00e9n es responsable de asegurarse de que cada tarea se enruta a los dispositivos que tienen acceso a la lista asociada. Tambi\u00e9n hay algunas l\u00edneas de c\u00f3digo dedicadas a distribuir perfiles de usuario para potenciar la interfaz de usuario compartida. Para profundizar en una aplicaci\u00f3n similar, puedes seguir un recorrido por el modelo de datos de nuestra aplicaci\u00f3n de chat de ejemplo.<\/a><\/p>\n

En una aplicaci\u00f3n Rails tradicional de tres niveles, tendr\u00edamos modelos correspondientes a usuarios, listas y tareas. Puede que tambi\u00e9n tengas un modelo de \"membres\u00eda\" que capture las restricciones de acceso. Pero lo que m\u00e1s caracteriza a una aplicaci\u00f3n de estilo Rails es que cada vez que un usuario crea una tarea, activa una casilla de verificaci\u00f3n o a\u00f1ade un nuevo miembro a una lista de tareas, la aplicaci\u00f3n m\u00f3vil realiza una petici\u00f3n HTTP al servidor. El servidor cargar\u00e1 entonces los objetos modelo apropiados desde la base de datos, validar\u00e1 los cambios y los guardar\u00e1 de nuevo en la base de datos. A continuaci\u00f3n, tendr\u00e1 que notificar a los dem\u00e1s dispositivos m\u00f3viles que su representaci\u00f3n del objeto no est\u00e1 actualizada para que puedan actualizarla. (Ten en cuenta que ni siquiera hemos empezado a tener en cuenta el caso de que los dispositivos m\u00f3viles modifiquen los datos mientras est\u00e1n desconectados...).<\/p>\n

Hagamos un c\u00e1lculo aproximado de la cantidad de c\u00f3digo que tendr\u00edamos que escribir para crear una aplicaci\u00f3n Rails de este tipo. Voy a omitir el c\u00f3digo de inicio de sesi\u00f3n\/usuario, ya que normalmente no se escribe como c\u00f3digo personalizado para la aplicaci\u00f3n.<\/p>\n