Cómo logró Andrew Barba ejecutar Swift sin servidores por medio de Compute

Hace poco, Andrew Barba, ingeniero responsable del éxito de Swift Cloud, publicó un SDK de Swift concebido para nuestra plataforma Compute, con prestaciones avanzadas y todo tipo de funciones. Tuvo lista la versión inicial en solo cuatro días. Gratamente sorprendidos, decidimos entrevistarlo para que nos contara qué objetivos tenía su proyecto y qué proceso de diseño siguió.

Si te dedicas al desarrollo de aplicaciones para el ecosistema de Apple o relacionadas con este, seguro que has oído hablar de Swift, el lenguaje de programación diseñado por Apple y la comunidad de código abierto que trata temas relativos a iOS, iPadOS, macOS, tvOS y watchOS.

Aunque el ecosistema de Apple tiene un alcance enorme en dispositivos como tabletas y teléfonos, la comunidad de Swift lleva mucho tiempo buscando la forma de ejecutar su lenguaje favorito en servidores. Los responsables de mantener el lenguaje han ido poniendo los cimientos para ello. Por ejemplo, han agregado compatibilidad con la compilación de código a WebAssembly, pero su labor no ha tenido demasiado eco en la comunidad, al menos hasta ahora. 

A continuación, reproducimos algunos fragmentos interesantes de la entrevista que hicimos a Andrew Barba: 

¿Por qué Swift es una buena elección? ¿Qué atractivo tiene para ti?

Me inicié en el sector como desarrollador de iOS, así que empecé a trabajar con Swift desde el principio. Su importancia es grandísima en el ecosistema de iOS, y el nivel de seguridad y el rendimiento que ofrece me cautivaron. Más tarde mi carrera dio un giro hacia los backends, por lo que dejé de utilizar Swift con tanta frecuencia y pasé a programar JavaScript con Node.js.

La verdad es que esa última experiencia de desarrollo me pareció muy deficiente en comparación con el diseño de aplicaciones nativas que hacía con Swift. Hubo momentos emocionantes, como cuando hace unos años Apple se tomó en serio conseguir que Swift se ejecutara en el servidor y para ello, por ejemplo, publicó herramientas de CI y paquetes públicos con los que ejecutar Swift en AWS Lambda.

¿Qué te impulsó a diseñar un tiempo de ejecución de Swift para Compute?

Implementar paquetes de Swift en AWS era demasiado costoso. Además, dominar la arquitectura de la nube y los archivos Docker exigía unos conocimientos demasiado profundos… Quería eliminar algunas barreras a la ejecución de Swift en el servidor que afectaban a la comunidad de desarrolladores de iOS. 

No podemos olvidarnos de la extraordinaria labor del equipo de Wasm para Swift, que consiguió que Swift se compilara en WebAssembly. De hecho, al analizar su trabajo a fondo tuve una revelación: ¿por qué no implementar todas las especificaciones del tiempo de ejecución de modo que nada se interponga entre el compilador y la plataforma?

¿Por qué escogiste Compute?

Bueno, intenté diseñar la integración de Swift con Cloudflare Workers, pero vi que eran necesarias demasiadas dependencias para programar un paquete que cumpliera todos los requisitos de tamaño de Workers. Además, no quedaba claro cómo sacar partido de algunas funciones de la plataforma, como las peticiones HTTP salientes y la capa de caché. Logré integrar Swift y Compute directamente porque Fastly expone las llamadas de host del sistema principal de Compute, y eso hace que se necesiten menos capas de abstracción y paquetes mucho más pequeños.

Básicamente, Fastly es políglota y admite varios lenguajes.

Actualmente, vemos cómo la informática en el edge evoluciona en multitud de direcciones interesantes. ¿De qué forma crees que prefieren los desarrolladores interactuar con las plataformas en el edge? ¿Nos pondremos de acuerdo en una norma que lo regule?

Ya existe una especificación normalizada de HTTP, o sea, que hoy mismo podríamos definir un conjunto universal de abstracciones en relación con la informática en el edge. Creo que, en términos globales, la meta de los desarrolladores es controlar de forma pormenorizada el almacenamiento en caché. Es posible que las plataformas sigan discrepando respecto a aspectos como el estado: todo el mundo trata de reinventar la rueda, con métodos distintos.
Son tantas las complejidades de estas plataformas y el trabajo que ya te ahorran, que cada vez es más difícil poner a prueba un equipo de producción equivalente de forma local. Por eso vemos que hay más herramientas que te ayudan a utilizar servicios remotos como parte de los flujos de trabajo de desarrollo o de realización de pruebas: túneles, páginas de pruebas de configuración, etc. Las herramientas Fiddle, de Fastly, y Viceroy son alucinantes. Podríamos hablar largo y tendido sobre las aplicaciones de archivo único; sobre la capacidad de asimilar todo en un solo lugar o la capacidad de realizar pruebas e iteraciones rápidamente. 

En tu opinión, ¿qué nuevos casos de uso surgirán en el edge?

Es difícil saber qué utilidades se podrán ejecutar en exclusiva a través de la edge computing. Diría que la optimización de imágenes. O quizás el aprendizaje automático: en combinación con la informática en el edge, esa disciplina tendría un futuro prometedor. 

La funcionalidad más destacada de cualquier red del borde es la resiliencia. Es fácil trabajar con aplicaciones de edge computing que no tienen un estado asignado; los problemas surgen con el estado y la coherencia. Por eso mismo es tan interesante Spanner, de Google.

¿Qué consejos les darías a los desarrolladores que están empezando su carrera profesional? ¿Se parecerían en algo a los consejos que tú mismo te habrías dado en tus inicios?

Ahora se programa código de una forma más funcional y declarativa, que se aparta de la lógica imperativa y rebaja la barrera mental que impide comprender qué tareas realiza tu aplicación. Es importante escoger la cualidad que refleje mejor la naturaleza de tu código. Las herramientas son mucho más potentes hoy y ya no es necesario profundizar: solo tienes que encontrar una plataforma adecuada que te dé lo que necesitas, para alcanzar niveles de productividad nunca vistos.

Si te apetece probar cómo va Swift con Compute (o incluso ayudar a Andrew perfeccionar el SDK), echa un vistazo aquí a su repositorio del tiempo de ejecución. Si este artículo te ha parecido inspirador y quieres poner a prueba tu propio proceso de diseño en Compute, aquí puedes dar los primeros pasos.

En Fastly nos gusta echar mano de una coletilla que resume nuestra cultura: por desarrolladores y para desarrolladores. Con la primera parte —«por desarrolladores»—, nos referimos no solo a los equipos de Fastly encargados de diseñar nuestros productos, sino también a la comunidad de desarrolladores en general, cuyo trabajo es clave en nuestro ecosistema y permite a toda nuestra base de usuarios programar con los métodos y en los lenguajes que prefieran.
Si quieres que analicemos tu trabajo en el blog o deseas compartir los resultados de tus experimentos con el SDK de Swift de Andrew, mándanos un tuit.