La Cuarta Plataforma: Cómo Vega Nos Acercó Sorprendentemente a “Escribir Una Vez, Ejecutar en Todas Partes”

Sin embargo, la cuarta plataforma se acercó sorprendentemente a WriteOnce, RunEverywhere, y Promise. Este es un estudio de caso de Zotoo, donde vas a aprender cómo esta cuarta plataforma lo remodela de la manera en que moldeamos las otras tres. Porque durante más de una década, incorporamos aplicaciones a las diferentes plataformas, a la web, Android, Apple, cada una con su propia base de código, su propio equipo, su propio calendario de lanzamientos, que eran muy fragmentados y diferentes y difíciles de pensar.

Hace unos años, Amazon nos mostró Vega, un nuevo sistema operativo donde React Native es un marco de interfaz de usuario principal. Y lo tomamos como una oportunidad para construir sobre él algo que es verdaderamente multiplataforma. Y ahora, esto cambió totalmente la forma en que moldeamos las otras tres. Hoy, tenemos una base de código en cada pantalla, moldeada en cada sprint. Y esta historia es imposible de contar solo desde la perspectiva tecnológica. Así que, también verás el punto de vista del producto y de la organización.

Hola, soy Bo. Y soy un ingeniero principal en Zotoo. También co-organizo el meetup de React Berlin. Y estoy orgulloso de mi hija y mi hijo. Y disfruto hacer senderismo con mi esposa donde sea que ella nos lleve. Y quería decir que tengo un perro, pero es un poco al revés. Así que, sí, también puedes notar un estilo de anime en esta presentación. Lo tomé como uno de los contenidos de más rápido crecimiento que distribuimos. Entonces, ¿quién es Zotoo? ¿Y qué estamos haciendo? Nuestro producto es el streaming. Somos una empresa de streaming. Y estamos tratando de hacerlo fácil para nuestros clientes y usuarios, sea cual sea el dispositivo o la tecnología que traigan. Y esto literalmente significa encontrarse con las personas en los momentos que viven. Y te daré un ejemplo de mi vida o de la vida de mi familia. Donde nos reunimos en la víspera de Navidad para ver nuestra película navideña favorita en la pantalla grande.

O cuando estoy en movimiento, viendo el partido de fútbol favorito y animando y apoyando a mi equipo en el móvil. O si estás en un viaje largo y los niños están súper aburridos y les gustaría ver su programa favorito en pantallas multimedia. Y básicamente en cualquier situación desde cualquier dispositivo. Por ejemplo, cuando estoy tomando café por la mañana y puedo ver noticias en una nevera. Literalmente un día pusimos nuestra aplicación en la nevera y funcionó. Y esto viene, por supuesto, con desafíos.

Para encontrarse con las personas en sus dispositivos, su vida. Porque podría ser cualquier cosa, ¿verdad? Podría transmitir un video. Y en nuestro caso, lo separamos en dos experiencias. Una es móvil, cuando tienes algo en la mano. Y la otra es pantalla grande. Y esto es más nicho. También un portafolio más amplio de dispositivos. Donde tenemos experiencia única. ¿Será una pantalla inteligente? O, no sé, una estación de juegos como Xbox. O dispositivos de conexión como Chromecast o Apple TV, Fire Stick. Y por supuesto navegadores web.

Así que sí. Y la mayoría de estos dispositivos funcionan en las tres plataformas. Apple, Android, web. Y reconocemos algunos clientes a los que estamos distribuyendo aplicaciones únicas. Por ejemplo, para Apple podría ser TVOS. Y iOS para Android es Android TV, Android móvil, Fire OS, cajas de configuración, algunas tabletas Android. Muy diverso en comparación con Apple. Y web, ya sabes, es una locura. Cualquier cosa que pueda tener un navegador dentro, puede transmitir un video. Y podría ser, no sé, Chrome Safari, Firefox. Pero también podría ser un televisor inteligente con sistemas operativos basados en web. O una nevera que mencioné en el navegador Chromium.

