Cuando Raspberry Pi Dijo No a Node: Cómo Reconfiguramos Nuestra App de Next.js

Hola a todos. Bienvenidos a la sesión donde voy a hablar sobre una historia, de hecho, es una sesión de narración más que una sesión técnica. Voy a hablar sobre cómo tuvimos que reconfigurar nuestra aplicación Nexus cuando nos encontramos con una restricción de un cliente. Así que, de eso se trata, esta. Pero junto con la historia, voy a traer ciertos aspectos tecnológicos porque sin eso, la historia estaría incompleta.

Así que, para empezar, comencemos con una historia de rechazo inesperado. Así que, a diferencia de la mayoría de las veces, comencemos esta presentación con una historia de rechazo inesperado. Y la historia es así. Solo imagina esto en tu mente, como a las 2 AM, y acabamos de terminar de desplegar nuestra nueva aplicación Nexus para un cliente de EV. Y luego la aplicación se ve realmente impresionante. Es un hermoso panel, rastrea datos de batería en tiempo real, funciona perfectamente en producción, como el entorno que habíamos probado. Todo estaba tan bien.

Pero, ¿qué pasó a la mañana siguiente? Recibimos una llamada del cliente diciendo que esta aplicación tiene que funcionar en Raspberry Pi y no hay Node.js. No es que Raspberry Pi no soporte Node.js, pero este cliente en particular no estaba interesado en usar Node.js porque ya tenían un servidor propietario un servidor web, un servidor de aplicaciones, donde una aplicación web puede ser alojada y puede funcionar fácilmente. Así que pensaron que Node.js sería un equipaje extra. No optemos por este. Pero cuando escuchamos esto, fue como, sin Node.js, no hay fiesta, porque todo fue construido con la suposición de que Node.js estaría allí.

Así que, hola, soy Tapas. Soy un desarrollador full stack Lo llamo una pila de demanda porque después de pasar un par de décadas con la ingeniería de software, desarrollo de software, me siento libre de ir a través de diferentes tecnologías. Tengo una startup llamada Creobase Technologies y una comunidad de código abierto llamada React Play, que también fue premiada como, lo sé, una de las mejores comunidades de código abierto de React en el anterior React Summit. Soy educador en TapaScript. Ese es mi canal de YouTube también. El handle está ahí. Puedes echarle un vistazo. Escribo blogs, blogs técnicos en Free Code Camp y también soy un entusiasta del código abierto. Así que, eso es sobre mí. Muy bien. Así que, hablamos sobre el rechazo inesperado, ¿verdad? Esta charla es principalmente sobre lo que sucedió después del rechazo. Cómo reconfiguramos nuestra aplicación del día siguiente para funcionar en un hardware restringido sin Node.

Al mismo tiempo, qué tipo de lección de rendimiento aprendimos, cómo nos aseguramos de que el rendimiento no se degrade, y qué nos hizo replantearnos cómo debería construirse una aplicación de React, ¿verdad? Así que, voy a hablar sobre la arquitectura inicial con la que comenzamos, luego el problema que enfrentamos porque se eliminó Node.JS, luego nuestra fase de investigación, y luego cómo reconfiguramos toda la aplicación. Concluiré esta presentación con las lecciones que he aprendido. Una cosa, sin embargo, importante mencionar, en todo el curso de hacer esto, este código es algo que sentimos como muy cierto. Sabes, cada proyecto es una oportunidad para aprender, para identificar los problemas, desafíos, e inventar y reinventar. Es tan cierto. Bien. Así que, comencemos con la arquitectura, la arquitectura inicial.

La arquitectura inicial es así. Entonces, esta es una aplicación de gestión de baterías para vehículos eléctricos. Obtenía la matriz de datos, la matriz de baterías, básicamente de sensores IoT, ya sabes, y luego procesaba los datos a través de APIs. Y desde la capa de API, podíamos visualizarlo con gráficos interactivos, paneles, etc. Muy simple. Y la aplicación fue construida con NixJS AppRouter. En ese momento era 14, y luego migramos a 15 más adelante. D3JS para todo tipo de visualizaciones, y por supuesto, almacenamiento en caché en el borde por razones de rendimiento. Y como sabes, si eres un desarrollador de NixJS y amante de NixJS, sabes que hay cosas como componentes del servidor, SSR, ISR, todas estas técnicas que incorporas.

Está el poder de usar NixJS como un marco. Y haces que tu aplicación sea súper eficiente. Te ocupas del SEO. Te ocupas de muchas otras cosas que una aplicación ideal le gustaría ver en sí misma. Pero asumimos una cosa, sabes, asumimos que habrá NixJS. Pero lo que resulta es que cuando despliegas en un hardware embebido como Raspberry Pi, esta suposición particular puede romperse muy, muy fácilmente. Eso es exactamente lo que nos pasó, ¿de acuerdo? Ahora, en la siguiente sección, voy a hablar sobre cuál fue el problema con NodeJS.

