Crea tu API Rest con Vapor, y una Arquitectura de microservicios

Entendiendo qué es el lado servidor de las aplicaciones móviles.

10 min readApr 24, 2021

Para comenzar es necesario entender primero las piezas que nos encontramos en el mundo del desarrollo del software, hay lo que conocemos como el frontend y el banckend o lado servidor, para ello vamos a comenzar con un poco de teoría.

El lado servidor también es comunmente conocido como Api Servidor o una App del lado del servidor, lo que indica que es una aplicación que no corre o no se ejecuta en un dispositivo sino que se ejecuta en un servidor.

Estamos acostumbrados a que una app tenga al menos 3 partes: el modelo que contiene datos y procesos, la vista que tiene la interfaz de usuario y el controlador que conecta ambas partes, esto es el Frontend o parte de cliente.

Pero una app del lado servidor no tiene intefaz: solo procesos que controla datos, no es como una pagina web que tiene una interfaz en la que los usuarios interactuan pulsan ponen datos en un formualrio, le dan a un botón, aquí no, Esto es solo procesos que controlan datos y de hecho Cada operación envía y/o recibe datos a partir de una petición, es decir al lado servidor siempre se le evía una petición y luego también puede recibir datos a partir de esa operación o simplemente una respuesta o estado. Basicamente cuando tenemos que pensar en como crear nuestra app del lado servidor lo que tenemos que hay que atomizar cada proceso de gestión de datos a su mínima entidad de forma que cada llamada o petición se independiente una de otra, porque no hay un estado compaftido, cada operación que yo envío tiene un estado de devolución y ya está, por lo tanto al no tener estado, no deben exisit sesiones en el lado del servidor.

Por lo tanto cada solicitud debe contener toda la información necesaria para ser procesada. Esto es lo esencial a entender de los que es una aplicación o un API del servidor.

Otras de las características mas importantes que tiene un lado servidro es su capacidad de persistencia por encima de una aplicación o la posibilidad de conexion a bases de datos reales ya que como sabemos una app no puede conectar a una base de datos en un servidor(solo ficheros locales, CoreData, SQLite, Realm), lo que limita su capacidad de almacenamiento y gestion de datos. Sin embargo un lado servidor si puede concetar con otros servidores, entre ellos, de bases de datos como entidades con mayor capacidad y potencia. Y ¿Por que no podemos conectar a una base datos desde una app local?, pues porque necesitamos una conexión permanente, un socket permanente conctado a partir de un puerto TCP para tener una vía de comunicación constante a la base de datos, si eso lo hiciéramos dentro de una aplicación movil se nos fundiría la batería casi inmediatamente y aparte tener una canal abierto a través de un puerto constante hacia una entrada de datos no es nada seguro ni recomendable, solo las llamadas a ese lado servidor son las que me vana proporcionar los acceso a la base de datos.

Vapor que es la librería del lado servidor que vamos a implementar soporta PostgreSQL, MySQL/MariaDB y MongoDB, tambien, para trabajo en local y pruebas, admite usar ficheros SQLite, el ciclo de vida del usuario o la seguridad se gestiona desde el lado servidor con base de datos. Por lo tanto la cantidad de datos que piuede manejar una app desde un lado servidor es inifinitamente superior que en loca, aunque los tiempos sean algo mas grandes. Bien!! ya entendemos que es el lado servidor, ahora vamos a entender Swift en el lado servidor OMGGG!!.

Swift en lado servidor

Swift es un lenguaje de programación de proposito general, desde su lanzamiento el 2 de Junio de 2014 como futuro sustituto de Objective-C, Apple lo presenta como “Un lenguaje con el potencial de C, pero sin el equipaje de C”, con esto carga mucha responsabilidad a los programadores para que garanticen su trabajo y es demasiado facil hacerlo mal y que existan problemas de ejecución de codigo, sin embargo Swift esto lo previene con una capa de control de errores bastante potente que va a nivel de análisis y de compilación, además Swift usa la misma Arquitectura de LLVM de Compilación y es el mismo compilador de C, C++, Objective-C por eso se pudo hacer la implementación para que Swift y OBjective-C fueran interoperables, de hecho con C y C++.

