Home » Swift » Así funciona Swift en servidor (Swift Server Side) con Kitura

Así funciona Swift en servidor (Swift Server Side) con Kitura

Hoy día, las apps no son solo un elemento único y autónomo. Son más bien un ecosistema, donde la app es una parte del mismo y luego los servicios asociados residen en la nube: mensajería, servicios, analíticas, funciones sociales, dar a nuestros clientes un servicio con datos persistencia también en una interfaz web… Pero el primer problema con que nos topamos cuando hacemos una app enfocada a servicios que necesita un despliegue en servidor es el lenguaje. Nuestra app estará en Swift pero la parte de servidor necesitará de otro equipo para ser desarrollada en Node.js, ASP.NET, Java (JSP) o cualquier otro lenguaje similar.

Una de las grandes ventajas que Swift se haya convertido en código abierto y tenga soporte para Linux, es que ahora este también es una opción como lenguaje para la parte server-side (de servidor) de nuestra app, por lo que podremos gestionar cualquier tipo de proceso en el mismo lenguaje de programación con que realizamos la app. Sin duda, una gran ventaja. Ventaja que se amplia a cosas tan prácticas como compartir código o librerías entre la app y la parte servidor y no tener que volver a desarrollar una misma funcionalidad en diferentes lenguajes.

La forma en que se ha conseguido que Swift funcione en servidor bajo infraestructura Linux, es gracias a la división en la que la partes de las librerías del núcleo, como Foundation o LibDispatch, se han creado como parte del lenguaje en sistemas que no usen el núcleo Darwin y que nos permitirán usar Swift en cualquier servidor desplegado en sistema como Linux e incluso Windows, FreeBSD o una pequeña Raspberry Pi.

Lo primero que hemos de entender es que Swift en el lado servidor solo usa procesos, no tiene interfaz. Esto es algo obvio a primer nivel, pero que mucha gente no conoce. Una cosa son las librerías que construyen apps como UIKit para iOS o AppKit para Mac y otra es el lenguaje, que se ha disgregado. Lo segundo (una gran ventaja) es que la versión de Swift va unida al contenedor que pongamos en el servidor, por lo que no tendremos el problema de versiones nuevas porque el lenguaje va incluido en el mismo despliegue.

IBM @ Swift

El acuerdo que firmaron IBM y Apple hace ya dos años, supuso el inicio de unas sinergias muy beneficiosas para ambos. A día de hoy existen más de 100 apps empresariales que pertenecen al catálogo IBM MobileFirst para iOS (apps en exclusiva). Y además, ya desde el primer momento, IBM dijo que apostaban por Swift como lenguaje de desarrollo (cuando este estaba recién llegado al público).

Ahora, IBM es uno de los socios estratégicos en el desarrollo del proyecto de Swift Open Source (como ya contamos aquí), aportando al desarrollo de partes tan importantes como el núcleo o la propia fundación. Además ha creado dos herramientas claves para el mismo: Swift Sandbox (el entorno de desarrollo de Swift en web) y Swift Package Catalog.

Swift Sandbox se ha convertido en la puerta de entrada a Swift de infinidad de personas, donde según los datos de IBM no solo se han ejecutado millones de programas. Además, el 56% de esas ejecuciones son en sistemas que no son de Apple, lo que da a entender el enorme interés que despierta el lenguaje. Un entorno, donde además se permite elegir qué versión de Swift queremos usar para nuestros programas: la 3.0 en varias versiones o la 2.2.

Swift Package Catalog es, por otro lado, un catálogo de paquetes que pueden instalarse en Swift y ampliar sus funciones, con más de 1.500 paquetes desarrollados, donde destaca especialmente los servidores sobre los que podemos hacer los despliegues server-side de los que vamos a hablar. El más importante: Kiruta, un framework web de despliegue de código Swift para servidor.

Kitura, es la joya de la corona. Un framework web, de código abierto, que incluye toda la funcionalidad de Swift y sus librerías de núcleo, preparado para ejecutarse tanto en sistemas Darwin como Linux. Un potente framework que además es el que la propia IBM usa para todas las aplicaciones server-side en Swift.