Entonces, cuando escuchaste que NodeJS no está presente, y hemos construido toda la aplicación, teniendo en cuenta que NodeJS estará presente, y gran parte del poder del marco NixJS que hemos incorporado en esta aplicación, ¿qué tipo de problema comenzamos a enfrentar o comenzamos a delinear donde NodeJS no estaba presente? Como desarrollador, cuando comenzamos entre cosas como SSR, como renderizado del lado del servidor, el sueño del renderizado del lado del servidor, y las realidades del hardware, lo que descubrimos, como, NixJS espera un servidor para que las cosas funcionen. Y el tipo de servidor que el cliente nos dio, básicamente quería archivos estáticos. Entonces, desde el sueño de usar SSR, ISR, y todas estas cosas, al hecho de que tenemos que usar cosas como archivos estáticos, algunas personas dirán, como, de los 90, ya sabes, solo tienes HTML, CSS, JavaScript, ya no tienes todas estas cosas elegantes del marco, eso fue, como, un poco desalentador para un equipo técnico como nosotros, que siempre quiere trabajar en algunas tecnologías modernas y todo. Así que descubrimos que las restricciones son básicamente estas, sin tiempo de ejecución de Node, memoria limitada, este es el segundo punto. Estábamos pensando que iría a la nube, se ejecutaría en, como, ya sabes, edge, las cosas serían súper buenas, pero ahora es un hardware pequeño, por lo que tienes la limitación de memoria, y también el cliente regresó con otra cosa, como, tienes que hacerlo, ya sabes, offline, por lo que debería servirse offline. Puede que no obtenga los datos más recientes cuando se sirve offline, pero por supuesto, no debería romperse, no debería ser una pantalla en blanco cuando alguien accede a esta aplicación en su iPad o en algún lugar. Así que nuestra aplicación NixJS de repente no podía renderizar páginas, porque no hay Node.js, no podía ejecutar las rutas de API no hay Node.js, y luego los gráficos D3 que hemos desarrollado, comenzaron a ahogarse, porque no hay concepto de aceleración de GPU, estás usando este hardware, no hay APIs de transmisión, estábamos soñando con usarlas, y eso comenzó a crear muchas restricciones para nosotros. Así que como entendimos, bien, esta es la vida de esta aplicación, la vida de los desarrolladores sin Node.js, comencemos la investigación.

Así que comenzamos la investigación, y hay dos cosas, dos caminos que nos dimos cuenta que están frente a nosotros. Uno, reescribir todo lo que hemos escrito en modo React spa puro, modo de aplicación de una sola página, sin más marco, porque el poder de NixJS en sí, no podemos usarlo, ¿verdad?, entonces, ¿cuál es el uso de usar el marco? Así que deshagámonos de eso. Segunda cosa, de alguna manera hacer que NixJS se comporte estáticamente. Bien, hemos pasado nuestro tiempo arduamente ganado, ya sabes, meses construyendo componentes del servidor, diseños, APIs basadas en varias características de Node, ¿qué hacer, deberíamos desechar y reescribir? Decidimos, bien, no desechemos la implementación que hemos hecho, intentemos desglosar NixJS. Descubramos qué partes de NixJS realmente necesitan Node.

js, y si podemos descubrir eso, tal vez esa parte necesite alguna reescritura, pero otra parte podemos mantenerla tal como está, porque también tenemos que entregar al cliente, y hasta cierto punto, admito que este fue nuestro error, probablemente no entendimos la comunicación de dónde exactamente esta aplicación va a ejecutarse, y esa es una de las lecciones que quiero mencionar hacia el final, así que realmente no puedo pedir demasiado tiempo extra al cliente para que tenga que reescribir esta aplicación, ¿verdad? Así que a continuación, investiguemos y hagamos algunos hallazgos, ¿verdad?, qué parte de NixJS realmente necesita Node.js. Así que aquí están los hallazgos. Voy a repasarlos uno por uno muy lentamente. Lo que descubrimos, el SSR, renderizado del lado del servidor, y habíamos escrito algunas rutas de API, esas están vinculadas a Node, porque necesitas Node.js para hacerlas funcionar, alojarlas, etc. La parte de la interfaz de usuario, donde se trata del componente, básicamente, ¿podemos exportar este componente como exportaciones HTML? Si podemos hacer eso, significa que al final del día, es solo un simple HTML, lógica en JavaScript, y toda la embellecimiento está en el estilo, y eso se exporta, que puedes llevarlo portátil a cualquier parte del mundo, en cualquier servidor, cualquier servidor de aplicaciones. Así que eso es bueno. Así que significa que si puedes exportar estáticamente la interfaz de usuario, creo que esa parte no está dependiente de Node o del servidor basado en Node, genial. Luego los componentes del cliente, teníamos un sueño de usar componentes del servidor porque desde NixJS, 14, AppRouter, y luego 15, los componentes del servidor están en todas partes, ¿verdad? Se vende a todos los desarrolladores. Pero como desarrollador, creo que siempre tenemos la tendencia de mirar esa pieza brillante y resplandeciente, luego poner demasiado nuestros pensamientos en si esa cosa brillante es para mí, ¿realmente lo necesitamos? Así que si miras esta aplicación, la persona de esa aplicación es alguien que va a revisar muchos vehículos eléctricos, quieren conectar un dispositivo, un hardware a la batería, quieren recopilar los datos, y en el iPad, quieren ver ciertas cosas y tomar algunas decisiones. Esa es la persona. Ahora, esta persona nunca va a usar esta aplicación públicamente. No es algo que en una búsqueda de Google deberías obtener esta aplicación, ¿verdad? Es una aplicación muy privada. Así que el SEO no es en absoluto un asunto aquí, ¿verdad? ¿Por qué estábamos pensando en componentes del servidor, renderizado del lado del servidor y todas estas cosas si el SEO no está en absoluto en la imagen? En realidad, podemos traer esta aplicación completamente del lado del servidor al componente del cliente. Y eso funciona en todas partes.