Y somos conocidos no solo como la herramienta en la región DACH, sino como una solución de etiqueta blanca para clientes de todo el mundo. Y al final, como si multiplicaras todo, son cientos de aplicaciones para enviar. Y esto es un desafío a esta escala. Y a lo largo de los años, cada nueva plataforma multiplicó nuestro esfuerzo en lugar de extenderlo. Siempre quisimos estar en algún lugar del sitio donde todo se comparta. Sin embargo, la situación hace unos años era así. Teníamos aplicaciones existentes con su propia lógica de aplicación, con sus propias capas y suites de prueba, con su propia tecnología interna, impulsada por su propio equipo. Así que imagina incorporar algo más a eso. Eso requeriría un presupuesto bastante significativo y complicaría en exceso la alineación. Y sería genial si los equipos, por ejemplo, que estaban trabajando en el primer trimestre en una característica, el segundo trimestre en otra, el tercer trimestre, digamos en favoritos, pudieran realmente liberar sus recursos y no preocuparse mucho por las especificidades tecnológicas, sino más bien centrarse en sus características, en sus valores de flujo. Y a lo largo de los años, hubo varios intentos fallidos para lograr esto. Y es imposible simplemente tomar a todos los ingenieros de diferentes tecnologías y ponerlos en un solo equipo. De lo contrario, solo serían ingenieros sentados en el mismo canal aún enviando tres aplicaciones diferentes. Las personas necesitan hablar el mismo idioma. Y tratamos de encontrar una manera de hacerlo.

En 2019, 2020, acabamos de lanzar la aplicación PWA. Y esta era una tecnología súper prometedora. Y Google invirtió mucho en Project Fuga. Y tuvimos alguna historia de éxito. Por ejemplo, pudimos reemplazar esta PWA, nuestra experiencia de Windows, construida en C Sharp. Y no fue tan bueno para otros. Por ejemplo, Android Mobile, a pesar de que construimos PWA o TWA en este caso, y pudimos mostrarlo como proporcionarlo a nuestros clientes con paridad completa de características, algunas cosas no estaban accesibles para nosotros. Por ejemplo, DRM. Si estás en el negocio del streaming, tienes diferentes niveles de protección DRM. Y para un navegador, desafortunadamente, solo hay un nivel superficial disponible. Y no hay forma de obtener protección DRM fuerte, por ejemplo, para proteger tus transmisiones de éxitos de taquilla de Hollywood o algunos eventos deportivos únicos. Y por supuesto, el rendimiento era un poco diferente, especialmente con las animaciones. Así que tuvimos otra ronda, este tipo de enfoque híbrido, y echamos un vistazo a si podíamos construir, por ejemplo, la experiencia de reproducción en nativo y tener una experiencia web redondeada. Pero aún así, no coincidía con nuestras expectativas de calidad y rendimiento. Luego, en 2021, 2022, echamos un vistazo a una solución multiplataforma como Kotlin.

Estaba en beta en ese momento, supongo. Y el Flutter, pero la historia era la misma. La cantidad de dispositivos que cubríamos simplemente no estaba allí. Eran buenos con móviles, pero no con pantallas grandes. Y una historia algo similar fue con React Native.

Sin embargo, había un Community Fork que apoyaba Android TV y TVOS. Sin embargo, en ese momento, eso no nos parecía realmente creíble porque solo había un par de entusiastas apoyándolo. Y luego hubo un catalizador. A finales del 22, recibimos una invitación de Amazon junto con otros desarrolladores de streaming para una demostración en la oficina de Berlín. Y lo que nos mostraron fue bastante asombroso.

Así que lo primero que anunciaron fue que se alejarían de un sistema basado en Android primero. Van a construir un nuevo sistema basado en Linux y C++ como capa nativa. Pero lo más sorprendente para nosotros fue que este va a ser un sistema basado en React Native como marco de interfaz de usuario principal, integrado en el sistema operativo. Lo que significa que, a diferencia de Android o TVOS con React Native, no hay puente entre ellos. Es simplemente una traducción directa de React Native a código cercano al hardware.

Y echamos un vistazo a eso e hicimos algunas consecuencias, que fue un análisis FODA y destacó algunas fortalezas para nosotros porque ya tenemos un buen ecosistema web, que está muy cerca de React Native. Además, estaba en el React, ¿verdad? Tenemos ingenieros senior con una mentalidad estratégica ansiosos por probarlo. De las debilidades, realmente no tenemos experiencia específica en React Native. Y también, nos parece que en la forma en que abordamos el problema antes, tendremos que presupuestar un nuevo equipo de Vegas para apoyar esta plataforma.

Pero había oportunidades y muy buenas como Majin está dispuesto a tener una unificación multiplataforma. Y había como una vacilación y una gran amenaza si no vas a apoyar este, porque Firebase es uno de nuestros mayores clientes, y esta es también una rara oportunidad de ser pionero en algo así de nuevo. Así que queríamos aprovechar esta oportunidad. Y no solo tomarlo como una oportunidad para construir para Amazon, sino que lo vimos como una oportunidad para construir con ellos. Porque para nosotros, se convirtió en un punto donde estamos cambiando de otra plataforma para realmente construir en esta plataforma, soluciones multiplataforma.

