¿Por qué Compute aún no es compatible con JavaScript?

Al crear Compute, nuestro entorno informático sin servidores, nos marcamos tres objetivos: que los desarrolladores pudieran diseñar aplicaciones y experiencias de gran rendimiento y con un alto nivel de seguridad; que lo hicieran en el edge; y que lo hicieran con sus lenguajes de programación preferidos. De ahí que una de las preguntas que más nos hagan sea por qué Compute no admite JavaScript.

La pregunta es relevante, ya que otras opciones serverless del mercado sí son compatibles con JavaScript. En artículos anteriores, te hemos contado cómo evaluamos la incorporación de nuevos lenguajes a Compute y te hemos recordado que JavaScript no puede compilar aún en WebAssembly, que es la tecnología con la que diseñamos Compute. La buena noticia es que estamos evaluando AssemblyScript para dar respuesta a esta demanda. AssemblyScript es, en realidad, un subconjunto de TypeScript (a la vez que un superconjunto con tipo de JavaScript) que te permite utilizar el modelo y la sintaxis de programación de JavaScript. Además, te permite conservar las ventajas que WebAssembly ofrece en seguridad con tipos y rendimiento.

Sin embargo, aún hay quienes se preguntan por qué hemos optado por diseñar desde cero nuestra propia cadena de herramientas de compilación, tarea de enorme dificultad, en lugar de elegir el camino fácil, como puede ser recurrir a una tecnología estándar como V8, que ya trae de serie la compatibilidad con JavaScript.

¿Compramos o diseñamos?

En Fastly, llevamos muchos años analizando los problemas a partir de principios básicos y sin rehuir proyectos difíciles que sabemos que van a beneficiar a nuestros clientes. Diseñar nuestra propia infraestructura personalizada de enrutamiento quizás no tuviera sentido para una startup recién creada, pero es que las soluciones de red que había entonces nos obligaron a elegir entre el rendimiento y el control (la flexibilidad). Solo con una solución propia fuimos capaces de lograr ambos objetivos. Una decisión que nos sigue aportando ventajas competitivas.

Aplicación de este principio a Compute

De modo similar, las tecnologías sin servidores que hay en el mercado obligan a elegir entre el rendimiento y la seguridad. Un «arranque en frío» la primera vez que se ejecuta una función serverless requiere mucho más tiempo que los posteriores «arranques en caliente», cuando ya se ha inicializado todo lo demás. Algunas tecnologías mitigan este problema, en parte reutilizando el entorno en muchas peticiones para mitigar los costes de arranque en frío entre muchas invocaciones de función. No obstante, esto se convierte en un problema que pasa de afectar al rendimiento a afectar a la seguridad. De hecho, ya hay toda una categoría de vulnerabilidades de seguridad que se generan a partir de la reutilización de entornos. Los atacantes podrían tratar de acceder a datos «remanentes» de invocaciones previas o contaminar el entorno de manera deliberada para extender el daño a invocaciones posteriores.

Si elimináramos los arranques en frío, podríamos idear una solución que ofreciera un alto rendimiento y un alto nivel de seguridad. Eso fue eso precisamente lo que conseguimos: los tiempos de arranque de Compute son inferiores a 35 microsegundos. Este avance significa que podemos proporcionarle a cada petición un entorno operativo totalmente limpio, con lo que deja de existir la posibilidad de que los datos perduren de una invocación a otra.

Compatibilidad con JavaScript: sí, pero no de cualquier manera

El objetivo es lograr este equilibrio de manera sistemática y, a la vez, ser compatibles con tu lenguaje preferido. Para ello, nos hemos propuesto conseguir la compatibilidad de JavaScript con AssemblyScript. Así que no te pierdas las novedades que irán apareciendo pronto en este sentido. Mientras tanto, las inversiones destinadas a ampliar el alcance de Compute no van a parar y no nos deja de fascinar cómo nuestros clientes aprovechan el potencial de nuestra plataforma con distintos lenguajes.