Después de un cierto período, los datos deberían refrescarse, y los usuarios deberían poder ver los datos más recientes en la aplicación. Así es como estábamos usando ISR en el XJS incorporado. Ahora, si Node.js no está presente, ISR es complicado. Pero, ¿podemos reemplazarlo? Sí, es reemplazable. Es reemplazable con la tecnología antigua. Vamos a hablar de eso. Así que con todos estos hallazgos, sentimos, vamos a lo estático, pero de una manera inteligente. Bien, eso nos lleva a reescribir toda esta aplicación donde podemos usar la mezcla de la exportación estática de Next.js sin deshacernos de Next.js y el tiempo de ejecución ligero del navegador. Bien, ahora voy a hablar sobre varios pasos que tomamos y asegurarnos de que esta aplicación se entregó con las restricciones que se nos dieron. Era como, ya sabes, estábamos engañando a Next.js para que pensara que estaba ejecutando un SSR, pero solo se horneaba y refrescaba localmente. Eso es lo que hicimos.

Bien, los pasos son así. Lo primero, deberíamos tener vistas pre-renderizadas con la capacidad de exportación de Next.js. Así que cuando usamos la exportación de Next.js, lo que hace básicamente, no va a hacer los artefactos de construcción o la salida de la manera tradicional del entorno de Node.js. Va a hacer la exportación estática de tu HTML, CSS, JavaScript de tal manera que en una versión más antigua de un servidor, servidor no-Node, por ejemplo, Tomcat, o el tipo de servidor que tenía nuestro cliente, puedes alojar fácilmente tu aplicación, porque simplemente es HTML, JavaScript y CSS. No hay nada como, que esté muy vinculado con Next.js o Node.js allí en el artefacto de construcción. Así que esa fue la primera configuración que habilitamos.

Primer paso. Segundo paso que hicimos, teníamos muchas APIs escritas usando las rutas API de Next.js, y como Node.js no está presente, tuvimos problemas para alojarlas. Así que pensamos, bien, hagamos muchas llamadas en el lado del cliente. Así que desde el lado del servidor, comencemos a empujar las cosas en el lado del cliente usando la llamada fetch espejo. Así que si puedes ver esta diapositiva, puedes ver que hay ciertas secciones donde estamos haciendo ese fetch, y hay una URL de datos, voy a eso, qué es esa URL de datos, y vamos a obtener los datos y mostrarlos. Así que no hay renderizado del lado del servidor, no hay componente del servidor, componente puro del cliente, haz una llamada fetch a algo que no está alojado en remoto. Más bien, los datos son bastante locales. Así que obtén un volcado de datos JSON periódico de tus dispositivos de hardware, para que podamos renderizar eso en D3. El volcado de datos se ve así. Es una marca de tiempo, cuál es la carga, cuál es la temperatura, diferentes tipos de estadísticas allí, y almacena esos datos localmente con IndexedDB. Así que IndexedDB es algo que está en tu navegador, ¿verdad? Y si podemos almacenar cosas en IndexedDB, podemos realmente dar un gran impulso en el rendimiento. Así que cada vez que obtenemos un dato, podemos ponerlo en IndexedDB, de manera periódica, y luego servir los datos a la UI desde allí.

