Cómo Realm por MongoDB está probando módulos nativos “en el dispositivo”

Hola. Soy Krane. Trabajo para MongoDB en lo que solíamos llamar Rel, pero que ahora se conoce como los Atlas Device SDKs. Ayudo a construir y mantener nuestro paquete de TypeScript, apoyando múltiples sistemas operativos, plataformas y motores de JavaScript. Y hoy, quiero compartir una técnica que usamos para probar nuestro código en cualquier lugar donde necesite ejecutarse. MongoDB Atlas es una plataforma de data para desarrolladores multicloud, una suite integrada de servicios de data y database en la cloud, que te permite construir con data. Y una parte de esto es acercar la data al lugar donde se está utilizando. Y a esto lo llamamos Atlas para el Edge. Un lugar donde se está utilizando tu data es en los dispositivos móviles de tus usuarios finales. Y para eso, construimos los Atlas Device SDKs, anteriormente conocidos como Realm. Así que los Atlas Device SDKs cuentan con una database local que se ejecuta en la aplicación. Tiene sincronización bidireccional de data entre la aplicación y la database que se ejecuta en la cloud. Y no requiere conectividad a internet, a menos que necesite sincronizarse, por supuesto. Y porque no tiene este requisito, cuando lees y escribes data, es de muy baja latencia. Y además de esas APIs, también tenemos APIs para observar la data a medida que cambia en el servidor y se propaga al dispositivo. Y esto te permite construir experiencias de usuario verdaderamente reactivas. Además de TypeScript, tenemos soporte para Swift, Kotlin, .NET, solo por nombrar algunos. Y para que eso suceda, tenemos un componente central común escrito en C++. Y nuestro equipo aprovecha la generación de código para exponer este componente central como una interfaz de TypeScript en la que construimos el SDK encima. Y para que eso suceda, generamos código, código de pegamento, código de enlace, lo llamamos, entre este componente central y los diversos motores de JavaScript y sus APIs de C++. Actualmente apoyamos el núcleo de JavaScript en Hermes a través de JSI para React Native y también apoyamos V8 a través de NAPI para Node.js y Electron. También tenemos una vista previa del soporte de Wasm para los navegadores. Así que tenemos todo este código TypeScript hecho a mano y reglas que usamos para generar código para todas estas diferentes plataformas con motores de JavaScript que se comportan ligeramente diferente.

Así que naturalmente queremos probar esto en todas las plataformas compatibles antes de lanzar algo en las aplicaciones de miles de usuarios. Cuando me uní, teníamos un solo paquete que exportaba múltiples funciones asíncronas y teníamos entornos de prueba específicos que eran código hecho a mano, algo de él nativo, que no se probaba en absoluto. Era una pesadilla mantenerlo, especialmente cuando queríamos avanzar y actualizar estos entornos a las versiones más recientes de las plataformas que apoyábamos. Y esta falta de developer experience me afectó. Solo quería poder ejecutar la prueba en modo de observación en cualquier plataforma que apoyáramos, tener una increíble developer experience, en lugar de pasar mi tiempo actualizando estos corredores de plataforma o código de ejecución específico de la plataforma. Y pensé para mí mismo, ¿qué pasaría si simplemente ejecutáramos el mismo código en todas las plataformas, y lo manejáramos desde la comodidad de nuestras terminales, y pudiéramos escribir y mantener, y más importante, probar este código por separado de los entornos en los que lo probamos. Básicamente solo quería ejecutar un CLI en mi máquina host, ejecutar las pruebas en el dispositivo, y obtener los informes de vuelta en mi máquina host.

Entonces, en 2019, eso es exactamente lo que construí. Construí esto alrededor de Mocha. Honestamente, probablemente no hice demasiada investigación. Parecía popular, y sabía que podía ejecutar pruebas tanto en Node.js como en un navegador. Y se usaba en otros lugares de nuestra organización.

Y el CLI de Mocha, básicamente, esta es una diapositiva sobre la arquitectura simplificada de Mocha. Básicamente, una vez que ejecutas el CLI, instancias un corredor, que requiere los archivos de prueba, y luego comienza la ejecución. Y el progreso de las pruebas aprobadas y fallidas se emite a través de eventos de vuelta al CLI, que luego se retransmite a los reporteros. Y nombré mi herramienta Mocha Remote basándome en esto. No es tan popular como Mocha, como puedes ver, pero y en su mayoría son 900 descargas semanales. La mayoría de ellas son probablemente nuestro CI. Y esta es parte de la razón por la que quiero compartir esta historia hoy.