Todas estas herramientas tienen su punto de encuentro en Bluemix, la infraestructura en cloud de IBM, que ahora soporta Kitura como parte esencial de su motor y que permite un despliegue directo de nuestras aplicaciones para servidor gracias a una nueva herramienta para OS X: IBM Cloud Tools for Swift. Con esta herramienta, podemos conectar la parte cliente de nuestras apps, generada en Xcode, con la parte en servidor desplegada contra la infraestructura de Bluemix.

IBM Cloud Tools for Swift

La gran ventaja que aporta es que podemos usar esta herramienta para probar el código que irá desplegado en el servidor directamente en Xcode y nos permitirá depurar el código en local. Cambiando muy pocos parámetros en un fichero plist, podemos abrir en el propio Xcode el código del servidor, marcar puntos de ruptura para depuración, preguntar al depurador por valores y modificar cualquier problema directamente mientras nuestra app está conectada a la instancia en local del servidor conectado al propio Xcode 8. Una vez arreglado el problema y probado todo el código en local, solo tenemos que pulsar un botón en esta nueva herramienta y re-desplegarlo contra el servidor.

Ejemplo de despliegue

El despliegue de una app y la forma en que conectamos es más simple de lo que pueda parecer en un principio. Lo esencial en que tenemos que pensar es en servicios web. Un servicio web, para el que no lo sepa, es un listener (un proceso que escucha en un servidor) esperando que se haga una llamada al mismo. Igual que nosotros, al poner el nombre de una página en un navegador, vamos a ella y nos devuelve una respuesta, los servicios web son procesos que están desplegados en un servidor (como si fueran páginas web, pero sin contenido) donde reciben una petición en un formato y devuelven una respuesta: son procesos remotos que se ejecutan a través de la web.