Y para Amazon, por supuesto, podrían obtener nuestra aplicación en su portafolio o el feedback como sabemos, como pioneros en muchas direcciones diferentes. Por ejemplo, fuimos uno de los primeros que se lanzó junto con Google Chromecast. Y la importancia estratégica era clara, pero la hoja de ruta estaba llena y la capacidad de ingeniería ya estaba asignada. Así que recibimos una especie de no de nuestra gestión. Pero todavía vemos que esto viene y comenzamos a prepararnos un poco para una posible dirección. Y solo asignamos un ingeniero para sprints para probarlo, para construir una prueba de concepto, como para verificar si podemos hacer cosas muy básicas.

Y eso se proporcionó y realmente funcionó. Así que tomamos web y Android TV y los construimos juntos con una base de código existente. Y esta prueba de concepto nos mostró que podemos iniciar sesión y autenticar en nuestro sistema, también comenzar a hablar con nuestro backend. Y lo más importante, podemos reproducir nuestros streams con la misma calidad que teníamos en nuestra aplicación en vivo. Y no solo pudimos construir esto como un prototipo de React Native, pudimos integrarlo en la base de código existente.

Y entonces, de repente, obtuvimos luz verde. Y en realidad no estaba relacionado con la prueba de concepto, sino con otras cosas. Simplemente nos volvimos operativamente lentos y como esta alineación, estas diferencias en el ecosistema tecnológico fueron un dolor para nosotros. Y nuestro nuevo CTO, cuando se unió, declaró que nuestro frontend era intensivo en recursos y quería cambiarlo. Y entonces, obviamente, la prueba de concepto estaba sobre la mesa y se tomó como una apuesta arriesgada, pero algo muy prometedor que podría cambiar la forma en que trabajamos de una buena manera.

Así que la migración en la práctica, cómo lo hicimos. UTV, y cuando me refiero a UTV, eso significa un proyecto de TV universal. Y pusimos la palabra universal en mente de que podría enviar cualquier cosa. Así que lo comenzamos y lo conectamos a nuestra base de código monorepo, base de código web. Ya servía a diferentes proyectos como aplicación web, PWA que mencioné antes, aplicación para smart TVs, Chromecast, muchos, muchos otros. Así que React Native comenzó como otro proyecto más allí, integrado en la infraestructura existente.

Y eso también nos permitió usar la lógica de negocio y las configuraciones de capa compartida también que otros proyectos estaban usando gracias a JavaScript. Y nuestra lógica de negocio está escrita en puro JavaScript. No importa dónde lo conectes. Y lo que nos ayudó, especialmente en esta construcción junto con Amazon donde construimos juntos la aplicación con el sistema operativo, que lo cambió y no era lo suficientemente maduro o listo para producción hace unos años.

Sobrescrituras de tiempo de construcción cuando marcamos nuestros archivos y lo resolvemos a nivel de construcción con una plataforma específica o alias de plataforma. Así que pudimos omitir algunas cosas que no estaban listas y aún así enviar otras plataformas, pero también tratar algunos aspectos específicos de la plataforma de una buena manera donde puedes despojarlo y no enviarlo como lo harías en tiempo de ejecución a un paquete específico. Y generalmente la mayor sorpresa para nosotros en todo este desarrollo, como algunos aspectos específicos, los específicos de la plataforma eran una capa muy delgada.

Por ejemplo, supongo que el más grande fue Android, tal vez Apple, donde necesitas para algunos modelos construirlo en el lenguaje nativo. Por ejemplo, para Vega, era una capa de Metron Bundler, pero todo lo demás se resolvía como un no-modelo regular. Así que modelos de React Native. Sí. Y Web, obviamente ya teníamos esto en el sistema. Y luego en el verano de 2024, y recuerdo este momento donde pasamos dos noches y dos días con un ingeniero tratando de comprar en Vega, porque tiene como una mecánica de resolución diferente que el Metron Bundler.

Pero al final, lo resolvimos. Y lo que ves en la pantalla es la primera vista de Vega. Hoy en día, todo es mucho más fácil. Amazon tiene instrucciones increíbles. Podemos hacer multiplataforma y ejemplos que puedes simplemente copiar y conectar.

Otra cosa que fue bastante desafiante para nosotros, diría, es que no había una solución de pruebas multiplataforma. Así que cada sistema se enviaba con su propia cosa, y desarrollar algo como multiplataforma consume muchos recursos. Así que puedes llegar rápidamente a la degradación si no miras en las cuatro plataformas, pero también es difícil. Así que si tienes alguna capa de prueba que lo asegure por ti, eso es genial.