Intenté reutilizar el CLI de Mocha, pero encontré difícil extenderlo porque el corredor en sí no es extensible o no es posible configurarlo desde el CLI de Mocha, pero afortunadamente fue muy fácil de implementar, re-implementar eso, y el CLI de Mocha Remote ahora soporta casi todas las opciones que puedes pasar a Mocha, incluyendo la búsqueda de un título de prueba, incluyendo tiempos de espera, especificando reporteros, observando, y luego también un contexto, que yo mostraré más tarde.

Así que el corredor de Mocha, el corredor original de Mocha, en realidad pude empaquetarlo en una variante independiente del tiempo de ejecución usando webpack, y esto es lo que se ejecuta en las diversas plataformas. En lugar de simples eventos, usando la emisión de eventos, usamos una conexión WebSocket entre el corredor, el cliente y el servidor del CLI de Mocha Remote. Y una vez que el cliente se conecta al servidor, recibirá un mensaje para comenzar a ejecutar las pruebas. El cliente o el corredor ejecutará una función de prueba suministrada por el desarrollador, que básicamente definirá las pruebas ya sea importándolas o definiéndolas en línea. Y una vez que el corredor de pruebas comienza a ejecutarse, comenzará a enviar estos eventos de pruebas aprobadas y fallidas a través de un socket web de vuelta al CLI, que se propaga a los reporteros.

Esto es lo que parece cuando invocas el CLI de Mocha Remote, y puedes ver que buscamos todas las pruebas que tienen conexiones en el título, y también suministramos este contexto, en caso de una URL de API, que se propaga a través de este sistema al corredor, y lo mostraré en un segundo. También suministramos el subcomando noderuntestappjs, que es responsable de iniciar la aplicación de prueba. Y la vida de este subcomando y el CLI de Mocha Remote están vinculados de tal manera que si el subcomando sale prematuramente, el CLI de Mocha Remote también saldrá. Y por y viceversa. Así que también asegura que el código de estado correcto se propague cuando las pruebas fallan en el dispositivo o el dispositivo se bloquea o lo que sea, el CLI de Mocha Remote obtendrá el correcto código de salida no cero.

Genial. Creo que casi es hora de las demostraciones. Solo quiero mostrar aquí, esto es lo que parece en un cliente. Obtiene la prueba, o suministras la función de prueba y obtiene un camino de contexto, este argumento, y puedes ver cómo este contexto es capaz de ser usado cuando instancias esta instancia de MyApp. Genial. Quiero mostrar primero la ejecución, invocando el CLI de Mocha Remote aquí en Node.js. Y

Sí. Volvamos a las diapositivas. Bueno. Así que, Maka era popular en 2016 cuando empezamos el proyecto Realm.js. Se podría argumentar que todavía es popular con 7 millones de descargas semanales, pero no tan popular como Jest. Y Jest es el estándar de facto en los proyectos de React Native. Y por eso también he iniciado el paquete Jest remote. Está construido alrededor de la misma arquitectura y es una buena coincidencia porque el corredor de Jest es realmente enchufable desde el CLI. Así que es posible especificar este corredor Jest remote. Y actualmente, en su forma actual, como estoy grabando esto, soporta la ejecución de las pruebas en un proceso Node separado. Pero mi visión es, por supuesto, soportar todas las otras plataformas que también soportamos con Maka Remote.

Otro competidor, o se puede decir una alternativa a Jest, que está captando mucha atención de la comunidad web de React, especialmente, es Vitest. Y de mis investigaciones iniciales y conversaciones con los mantenedores, parece que esto será una mejor coincidencia ya que también tiene un modo de navegador experimental. Así que el corredor ya está construido de una manera que es independiente de la plataforma y del runtime.

Muchas gracias por su tiempo y atención. Esto es una rareza en estos días. Y espero que esto le haya resultado útil, especialmente si usted también es un mantenedor de un paquete como este. Y si tiene alguna pregunta, no dude en preguntar. Todos mis perfiles en las redes sociales están en mi perfil de Git Nation. Además, por favor ayúdame a construir esto para Vitest o Jest si quieres hacerlo, si tienes tiempo y crees que es interesante. Te deseo la mejor de las suertes con todos tus esfuerzos. Adiós y que tengas un excelente resto de tu día