 Buenas, buenas tardes. Agradeceros a todos los que habéis venido. Como bien ha presentado él, yo vengo a hablar de darle un uso distinto al que se suele dar a WordPress, que es utilizarlo como la parte de servidor de las aplicaciones móviles. El hardware del que hablaban, la integración con el hardware, sería nuestro dispositivo móvil. La presentación es prácticamente lo que ha dicho él, como más que me podía encontrar en Twitter, como MFere y poco más. La presentación la vea estructura en cuatro secciones. Una sería lo que el motivo que hizo, que yo utilizara WordPress como vaquen de aplicaciones, vamos a ver cómo hacerlo, que básicamente es utilizando la resapi que nos aporta. Mobilebacking as a service es como se llama a las herramientas que no hacen de servidor. Entonces, vamos a ver con respecto a otras herramientas existentes en el mercado, qué aspectos de los que debe cumplir ese tipo de herramientas, cumple WordPress y cuáles no. Y finalmente vamos a ver cómo lo tengo aplicado en una aplicación que está puesta ahora mismo en producción y vamos a ver un ejemplo de cómo se usa. El motivo es que empecé a implementar aplicaciones móviles. Siempre hay una parte de servidor donde se aloja el contenido que muestran los clientes móviles y donde se guarda la información. En 2011 empecé con lo que era Google App Engine. Ahora se llama Google Cloud Platform, luego pasamos a Microsoft Azure. El año pasado estuve trabajando en una aplicación que utilizaba Amazon Web Services. Ahora mismo estoy trabajando en otra que es Firebase. Hay varias soluciones y todas ellas tienen que cumplir una serie de requisitos que son las necesidades que tienen las aplicaciones móviles. Cuando yo pasé a ser freelance en 2015, en las propuestas que les daba a los clientes, siempre metía la parte de backend, les metía en el presupuesto algunas de estas soluciones. Dependiendo de lo que necesitaba la aplicación, normalmente incrementaba el coste de la solución de las aplicaciones. Pero claro, es algo que se necesita. Las aplicaciones siempre van a necesitar, o en la gran mayoría de los casos, una parte de servidor. Entonces, un cliente que organiza una feria de empleo en la que hay candidatos, hay empresas, hay ofertas de trabajo, me propuso que, en vez de contratar una de estas otras soluciones que hemos visto en la diapositiva anterior, ¿por qué no utilizábamos su web? Que él tenía un WordPress donde se hacían los registros tanto de los candidatos como de las empresas que ya tenían una base de datos, ¿por qué no utilizábamos eso? Entonces, yo investigo un poco y digo, técnicamente se puede hacer porque ahí tenemos la base de datos, y ya se registran porque utilizan el mismo contenido. Entonces, lo que hicimos es que el WordPress que él tenía, que mostraba la página web, que era lo que utilizaba, pues pasamos a utilizarlo también desde los clientes móviles. Pero para ello, yo lo primero que hice fue un poco así, a pelo, bueno, pues yo qué hice, metí en el funcio un punto PHP del tema que tenía en ese momento, añadí la funcionalidad y ya con eso podía acceder al contenido. Pero eso no es lo ideal porque una vez que actualizamos el tema, perdimos la funcionalidad. Luego pasamos a utilizar child themes, que es mejor porque si actualizas el tema, no pierde la funcionalidad porque la tienes en el tema mismo, que se añade a la funcionalidad del tema, pero si cambias el tema, sí que la pierde. Entonces, luego pasamos a la funcionalidad que utilizábamos desde los dispositivos móviles, las pasamos a un plugin, que es donde creo que debe estar. Pero el gran, el punto de inflesión vino cuando conocí, WordPress lo tiene, creo que desde 2014, la res API, y creo que lo metió en el core en 2017. Yo no sé en qué momento lo descubrí, pero para mí fue un gran descubrimiento. ¿Quiénes de vosotros sabéis que WordPress tiene una API res? Mucho, la mayoría. ¿Quiénes de vosotros la utilizan por defecto? ¿Qué queda WordPress? ¿Qué devuelve los posts, los usuarios, los comentarios, lo típico de... Y quiénes de vosotros implementan una API personalizada para sus propias soluciones. Vale, pues de eso es lo que yo voy a hablar. Voy a hablar de eso porque en la mayoría de los casos en las que pretende mostrar en las aplicaciones el mismo contenido que muestra la web, simplemente los posts y la galería y demás, normalmente nos suele compensar hacer una aplicación, o sea, una página web responsive con diseño adaptativo y sé que se puede haber de hacer los dispositivos móviles. El caso del que yo voy a hablar es hacer llamadas propias para almacenar y obtener contenido customizado y propio de tu aplicación. Eso, la API que nos aporta WordPress es el mismo esquema que teníamos antes. Tenemos un WordPress central que no soporta tanto para la web como para los clientes móviles, pero ahora se nos añade un contrato entre el cliente móvil y el WordPress. Ese contrato es una regla en la que las aplicaciones saben cómo van a obtener el contenido del WordPress y el WordPress va a servir ese contenido solo si se cumplen esas reglas. Eso, bien habilitado por defecto en WP Jason de nuestro WordPress, que es algo así de feo, que si lo ponemos lo formateamos, un poquito más bonito. Y ahí es donde nosotros vamos a añadir nuestras reglas. Esas son las reglas que trae por defecto WordPress y nosotros vamos a añadir las nuestras para acceder al contenido de la base de datos. Entonces, lo que vamos a hacer es añadir un in-space propio. En este caso sería WCMAD en su versión V1. Entonces, en nuestro WP Jason barra WCMAD barra V1 vamos a añadir llamadas que vamos a poder hacer a nuestro sistema. En este caso, la llamada sería fecha. Y esa llamada fecha, que se añade con el register root, les vamos a poder configurar para que sea un método de tipo Guest, de tipo POS para que tenga una serie de parámetros y que finalmente va a llamar una función, perdón, que sería que es fecha que pide un parámetro. En este caso es un ejemplo. Le pasamos como parámetro el año. En este caso es 2019, la función que fecha devuelve que para 2019 la fecha que tiene que dar es 6 de abril hoy. Entonces, en nuestro in-space es WCMAD en su versión 1 y la función, bueno, eso es lo que he dicho, y la función es que fecha. Eso lo que hacemos es que eso no viene en WP Jason por defecto. Entonces, con la llamada hook resolver añadimos para que entre las opciones que tenemos en WP Jason, esté ahora también WCMAD version 1, barra fecha, que nos va a devolver la fecha. Pero solo podemos acceder a la fecha que está almacenada en nuestra base de datos si llegamos por ese pad pidiendo en este caso de tipo Guest, un método de tipo Guest, y con el parámetro pasándole del año. Si no accedemos así, no accedemos a la fecha. Pero aunque ahora accedemos mediante unas reglas, pero claro, esas reglas son públicas, están en WP Jason, aparecen en barra WP Jason, aparecen las reglas de obtener el contenido. Entonces, tenemos que añadirle una capa de seguridad para que ese contenido se sirva en función de quién lo solicite. Las capas de las opciones de seguridad que tenemos con WP sería la que él utiliza por defecto, que es una cookie, que almacena si se ha hecho login, y en la cookie se pasa al usuario de contraseña y se sabe si el usuario tiene acceso al contenido. Para las aplicaciones se puede hacer también que se crea una contraseña, un application password, y ese es el que utilizan las aplicaciones para hacerla llamar. Es mejor que no tener nada, pero estas dos opciones son seguridad básica, que se añade el usuario de contraseña en la cabecera. Entonces, en todas las llamadas estamos pasando el usuario de contraseña que se podría interceptar. Es más recomendable utilizar las opciones que lo que pasan en la llamada es un token. Eso se puede hacer tanto con OAuth como con Jason Westoken. Ambos son instalar un plugin y lo que hacen es que solo piden el usuario de contraseña la primera vez. La primera vez no cuando obtienen el token. El token es la llave con la que van a tener acceso al contenido de las llamadas que hagan a la API. Y en ese punto donde dan un usuario de contraseña, pero a partir de ahí solo se intercambia el token. Y ese token se puede añadir una caducidad y que no sea válido. Entonces, en el caso de la aplicación concreta, vamos a ver si utiliza Jason Westoken y esas dos opciones son más seguras que con autenticación básica. Pues estas son las opciones de seguridad que podemos utilizar en WordPress. ¿Cómo lo hacemos en nuestra API, en la versión que hemos hecho de nuestra API? La clave está en la llamada Permisión Callback. Es un parámetro más que pueden tener nuestros métodos. El método, en este caso, lo llamo privado. Es un método privado que el contenido que va a devolver solo lo va a devolver quien llegue con permiso para acceder a ese contenido. Entonces, añadiendo la Permisión Callback, se llama una función que es Chequear Permiso y esa función Chequear Permiso con prueba. Pues tú vienes con el token de autenticación, te dejo pasar. ¿Tú eres un usuario de este tipo de rol? Te doy el contenido. Eres de este otro, no te lo doy. Cualquier cosa que queramos comprobar, lo comprobamos en esa función. Y si no se pasa esa función, no se llega nunca al contenido. Y si quien ha hecho la llamada tiene los privilegios para hacer el contenido, pues ya, entonces, cuando se llama la función que es datos privado y devuelve lo que se haya solicitado. Perdón. Entonces, con eso ya tendríamos una solución como la que ofrece Amazon Web Services o Microsoft Azure o cualquiera de esas porque ya nos está haciendo la parte de servidor, la parte de backend de nuestras aplicaciones. Según la definición de Wikipedia, bueno, al final de la presentación he añadido tanto lo que hemos hablado antes de la parte de seguridad, de autenticación, como esta definición está en los enlaces. La definición dice que si quiere ser un mobileback en esa service, debes cumplir una serie de requisitos. Entonces, entre esos requisitos están. Tener un servicio de autenticación para los usuarios. Lo tiene, tiene un servicio de usuarios y roles. Tener una API de eso de lo que estamos hablando, de la API red de WordPress. Tener base de datos, gustará más o gustará menos una base de datos relacionadas, pero todo WordPress conlleva una base de datos MySQL. Almacenamiento, por defecto en un WP content upload, pero podríamos almacenarlo en cualquier otro, en el hosting y tener almacenar un fichero. Automatización de tareas. WP Chrome nos permite, o el hosting, con las tareas de tipo Chrome. Podemos añadir las tareas periódicas que necesitemos. Notificaciones push. Esta ya no está tan claro que lo cumpla. Las notificaciones push son imprescindibles para las notificaciones móviles. Todas se envían a través de los servidores de Google y de Apple, y técnicamente WordPress, por defecto, no da soporte para ello. Pero esas notificaciones se pueden enviar con un script, porque al final son las llamadas a los servidores que hemos dicho de Google y de Apple. Entonces, también al final de la presentación ponga un enlace donde hay un ejemplo de un script para cambiarla de SPHP, y PHP es lo que tenemos en WordPress. El dashboard, similar. Es verdad que WordPress tiene un dashboard, un panel de control, donde controlamos los usuarios y demás, pero no viene por defecto a la implementación a lo que es la funcionalidad que nosotros añadimos a la API. Por defecto, no la gestionamos de ser paneles de control, y igual que hemos añadido las funcionalidades a la API, se las podemos añadir al panel de control. Sdk, esto lo que dice es que si tú, por ejemplo, utilizas Firebase para hacer tus aplicaciones de Android, pues te da una librería, una librería para Android o un framework para iOS, que lo instalas por defecto y te facilita la labor de utilizar las funciones de Firebase. Eso WordPress no lo tiene. Nosotros lo podríamos implementar una librería para los clientes móviles que hacedas fácil a nuestras llamadas de la API. Pues no, a lo mejor no hace falta, porque simplemente haces las llamadas a la API REST. Igual para las analíticas o para los crases, WordPress, por defecto, no da un gestor para medir la analítica del uso que hace el usuario en nuestros clientes móviles o de los fallos que estos dan. Pero, aunque los sistemas Cloud que hemos visto antes sí que casi todos ofrecen, pero yo, por ejemplo, en la aplicación que comentaba que año pasado trabajé, que era con Amazon Web Services, al final analítico utilizábamos Firebase. Estábamos utilizando la gestión de analíticas de otro de los servidores. Entonces, si desde WordPress tenemos que utilizar Firebase, porque las analíticas de Google son mejores o incluso propio Firebase utiliza Grad Litix para el tema de los crases, que Grad Litix es ahora suyo porque lo ha comprado Google y lo ha metido dentro de Firebase, pero hace unos años era de Twitter. Entonces, no lo tenemos, pero tampoco es tan problemático utilizar el de otro servicio. Y, finalmente, vamos a ver un ejemplo de aplicación que almacena el contenido en un WordPress y que se accede a él mediante una API. La aplicación se llama Twilow y es un lector de hilos de Twitter. Se empezó con los blogs. Los blogs, se decía, que era demasiado largo. Se pasó al microblogging, que eran pildoritas de una límite de caracteres. Funcionó muy bien, Twitter tuvo mucho éxito y ahora resulta que los usuarios empezamos a utilizarlos enlazando los tweets unos con otros y generamos hilos que, si los ves en formato de artículo, se parece mucho un blog. Entonces, como que volvemos al formato de artículo. Entonces, la aplicación, lo que hace, ahora mismo está en el Apple Store, lo que hace es que si tú ves un tweet, ya sea en el navegador del dispositivo o en la aplicación de Twitter, lo que puedes hacer es compartirla y verla dentro de la aplicación en formato de artículo. Entonces, aparece una extensión de la aplicación que te permite, cuando das al botón de compartir, que te aparezca la aplicación ver hilo, es una extensión de tu hilo. Es para que se vea desde otras aplicaciones. Y en el punto en el que das a eso, analiza el tweet. ¿Analiza el tweet qué es lo que hace? Pues consulta si ese tweet pertenece a un hilo o no y eso Twitter te lo va. O sea, Twitter tiene una API que tú le preguntas por un tweet y te dice el autor, las fechas, te lo dice todo, tiene si respuesta de otro, en el momento en el que un tweet es respuesta de otro, ya es un hilo. Un hilo con dos tuyas lo tiene. Entonces, eso se lo podríamos preguntar, pero Twitter no te permite que todos tus clientes móviles, todas tus aplicaciones, todos los usuarios de tu aplicación le preguntes porque Twitter te permite consultar su API pero con un número limitado de consulta. Entonces, lo que hacemos es que esas consultas las hacemos desde nuestro WordPress y los clientes móviles nos preguntan a nuestro WordPress. Entonces, en este punto el cliente móvil le ha preguntado al WordPress, oye, este tweet pertenece a un hilo y aquí lo hacemos mediante la API. Tenemos un in-space propio que es tu hilo barraba en su versión 1, en la llamada hilo. Entonces, sería nuestro dominio barra, vpjson barra tu hilo, barra versión 1 barra hilo. Ahí le podemos consultar, si pasándole como parámetro el id del tweet, le decimos si es un hilo o no. Entonces, la llamada de seguridad, el permiso en un callback lo que hace, quien me lo está preguntando, no son mis aplicaciones móviles. Con prueba, si es la llamada, está hecha de hacer nuestra aplicación móvil, que es lo que hemos hablado antes, la autenticación, si tiene el token, con JSON, web token, y en ese caso le dice si es un hilo o no. Si sabe, si es alguien que, si ya se ha preguntado por ese hilo nuestro WordPress ya te ha armacenado. Sí, pues es un hilo o no es un hilo o lo que sea. Y si no lo sabe, pues en ese punto es cuando WordPress utilizando la API de Twitter le pregunta a Twitter, oye, ¿esto pertenece a un hilo? En este caso concreto, pues que no devolvería, pues sí. Es un hilo bastante famoso que tiene 385 respuestas, que lo escribió un tal manual virtual el 21 de agosto de 2017 y devuelve contenido. Ese contenido tiene imágenes, tiene vídeos, tiene enlaces, tiene y se puede leer en forma artículo. Y eso es lo que hace la aplicación y lo hace armacenando el contenido y la información de los hilos en un WordPress. Como decía, estos son los enlaces a las cosas de las que ha hablado. La aplicación ahora mismo solo está para iOS, en Apple, pero es fácil que esté para Android en los siguientes meses, porque con los colegas de Architesco estamos trabajando para hacer una versión para Android y nada. Las preguntas que queráis hacer, o podéis encontrar en Twitter, en el correo. Venid, ¿cómo queráis? Un momento de preguntas. Veo más luz, gente. Hola, me gusta mucho tu charla. Nosotros también habíamos trabajado con esto y la verdad es que por camino muy parecido. Al final, mola mucho ver que llegamos a los mismos sitios y mola. La pregunta era el tema de notificaciones, que es crítico en estas cosas. Nosotros usamos One Signal para esto, enviando desde PHP, desde WordPress. ¿Recomienda algún servicio? Porque facilita, en lugar de tener que enviamos... No, sí, hay muchos. Y yo utilicé también una city y hay muchos servicios de tercero que te gestionan el envío de notificaciones. Lo que quiero decir es lo más cercano y lo más nativo a propio WordPress. Y sería eso, un script en PHP puro que lo puedes incluir en tu plugin y hace esa funcionalidad. Como servicio, pues hay muchos. No me acuerdo del nombre, el año pasado, la aplicación que trabajaba con Amazon, no me acuerdo del nombre, pero funcionaba muy bien. Pus-bus, pus-bus, como se llama. Bueno, gracias. Pero hay muchos servicios de eso. Hola, el caso que acabo de decir es que nos encontramos muchísimo con desarrolladores de front, de gente que trabaja con bube, con ángula y que cuando les contamos que WordPress tiene una resape nativa, se quedan sorprendidísimos. Sí, sí, no, sí. Bueno, más sorprendido que se haya levantado tanto la mano porque sí que la mayoría de la gente sabía que existe, pero luego no sois tanto lo que la utilizáis. Y creo que es súper potente, ¿verdad? Pero nosotros estamos aquí, la mayoría de los que estamos aquí pero lo que, como desarrollar de web, lo que no entiendo cómo podemos hacer para llegar a más gente y sobre todo lo que quería saber es qué es lo que has encontrado tú como desarrollador de front o de móvil a la hora de... ¿Por qué los desarrolladores de mobile o de aplicación nativa no son conscientes de que existe esa API de WordPress? Creo que porque llegaron antes los servicios claro que hemos hablado antes. O sea, ya por defecto tú dices, por si te hemos montado una aplicación, está claro que lo hago con Firebase o lo hago cual sea, pero eso es lo primero de selección y luego ya lo monto sobre eso. Y WordPress, pues, si eso es para blog, lo que hemos hablado, eso no es para aplicaciones móviles, pero se puede, o sea, se puede y no es necesario. También es verdad que también depende del volumen de las aplicaciones y de la escalabilidad, porque si va a tener muchísimo usuario, si va... Amazon son servicios que tienen todo, o sea, cualquier cosa que puedas necesitar, cualquier otro servicio de landas, de lo que sea, son paquetes que tienen más servicios. Pero si es para nutrir a las aplicaciones, WordPress cumple perfectamente. Hola. Aquí. Una pregunta general, por favor, yo no tengo perfil de desarrollador, pero es cierto que desde hace mucho tiempo se escucha que una de las justificaciones o posibles usos de la implantación de REST API en WordPress era precisamente el acceso para aplicaciones móviles a un servidor WordPress. Hace tiempo que lo he oído escuchando. Entonces, mi pregunta es, me sorprendo que no se use tanto, mi pregunta es, ¿cómo de extendido está el uso, el acceso como al backend de WordPress de las aplicaciones móviles? Y, segundo, ¿existen en el roadmap de WordPress algunas planes para implantar todas esas carencias que has comentado que definen a las mobile backend services? No creo. No creo que estén en el roadmap. No sé si deberían estar, porque al final WordPress... Y sobre todo porque las que no cumple es necesario, es lo que he dicho. Si al final el tema de analíticas en la aplicación, o sea, Amazon tiene que tener su herramienta, por decir, no es que lo cubro todo, pero qué porcentaje utilizan las analíticas de Amazon y qué porcentaje se utilizan las analíticas de Google. Entonces, que en algunos puntos tengas que utilizarlas de tercero. Si funcionan mejor, o sea, la integración no es que no puedas tener eso, o sea, siempre puedes compaginarlo con otra solución. Y el tema de llegar a esto, pues bueno, en mi caso fue por un cliente que me decía, oye, ¿por qué no aprovechamos lo que ya tenemos? A lo mejor quien sea mobile first, o sea, piense primero en la aplicación y haga el desarrollo para... de cara a la aplicación, poniendo a todas las cosas en una balanza, diga, pues, me sale mejor utilizar cualquier otra solución en la nube. Pero, ¿quién haya empezado por la web y el WordPress lo tenga porque iba a hacer una web con WordPress? Yo creo que para hacer una aplicación móvil, en lugar de implementar otra solución en la nube, creo que es más fácil ampliar la funcionalidad del WordPress que ya tiene. Jaime, estas en las happiness, ¿verdad? Sí, bueno, y por ahí me seguiré donde me quieran abordar. Última pregunta, quizá alguien se anima. Pues si no, un fuerte aplauso para Jaime y lo encontramos en la happiness.