Que estés seguro. Y construimos tal cosa internamente. Lo llamamos Universal System. Este marco ya cubre web y Android y aún está construyendo Apple. El objetivo principal de esto, seguimos escribiendo pruebas play-write. Tal vez esto sea una sintaxis un poco más abstracta.

Algo así como comparar React con React Native. Pero sí, y luego lo estamos esperando en los motores específicos de la plataforma, como un controlador web o Appium. Y lo que es interesante, si estás familiarizado con Convince law, toda esta transformación tecnológica también estaba conectada con la transición organizacional que tocaré un poco más adelante.

Así que la ley de Convince dice que cualquier organización que diseñe un sistema producirá un diseño cuya estructura es una copia de la estructura de comunicación de la organización. Y esto nos ha sucedido. Así que a lo largo de los años hemos moldeado nuestra organización de manera diferente. Y se reflejó en la base de código, lo que nos permitió aislar algunos dominios propiedad de los equipos. Así que dentro del monorepo podrían ser autónomos y moverse rápido.

Entonces, ¿cómo se veía el producto para esta migración que nos permitió construirlo? Una de las decisiones estratégicas más importantes para nosotros fue mantener la experiencia del usuario consistente. No intentes cambiar la tecnología y también la experiencia. Porque también queríamos medir cómo funcionaba esta nueva tecnología. Y si realizas algo que es diferente, es difícil. Así que restringimos el rediseño a propósito.

Sin embargo, hubo algunas cosas a las que no pudimos resistirnos y añadimos algunas pequeñas mejoras incrementales que no afectarían mucho la experiencia del usuario, como hábitos quiero decir, pero mejorarían algo que siempre fue una lucha. Así que, por ejemplo, cada vez que nuestros usuarios olvidaban las contraseñas, restaurarlas en la pantalla grande era un dolor debido a la escritura de depuración. Así que simplemente introdujimos un código QR. Y hubo varias otras cosas como esa que hicimos por todas partes.

Y cuando lanzamos nuestra primera beta, fue bastante bien aceptada por nuestros clientes. Y si alguna vez lanzas una nueva tecnología o reescribes todo desde cero, sabes cómo reaccionan las personas, cómo nuestros usuarios reaccionan ante los cambios. Y esta transición fue bastante fluida y coincidía con la experiencia que ya aman. Y un tema interesante en este caso es cómo transformamos nuestros reinos tecnológicos en una organización de valor de flujo. Y hay un libro muy interesante que sugeriría leer si estás en este tema. Generalmente puede aplicarse a cualquier empresa de cualquier escala. Y describe diferentes topologías de equipos y cómo podrían mezclarse juntos.

Y nuestro viaje fue a lo largo de los años. Comenzamos en 2023 con un equipo de base para probar cosas. Y luego trajimos nuestra primera experiencia externa porque no teníamos experiencia en React Native internamente. Y luego nos ayudó también a escalar y traer a otros a esta transformación. Y al final, en 2025, toda la organización se movió hacia una organización alineada con el flujo. Así que nos moldeó no solo desde la tecnología, sino desde cómo nos alineamos unos con otros. Así que permíteme profundizar en eso. Comenzamos muy humildemente, como mencioné. En 2023 formamos un equipo UTV, que no era muy diferente del equipo de proyectos que teníamos antes. Estábamos haciendo de todo, como cosas de plataforma, desarrollo de características para paridad de características, video, toda la infraestructura. Pero para React Native.

Y este equipo ganó algo de experiencia. Y después de que el equipo estuvo seguro de trabajar, lo dividimos. Y la mitad del equipo obtuvo nuevos miembros del equipo de ingenieros existentes y comenzó a ayudarlos a integrarse a la nueva tecnología. Y también añadimos ingenieros principales para apoyar a estos equipos y esta transición mediante su mentoría. Así que comenzamos un poco acelerados. Pero aún así era como dos equipos de proyectos haciendo lo mismo, pero aún poseyendo todo. Y luego, en 2025, comenzamos cosas más interesantes. Comenzamos a localizar algunos dominios. Así que estos equipos que anteriormente trabajaban en todo comenzaron a enfocarse solo en el desarrollo de características. Mientras añadimos otro equipo que se encargó de todo lo específico de la plataforma y también añadimos un equipo que descargó a otros de los temas de infraestructura o calidad de código. Y, por supuesto, los ingenieros principales seguían apoyando toda esta alineación, lo cual funcionó. Algunos fueron buenos, otros no.