Si tenemos un servidor Linux con Swift instalado (hicimos una guía sobre cómo hacerlo en este enlace, solo tenemos que ejecutar la instrucción swift build --init en una carpeta vacía y se nos crearán los elementos esenciales para crear un paquete en Swift.

Al igual que cuando queremos hacer un programa en Xcode creamos un proyecto, en Swift para Linux creamos un paquete, que contiene un estructura de archivos donde la parte principal es el fichero Package.swift del raíz (donde está la estructura del mismo) y luego la carpeta Sources donde reside el fichero principal: main.swift.

Hecho esto, solo tenemos que ejecutar swift build para construir el paquete recién creado, que estará en la carpeta .build/debug/play. Si lo ejecutamos llamando a esta ruta, veremos un mensaje: Hello world!.

Ahora vamos a instalar Kitura como paquete dentro de nuestro programa, así que editamos el fichero Package.swift con el siguiente contenido:

Como vemos, en realidad estamos haciendo un programa Swift que importa el framework PackageDescription donde en el cual, creamos una constante package donde instanciamos el objeto Package con una serie de parámetros: el nombre (que ya estaría puesto) y una dependencia. Como vemos es un array, por lo que podríamos poner varios paquetes. Lo importante a entender aquí, es que Kitura se instala como parte de nuestro programa, no hay que hacer nada más.

Ahora vamos a nuestro archivo main.swift y ponemos el siguiente código:

¿Qué hace este código? Lo primero es crear una instancia o proceso en nuestro servidor llamado /hello, lo que quiere decir que responderá en el raíz del mismo y en esa ruta. El enrutado define el tipo de parámetro Content-Type que necesita en web, indicando que es texto plano en UTF-8. Y luego, haciendo uso de interfaces fluidas, genera en una sola línea el envío del estado correcto (a través de la enumeración .OK), el mensaje en texto y cierra el proceso.

Configurado el enrutamiento, definimos el puerto, y creamos una instancia del servidor con el constructor listen del objeto HTTPServer. Le pasamos el puerto y el enrutado como delegación del mismo (pues será un proceso en según plano que se ejecute de manera continua) y luego lanzamos el servidor con el método run() de la instancia server.

Lanzamos la siguiente instrucción, ya fuera del código, sabiendo que la primera vez se descargará Kitura y lo instalará, por lo que el proceso será algo más lento. Ojo, la ruta para ejecutar esta instrucción debe ser aquella donde está el archivo Packages.swift.

También instalará otros paquetes de red, dependientes, como JSON y varios soportes de comunicación en red. Una vez termine, podemos llamar al servidor desde un navegador, al puerto que hemos indicado (si estamos en local, tendríamos que poner localhost:8095) y veremos que aparece la página de bienvenida de Kitura. Si ponemos /hello, nos devolverá el mensaje Hello world! que habíamos puesto en nuestro código.

Haciendo llamadas JSON

Vamos a crear una parte con un JSON, así que editamos nuestro código en main.swift y añadimos un nuevo enrutamiento al ya creado. Justo debajo del que teníamos y antes de definir el puerto del servidor.

Puesto este código, ya tenemos algo más complejo que probar. El código en sí es muy sencillo: creamos un formateador NSDateFormatter para poder sacar la fecha y la hora en cadena y definimos la misma cabecera de respuesta que habíamos hecho con el anterior proceso, en texto plano y UTF-8.

Aquí, lo importante del código es el recibo, que creamos como un diccionario con las claves Mensaje y el texto Hello world y luego la fecha y la hora. La instrucción if let json = JSON(recibo) utiliza el constructor JSON para devolvernos una instancia ya formateada en este formato en la constante json. Pero como JSON puede no funcionar correctamente, tenemos que hacer un enlace opcional para validarlo. Luego, en el .send enviamos la constante json en vez de un texto. Nada más.

Volvemos a generar el paquete, este se re-desplegará en el servidor y podremos ahora acceder a `/hoy’ en el mismo. Veremos que nos devuelve un recibo en JSON que podremos recuperar con cualquier proceso estándar de llamada a un servidor web.

Sencillez ante todo

No hay que hacer nada más. No hay que instalar ningún servidor en ningún sitio ni realizar complejas instalaciones. Una vez tenemos Swift instalado en Linux (o en una máquina virtual del mismo a través de Docker, Vagrant o VirtualBox) solo tenemos que crear los programas que hemos puesto aquí y nada más. El servidor se instala solo en la compilación y se configura. Así que podemos probar con varias configuraciones y a partir de ahí, llegar a donde queramos. Este código es muy simple, el que usa IBM para sus ejemplos solo que nosotros lo hemos intentado explicar para que quede más claro.

Os invito a probarlo y a contarnos vuestra experiencia. Un saludo y Good Apple Coding.

IBM Cloud Tools for Swift | Enlace

Acerca de Julio César Fernández

Analista, consultor y periodista tecnológico, desarrollador, empresario, productor audiovisual, actor de doblaje e ingeniero de vídeo y audio.

Otras recomendaciones

Swift 3.1 Hoja de Ruta

Swift 3.1, hoja de ruta hasta primavera de 2017

Swift 3.1 marca su hoja de ruta de aquí a primavera de 2017 con dos grandes retos: la compatibilidad de código con la versión 3.0 y potenciar el gestor de paquetes y la integración con servidor para conseguir aun más rendimiento en soluciones como Kitura, Vapor o Perfect (entre otros). Descubre los detalles en nuestra noticia y qué nos depara esta nueva versión menor del lenguaje.

  • Pedro Internet

    El problema es que Kitura funciona con Swift 3.

    • No es ningún problema. Tu app puede estar en Swift 2 o incluso en ObjectiveC. Y la guía de instalación de Swift en Linux de la web está actualizada a Swift 3. Tienes todos los ingredientes. Incluso puedes hacer debug de tu programa server side en Xcode 8 Beta y que tu app esté en el 7.
      Un saludo

  • Eduardo González Joyanes

    esto quiere decir que ya no es necesario un servidor de aplicaciones? Tiene balanceo de carga Kitura? balancea el linux?
    Buen artículo, y muy interesante…

  • jose luis sanchez

    Tan solo comentar que , en Xcode 8.2, swift build --init no me ha funcionado.
    He tenido que usar swift package init --type executable

    • Hola José Luis. Es correcto. Esta guía es de una versión anterior y la forma correcta de crear ejecutables ahora es la que comentas.
      Te invito a que le eches un vistazo a nuestro última guía sobre Swift 3 bajo Linux donde vienen explicados los últimos cambios.
      Gracias por el apunte.