El objetivo del lenguaje desde el primer día fue ser de proposito general y esto es algo que tenemos que quitarnos de la cabeza, pensar o creer que Swift solo esta destinado para las plataformas de Apple y no solo para iOS, eso no es cierto, Swift funciona en Linux desde finales de 2015, día que se hizo OpenSource, y además todos los grandes servivios en la nube como Mirosoft o Google Cloud, Amazon Web Services, IBM Cloud o Heroku soportan API’s en Swift del lado servidor bien de forma directa, bien a través de contenedores o de paquetes de construcción. IBM tiene una API de lado servidor propia: Kitura y Amazon tambien: Smoke.

Antecedentes, código interpretado o en VM Software

Soluciones como Django o NOde.js son interpretados contra un motor
Con Python, Javascript o Ruby cualquier error de código solo salta cuando se produce.
Las soluciones de código script son al estilo de la “vieja web”: todo se interpreta
Java en el lado servidor usa JVM(Java Virtual Machine), el código está en bytecode(código intermedio)
En java la maquina virtual interpreta y traduce en tiempo real
Garbage Collector en servidor, con Java, es un problema que genera pausas de proceso.
Python, Java o Javascript debido a sus arquitecturas tiene mas latencia y son las lentas
El uso de CPU es mayor por que tienen varias capas o modelos intermedios

Swift, la Web se acerca a la programación tradicional

Los errores en el código se detectan por anticipado en compilación o análisis
Los despliegues se basan en integracióncontinua de forma nativa
Usa test unitarios que validan la funcionalidad de forma mas eficiente
Procesos como el cifrado de datos son mucho mas rápidos compilados
La capa de abstracción de red esta basada en procesos asíncronos
Se acabó el paradigma web de interpretación de un código
Java tiene parte de esto, pero es menos eficente al depender de una VM Software.

Swift, código compilado e integrado con estándares

Swift va compilado como binario contra el sistema operativo (Linux 0 macOS)
Es más rápido, estable, seguro y previene errores por estructura y compilación de lenguaje
Incluye funciones básicas como trabajo de red, gestión de hilos y memoria por ARC
En su fundación es un lenguaje orientado a tipos por valor, con programación funcional nativa
Usa el formato JSON como entrada y salida, con serialización directa desde el propio lenguaje
Las soluciones de swuft de lado servidor se integran en los actuales estándares
Soporta PaaS(plataformas como software): Docker, Kubernetes o Cloud Foundry
Monitorización por Prometheus, autenticaciónJWT(JSON web Tokens) y foma parte de OpenAPI.

Historicamente la web siempre ha funcionado de forma síncrona, y esto que quiere decir, que se realiza una petición, se procesa(y se espera)y cuando está resuelta la petición, se devuelve, con el objeto de optimizar este proceso, muchos desarrolladores pensaron en crear un paradigma más óptimo, asíncrono, que mejorara el flujo, de ahí surgió Netty, un framework de aplicaciones de red conducido por eventos, para Java, pero en marzo de 2018 Apple creó su propia versión nativa en Swift : SwiftNIO(Swift Network Input output, no tiene nada que ver con Neo de matrix heee! OMGGGG!!), este framework se basa en ciclos de eventos, es decri un EventLoop es un objeto que espera a un evento y cuando este sucede lanza un callback que procesa el resultado de ese evento.

Apple actualiza de manera constante este framework, la versión 2.0 de SwiftNIO, tiene dos importantes novedades, además de muchas mejoras:

Soporta el protocolo HTTP/2 que aplica cambios como que es un protocolo binario y no basado en texto
Soporta multiplexación, que permite recibir y enviar varios emnsajes a la vez
Elimina información redundante durante una misma conexión
Usa una unica conexión TCP para recuperar todos los datos de una misma fuente
Incluye implementación nativa de Swift de la librería SSL (ya no es necesario usar OpenSSL)

Que cantidad de Teoría no?, pero es necesario conocer un poco del estado del arte de Vapor