Y luego, después de los aprendizajes de 2025, llegamos al modelo actual, donde todo funcionó bastante bien, diría yo. Los equipos podían centrarse en su área de responsabilidades. Reconocemos el dominio de propiedad y temas específicos. Por ejemplo, tenemos un equipo que juega a ver, que está en el dominio de video y maneja todo lo relacionado con ello. Como video obviamente, reproducción, OSD, video nosotros. Por otro lado, tenemos un equipo de descubrimiento de contenido que se encarga de llevar usuarios a los videos a través del descubrimiento de colecciones. También tenemos capítulos de plataforma de formato para tener esta experiencia que ganamos. Y también transferimos a nuestros desarrolladores nativos con su experiencia única a los equipos enfocados en la plataforma. Y extendimos el equipo de infraestructura y calidad de código y el equipo de plataforma en un capítulo de tecnología front-end, que se encarga de todo lo demás.

Y, sí, ¿qué aprendimos de eso? Tres cosas que defenderemos sin dudar es que íbamos a la solución brownfield en el greenfield. No lo bifurcamos en otra plataforma ni intentamos recrear todo desde cero. Lo agrupamos y nos ahorró mucho tiempo y muchos errores. Definitivamente optamos por una estructura de código organizada por dominios, porque funciona muy bien y crea este aislamiento donde los equipos son autónomos y pueden moverse más rápido y no depender unos de otros. Y más como una cosa tecnológica de nicho es la sobrescritura en tiempo de compilación, por supuesto. Este es un patrón bastante común que, no estoy seguro si es muy popular en React Native, pero por ejemplo, en C Sharp u otros, tales cosas ayudan a realmente aislar algunas especificidades. Así que tener esto desde el principio, sí, fue muy útil.

Y hubo algunas cosas que podríamos haber hecho diferente, y si lo hubiéramos sabido, definitivamente habríamos invertido en infraestructura antes y, por supuesto, traer algo de experiencia en React Native antes sin intentar resolverlo todo por nosotros mismos. Tener a alguien que ya tiene y gana esta experiencia es muy importante porque puede acelerar significativamente a los equipos. Uno de los hallazgos tecnológicos fue que Vega y Web están bastante cerca uno del otro. Y eso fue básicamente una capa de JavaScript traducida directamente a especificaciones de hardware. Desde el aprendizaje del producto, diría que cometimos algunos errores al cambiar la experiencia, y fue percibido muy duramente por el usuario. Así que incluso un cambio menor en UX desencadenó como una avalancha de comentarios. La realidad es que tenemos que cambiar todas nuestras pantallas, todas nuestras aplicaciones. Android fue definitivamente uno de los más desafiantes debido a la fragmentación y la cantidad de dispositivos y sus variaciones, a diferencia de Apple o Fire OS, donde tenemos una larga lista de dispositivos. Pero en general, uno de los resultados prominentes del producto fue que esta innovación tecnológica aceleró nuestra capacidad de envío. Y esta apuesta dio sus frutos en los números. Ya llevamos un año en producción con nuestras primeras aplicaciones. Y esto es muy comparable a nuestra aplicación nativa que estamos reemplazando gradualmente usando la misma tasa de fallos. No hubo incidentes importantes. No hubo capacidades que no pudiéramos entregar.

Y si comparas, por ejemplo, el último trimestre del año pasado y el primer trimestre de este año, nuestro rendimiento y capacidad para entregar características creció casi un 25% por trimestre. Por supuesto, hay un cierto porcentaje aquí debido a una mayor adopción de IA, pero ya teníamos esto en el anterior. Así que literalmente puedes sentir cómo está energizando a todos, cómo todos pueden lanzar y centrarse en sus propias cosas.

Y desde otro ángulo, este viaje nos mostró que la comunidad y el mundo exterior en general todavía piensan que React Native es solo para móviles, para iOS o Android, lo cual claramente no es cierto porque hay mucho más en este mundo que podemos hacer con estas cosas increíbles. Y con suerte, con Amazon como un gran jugador uniéndose a esta carrera, tendremos más estándares, más reconocimiento y más universalidad.

¿Y dónde estamos ahora? En septiembre del año pasado, lanzamos nuestro primer Android TV y luego en octubre cumplimos nuestra promesa a Amazon de entregarles una aplicación. Y luego, más tarde, en abril de este año, también comenzamos a reemplazar nuestros sistemas de firmware heredados con Android. Así que Android y Android. Pero también estamos lanzando ahora Apple TV como beta y esperamos este otoño tener televisores inteligentes.