Así que nos aseguramos de que las cosas sean bastante más rápidas, porque todo se carga en el navegador sin problemas. Y luego, la última parte, la parte de ISR, la engañamos usando un script cron. Entonces, lo que sucedía desde el sensor, que estaba conectado al dispositivo EV, solía obtener los datos, y con una frecuencia, era un script de Python, en una frecuencia cron, solía volcar el JSON en una ubicación. Solíamos recoger el JSON, identificar cuál es el último dato JSON que llegó para que D3 lo muestre, y esa es la llamada fetch que solía obtener los datos JSON, y luego se los mostramos al usuario. Así que todo el asunto, que era como muy basado en Next.js, muy basado en Node.js, tuvimos que reconfigurarlo para asegurarnos de que funcione en esa limitación o hardware limitado que se nos dio. Hay momentos en los que realmente no puedes ir a lo sofisticado. Tienes que recurrir a algo que podría ser muy mínimo, que podría no parecer la mejor práctica, pero algo en ese particular entorno, probablemente lo mejor que se puede hacer. Así que cuando lo ejecutamos por primera vez, ¿qué pasó? Fue muy rápido. Inicialmente, con Next.js, Node.js, ese entorno, lo estábamos poniendo en la nube, ya sabes, la edad, tomaba como un segundo, unos pocos segundos, no un par de segundos, menos que eso. Pero ahora todo es local. Así que toma alrededor de 500 milisegundos desde el momento en que podemos obtener los datos del hardware. En el momento en que obtenemos los datos, todo es muy local, ¿verdad? Como era local, no hay saltos de servidor, no hay retraso de hidratación. Todo esto se ha ido completamente. Así que en realidad, lo que pasó, la ironía aquí es que Raspberry Pi dijo no a Node.js, básicamente dijo nuestro cliente. Pero terminamos teniendo algo que es mucho más eficiente, mucho más rápido, y los clientes estaban contentos. Así que fue un descubrimiento accidental, diría yo, que ir a lo estático puede ser más inteligente que lo dinámico cuando tienes cierta creatividad en juego que puedes aportar. Y en este caso, creo que eso fue lo que funcionó. Así que esto es lo que habíamos hecho a un nivel muy alto.

Y si quieres profundizar más sobre esto, te dejaré algunos de mis enlaces sociales. Siempre puedes contactarme. Podemos discutir más sobre en profundidad cómo sucedió todo en la capa. Así que la lección que aprendimos a un alto nivel, quiero mencionarlas. El renderizado del lado del servidor, excelente cosa, una cosa sofisticada con React, hace de esto un framework. Pero eso puede no ser siempre la respuesta. Como dije, como desarrolladores, tendemos a hacer esto mucho. Tendemos a usar esto mucho porque el framework nos lo da. Pero no te dejes llevar ciegamente por lo que funciona para la mayoría. A veces lo que pasa, la edad o lo estático también gana, de la manera que hemos visto aquí. Aunque esos son los casos menos utilizados. Esa es la primera cosa.

Segundo es pensar a nivel de hardware. Antes de este proyecto, francamente, mi mentalidad, la mentalidad de mi equipo no era esta. Nunca diseñábamos nuestra aplicación para limitaciones. Pero después de este incidente, comenzamos a pensar que deberíamos diseñar para limitaciones, no para las nubes. Así que piensa en las probabilidades mientras piensas en todas las partes felices que pensaste para tu producto o la aplicación que estás desarrollando.

Y tercero es entender muy bien tus herramientas y frameworks, muy profundamente, para que en una situación como esta, no abandones abruptamente o renuncies a tu framework y te vayas a otra cosa porque estás enfrentando una limitación. Estando en el framework mismo, puedes ajustar muchas cosas si sabes cómo funciona en su base. Así que, esta no fue una historia solo sobre el Raspberry Pi, para ser muy franco. Esta fue la historia de nuestra adaptabilidad. Y como desarrollador, como equipo, nos adaptamos muy bien.

Así que si estás usando una aplicación XS y si te encuentras con cosas como esta, solo ten en cuenta que puedes hacer las cosas mucho, mucho más portátiles. Es muy posible. Así que, gracias. Y si alguna vez estás depurando algunas de estas cosas o teniendo un problema de caché, como lo tuvimos en 2M, recuerda que siempre hay algo peor que eso, que enfrentamos en el último momento, donde no había servidor Node.js en Raspberry Pi, pero aún así pudimos lograrlo. Así que tú también puedes hacerlo. Con eso, terminaré esta presentación. Por favor mantente conectado y puedes conectarte conmigo en LinkedIn y varios otros lugares. Como mencioné, he dado esto como una visión muy, muy general. Pero en caso de que quieras profundizar conmigo entendiendo cada una de estas capas, siempre estoy abierto. Definitivamente puedo hablar más y tal vez haya más ideas mejores que surgirán cuando estemos discutiendo juntos. Así que con eso, muchas gracias.