Prerequisitos para darle cera a Vapor

Instalacion de HomeBrew

2. Comprobación de las Command Line Tools

3. Vamos a instalar Vapor ToolBox, para ello en nuestro terminal debemos escribir el siguiente comando:

C02VF3RYHV2F ~ % brew install vapor/tap/vapor

con la líneas vapor -h se puede obtener información extra sobre la instalacion del framework.

Pero esto no es un proyecto aún es nuetsra base para crear uno, ahí se instalarán las dependencias que sean necesarias para nuestra App de lado servidor.

Creando un proyecto por defecto

Bien lo primero es ubicarnos en nuestra carpeta de trabajo y crear una carpeta que será la ubicación de nuestros ficheros, como siempre trabajamos en GitHub pues vamos a ello, en nuestro terminal escribimos lo siguiente juna vez estemos dentro de nuestra carpeta, yo por ejemplo la he llamado ApirestVapor y dentro he ejecutado la instricción

C02VF3RYHV2F ApiRestVapor % vapor new APIRestVapor

Nos hará un par de preguntas, si queremos usar fluent, que es la dependencia para la gestion de base de datos del tipo Postgres, MongoDB, etc, yo siempre le digo que si y que trabaje con Postgres, por ejemplo, pero podeis probar las distintas opciones, ademas nos preguntará si quremos usar Leaf que es un poderoso lenguaje de plantillas con sintaxis inspirada en Swift. Puede usarlo para generar páginas HTML dinámicas para un sitio web front-end o generar correos electrónicos enriquecidos para enviar desde una API, yo de momento le digo que no, he inmediatamente después se hace la magia y se crea el proyecto en Vapor, éste proyecto usa SPM como gestor de dependencias y ya podemos abrir nuestro proyecto en Xcode.

Esta es la estructura de nuestra API Rest con Vapor, con la combinación (Cmd+Shif+.) se habilita la visualización de los ficheros tipo phantom o que inician con un (.), y vemos que se crea hasta el .gitignore, vaya maravilla!! no ??, ahora en ese mismo directorio que esta el proyecto desde el terminal esceribimos la siguiente instrucción para abrir el proyecto

C02VF3RYHV2F APIRestVapor % vapor xcode

Supef facil no ?? es una autentica maravilla, el fichero Package.swift define la instalación de dependencias y como esto esta enganchado a el gestor de Apple SPM, se observa en la parte de abajo las librerías que estan definidas en dicho fichero.

Aquí se pueden añadir tantas dependencias se deseen usar, de momento todo es gratis, y es un inicio, asi que no tocamos mucho este fichero.

Dentro de la estructura de ficheros esta uno muy importante el de Sources y este se subdivide en App y Run, en Run esta el fichero main.swift

Este es el primer fichero que busca SPM para comenzar a funcionar, tiene varias propiedades pero la ultima es la ejecución de nuestra API, super facil, tampoco se toca mucho.

Realmente lo mas importante y es con lo que se trabaja, es lo que se encuentra dentro de la carpeta App con los modelos, las migraciones para crear las bases de datos y los controladores que son los que nos van a dar la funcionalidad de los endpoint y nos llega uno siempre por defecto, para que nos enteremos de como funciona.

Vamos a Ejecutar el proyecto el proyecto, comprobamos que nuestro dispositiovo sea My Mac y le damos a Run con el play, vamos el de toda la vida, nos va a salir un mensaje de este tipo:

Poner vuestra contraseña de equipo y si todo va bien !! deberiais tener en la consola este mensaje

Colocar la url que indica la consola y ponerla en un navegador y os saldrá esto:

Yeahhhhhh!!!!, funcionaaaa, que maravilla no ?, mmmm.. pero en donde se hace eso ??, si os fijais en el fichero routes.swift, vereis algop que tiene toda la pinta de microservicio, o por lo menos cuando hacemos una llamada desde nuestra App.

Ahora que lo veis, cambiar el texto por el que deseéis, mmm y el de abajo es un parametro ??, pues si, colocar http://127.0.0.1:8080/hello y mirad que pasa!!