Cinco formas de aprovechar Verdaccio, tu registro privado y proxy de Node.js

Hola, gracias por unirte a mi charla. Mi nombre es Juan Picado. Estoy aquí para mostrarte cinco maneras de aprovechar Verdash para un registro privado y proxy de Node.js. Así que, comencemos.

Primero que nada, algo sobre mí. Mi nombre es Juan Picado. Soy ingeniero frontend senior en Mobility Dare, es una marca de Ativinta. Estoy basado en Berlín. Y también paso parte de mi tiempo haciendo Open Source, principalmente manteniendo el proyecto Verdash. Así que, si no lo conoces, sabrás más en los próximos 20 minutos y espero que te guste.

Así que, comencemos. Somos desarrolladores de Node.js y también desarrolladores de JavaScript. Así que, puedo imaginar que ya has publicado un paquete y si no lo has hecho aún, entonces disfrutarás esta charla porque es muy, muy sencillo hacerlo localmente. Verdash es un registro privado y proxy ligero de Node.

js, con configuración completamente opcional, que te permite simplemente alojar y publicar paquetes privados de Node.js. Y es compatible con cualquier gestor de paquetes. Así que, este diagrama aquí describe un simple viaje de una solicitud donde el registro privado siempre está en el medio entre el remoto, que puede ser uno o más. Y luego tienes un caché local. Y este caché local realmente beneficia. Quiero mostrarte cómo usarlo en tu proyecto. Así que, primero que nada, necesitas instalar Verdash.

Y para eso, necesitas instalar el paquete globalmente. Y eso es todo. Así de simple, no necesitas hacer nada más, solo comenzar. Luego, lo siguiente que tienes que hacer es simplemente ejecutar el comando Verdash. Sí, eso es todo. Así que, tienes un registro que está funcionando con una interfaz de usuario para navegar, no solo paquetes privados, sino también dependencias, incluso si son públicas. Porque Verdash, no carga ninguna solicitud de paquete a través del gestor de paquetes o la interfaz de usuario. Para ayudarte a entender he preparado cinco maneras básicas, y cómo Verdash puede ser realmente útil para cualquier desarrollador de JavaScript hoy en día. Así que, comencemos con la primera.

Que es desarrollo personal. Así que, vamos a publicar un paquete. Para este ejemplo, tengo un npm workspaces, que es bastante simple y lo veremos ahora. Y la idea es publicar algunos paquetes.

Así que, primero que nada déjame mostrarte la estructura del proyecto, que no es mucho. Solo 5 módulos. Y uno de ellos, esta es la configuración para npm workspaces, y uno de ellos tiene referencia a otros dentro. Veremos por qué estoy haciendo esto cuando publiquemos y te lo muestre en el mismo.

Así que lo primero que tienes que hacer es ejecutar Verdash. Y si quieres publicar necesitas iniciar sesión. Para eso puedes usar el comando login. Y si quieres apuntar a otro registro, entonces usa la bandera registry y la ul del registro. En este caso localhost 4873, que es el puerto predeterminado de Verdash. Inicias sesión y luego si no tienes ningún usuario solo usa lo que quieras. La contraseña y el correo electrónico no son importantes porque Verdash no los utiliza. Y luego estás conectado. Puedes ver que el servidor está reaccionando a cualquier comando que estés escribiendo. Esto es porque el gestor de paquetes es grande con la API del registro.

Así que ahora publiquemos un paquete. Y si has usado workspaces en npm puedes publicar varios paquetes al mismo tiempo solo usando estos slack workspaces. Y esto es lo que vamos a hacer y acaba de suceder. Sí, lo hicimos. Así que tenemos paquetes en el registro. Así que vamos a ver cómo se ven estos paquetes en el registro. Y esta es la interfaz de usuario. Puedes cambiar entre el modo oscuro. Y aquí tenemos los cinco paquetes. Genial. Y estas son las dependencias que te mostré antes. Así que puedes simplemente navegar a través de ellas y ver quién tiene las dependencias de quién.

Y eso es todo. Así de simple. Acabo de publicar un paquete en solo unos segundos. Sí, pero hay una restricción que debes tener en cuenta. Si publicas un paquete, un paquete privado, es decir, cuya versión no existe en ninguno de los upstreams que también llamamos Applinks, como VAC17 por ejemplo, si ya existe en el registro y Berdacho siempre buscará esta versión si ya existe y si la condición es verdadera, entonces obtendrás un error 409. Esto es bastante común si deseas parchear una versión pública, ¿verdad?

Así que para evitar esto, puedes simplemente añadir un sufijo a la versión. Y tu versión no se perderá una vez que Berdacho actualice nuevas versiones porque Berdacho fusiona lo que tienes localmente con lo que tienes de los upstreams. Así que hagamos una demostración rápida también solo para mostrarte los beneficios y cómo podemos realmente resolver esto con este paquete React. Veamos si encuentro el proyecto... Ah, aquí está. Así que aquí podemos ver esta versión, es la actual en npmjs. Ejecutemos Berdacho de nuevo. Ya estamos conectados, así que no necesitamos iniciar sesión de nuevo. Y probemos a publicar esta versión con la bandera registry. ¡Boom! ¡Sí! Conflicto de publicación. Así que para resolver esto puedes cambiar la versión manualmente, pero es mucho más fácil si usas un parche de versión. Y en este caso no estoy usando la versión de Github porque acabo de clonar este proyecto, no quiero crear una etiqueta local en mi proyecto. Así que solo ejecuto esta versión y cambiará automáticamente. Puedo ejecutarlo varias veces y puedes ver cómo la versión cambió según la anterior. Y ahora publiquemos este paquete. Solo publica y ahí está, así que si volvemos al registro de nuevo podemos ver si lo encuentro, podemos ver que la última versión es la que acabo de publicar. Si accedo a la versión de React podemos navegar a través de la versión para que pueda ver las que vienen de afuera más la que acabo de publicar. Así que continuemos con la siguiente diapositiva.

Así que publicar es fácil, pero si estás trabajando en un entorno sin conexión como yo en este video trabajando en un avión, lo cual es bastante común si estás viajando o vives en áreas remotas o no hay conexión en absoluto. Si deseas publicar paquetes, y esta es la razón por la que Vertel existe, porque puedes publicar paquetes en cualquier lugar, entonces necesitas habilitar la publicación sin conexión en la configuración. Esto no es por defecto porque las razones son porque el registro siempre busca versiones en remotos. Si no hay conexión, la publicación fallará. También puedes mejorar la experiencia sin conexión eliminando la propiedad proxy en el archivo de configuración. Puedes ver en la diapositiva. Verás más sobre esto en las siguientes diapositivas.

Puedes ver en la diapositiva. Verás más sobre esto en las siguientes diapositivas. Hay una razón para eso. A continuación está la productividad del proyecto y la integración continua en registros privados.

La mayoría de los paquetes públicos que usamos hoy en día se están publicando a través del registro privado, pero también llaman desde otros registros. Todos estos registros son servicios que requieren alta disponibilidad, pero esto no es el 100% del tiempo, porque ocurren caídas públicas, y entonces debes estar preparado para ello. En esas situaciones es cuando las capacidades de los registros privados y los proxies son una clave fundamental de tu pipeline de desarrollo. Porque tener un registro proxy entre tu pipeline y tus servicios públicos evitará que tus equipos o tus compilaciones dejen de funcionar mientras ocurre una caída.

Verdash tendrá esta capacidad de serie, almacenará en caché cualquier dependencia y versión por demanda, así que la próxima vez que se solicite servirá la que está en caché. Porque en el entorno de integración continua las compilaciones se ejecutarán múltiples veces en la misma pull request cuando realices cambios en tu repositorio, lo que implica que el manifiesto del paquete para un paquete público se descargará una y otra vez. Hay una caché predeterminada en Verdash de 2 minutos, pero puedes aumentar la caché simplemente diciendo al registro que no necesito una nueva versión cada 2 minutos, tal vez 10 minutos está bien para mí. Esta es una muy buena práctica porque acelerarás tus compilaciones ya que el registro no necesitará ir por cada solicitud afuera para preguntar si tienes nuevos cambios. Además, si la red no está funcionando bien, también puedes aumentar los fallos máximos en la configuración.

Y el tercer tema es la seguridad porque la seguridad es un tema que debe abordarse desde 2 ángulos. Primero, del lado del cliente porque necesitas usar las configuraciones correctas en el Package Manager. Puedes consultar más sobre esto en el virtualwebsite. También tengo un enlace en las 2 diapositivas adelante. Pero también desde el lado del servidor porque se plantea por sí mismo y ahora elaboraré un poco más porque hay una razón. Y si no recuerdas lo que sucedió hace 1 año, déjame recapitular rápidamente. Un investigador de seguridad descubrió que una mala configuración en los registros podría ayudar a que paquetes destinados a ser privados sean reemplazados por paquetes maliciosos, que son publicados en registros públicos con el mismo nombre. Esto podría comprometer la seguridad. Esta historia es demasiado larga, pero aquí dejo un buen artículo donde puedes leer más sobre ello. Solo es un recordatorio de que un registro es una gran ventaja y te brinda una capa extra de seguridad. Pero también es una gran responsabilidad porque debe estar correctamente configurado. Hay dos consejos reales aquí. Primero, aísla tus paquetes privados usando scopes. Usualmente es el nombre de tu empresa, de tu proyecto o de tu organización. Y también intenta registrar este nombre en registros públicos. Porque esta es una forma de tener control total. En caso de que no hayas configurado correctamente el registro localmente, al menos posees el scope afuera. La segunda razón es, especialmente si estás usando Verdacho, por favor elimina el proxy en la configuración para evitar que el registro busque fuentes externas para actualizaciones. Esto es altamente recomendable para paquetes con scope. Si tienes la intención de ser privado, especialmente si estás usando Verdacho.

Así que las últimas versiones de Verdacho, incluyen una nueva característica de seguridad, que es la limitación de tasa. En este punto, puedes agregar limitación de tasa a dos áreas, que son los endpoints web, los endpoints de seguridad, que son el inicio de sesión y el cambio de contraseña. Con eso, vas a usar la posibilidad de un ataque de denegación de servicio, que estos son puntos clave en los endpoints. Así que por defecto están realmente configurados para un número muy bajo de solicitudes, pero puedes cambiar esto. Así que recomiendo totalmente usar esta característica si no has notado que ya existe.

Así que, las pruebas de extremo a extremo, que son mis favoritas, donde la integridad de tus paquetes es cuando estás publicando un paquete y la estructura de funcionalidad de estos modelos no se ve afectada cuando es consumida por los usuarios. Hay muchas formas de romper un paquete, la más común es la configuración incorrecta, porque no importa cuán bien probado esté tu modelo. Hay algunos pasos principales cuando estás configurando para enviar un paquete que dependen de los desarrolladores, y podría ser que olvidaste agregar el campo principal si estás tratando de enviar un paquete common-JS, o tal vez olvidaste el módulo si estás tratando de usar un módulo JSON, o tal vez olvidaste los patrones correctos en la propiedad de archivo en el paquete. Además, podrías configurar incorrectamente el archivo .npm.ignore en el archivo raíz. Hay muchas cosas involucradas en el envío de un paquete, y cualquier error cuenta y puede ser detectado solo al publicar. Para eso, necesitas un registro. No puedes publicar instantáneas todo el tiempo en el público, especialmente si son paquetes privados, así que recomiendo probar publicar tus paquetes en cada pull request, al igual que un storybook está haciendo en esta diapositiva, por ejemplo.

Veamos un ejemplo, puedo romper un paquete que está destinado a ser enviado como una interfaz de línea de comandos. Aquí tengo una demostración, si quieres verla más tarde, solo imprime hola mundo en la consola, y usa github actions, docker y node js para ejecutar pequeñas pruebas de extremo a extremo. Así que, como observas, esta es una vista de mi proyecto de github, donde mis pruebas están rotas en master. Así que, veamos rápidamente cuál es la razón, y arreglémoslo en un momento. Así que, este es mi proyecto, y si ves, hay algo mal en la configuración, en el paquete. Así que, veamos por un segundo qué podría ser, y parece que es el archivo bin. Así que, este archivo no existe en la raíz, no existe. Entonces, ¿qué podemos hacer para arreglarlo? Bueno, solo usar el nombre correcto, ¿verdad? Y, realmente vamos a comprometer este archivo porque si... y esto debería realmente solucionar el problema. Así que, vamos a comprometer esto. No, no quiero romper master, quiero arreglar master. Sí, vamos a enviar estos cambios y luego mientras GitHub ejecuta la acción, te mostraré cómo estoy realmente haciendo esta prueba. Así que, si no estás familiarizado con GitHub Actions, es realmente simple, recomendaría totalmente usarlos. Aquí tenemos servicio. Servicio es una propiedad que te permite usar imágenes de docker dentro de tu acción. En este caso estoy usando la imagen de docker de Verdacio, que es la oficial. Estoy exponiendo dos puertos, quiero decir un puerto, que es el mismo. Para el S73, con esto puedes usar el registro en todos los pasos a continuación.

Así que, primero solo estoy iniciando sesión porque sí, necesitas iniciar sesión la primera vez. Luego publico el paquete. Esto es lo que cualquier usuario hará. Luego, solo verifico si el paquete está allí, lo cual es opcional. Luego solo instalo globalmente el paquete. Cuando estás instalando globalmente un paquete OGS usando VeeN, este comando estará disponible en el contexto global. Y luego ejecuto la prueba. En la prueba no tengo nada especial, solo estoy usando un proceso relajado, que usa SpanSync. Ejecutando el comando, se supone que esté disponible en el contexto global. Este será un primer punto de interrupción si no hay comando. Esta prueba va a fallar. Luego va a capturar el resultado. Y luego comparamos el resultado, si está bien, todo está bien. De lo contrario, proceso x con uno, lo que significa que GitHub fallará. Vamos a la acción de GitHub. Sí, hace dos minutos. El master arreglado está funcionando perfectamente. Si vemos la acción dentro, podemos ver que esto realmente pasó correctamente. Perfecto. Y el master está verde nuevamente. Súper bien. Así que volvamos a las diapositivas.

Hay muchos ejemplos en código abierto, y la mejor manera de aprender es un buen ejemplo es leer código abierto. Por ejemplo, puedes usar Angular CLI, que también utiliza Chill para ejecutar Verdacho. En este caso, están usando Verdacho programáticamente para ejecutar el registro, y esta también es una buena manera de hacerlo. Así que si quieres más ejemplos, solo envíame un mensaje en el chat y puedo darte más, porque tengo muchos más para compartir.

Um, porque tener tu propio registro puede ser intimidante. ¿Qué tan difícil es alojar un registro? ¿Cuánto cuesta? ¿Cuánto esfuerzo? Todas estas preguntas son comunes, y un registro necesita dos piezas fundamentales, el servidor y la interfaz de usuario, y Verdacho tiene ambos en el mismo paquete. Además, debes preguntarte, ¿qué esperas de un registro? Porque Verdacho se adapta mejor si buscas privacidad, flexibilidad, personalización, todos los entornos offline y, en general, bajo costo. Porque esto es lo que estamos haciendo en la organización Verdacho, estamos usando nuestro propio registro y nuestras compilaciones.

Hemos estado ejecutando nuestro propio registro durante tres años, lo que cuesta alrededor de $60 por año. Y tenemos miles de compilaciones cada mes, incluyendo todas las dependencias de todas estas personas que contribuyen, lo que es un montón de solicitudes al registro cada día. Y no hemos tenido la necesidad de escalar hasta ahora porque ha estado funcionando muy bien con la configuración predeterminada. Pero esta es nuestra propia configuración personal. Podrías tener diferentes requisitos, y Verdacho es flexible. Podrías necesitar un almacenamiento diferente. Por ejemplo, podrías usar S3 en Amazon Web Services o tu propia nube como Minio. Podrías necesitar tu propio proveedor de autenticación o tal vez cambiar la interfaz completamente. Verdacho también permite middleware porque es express en este punto. Este es un ejemplo. Estoy usando MPM Audit. Estamos aplicando usando plugins dando soporte a este comando. Así que podrías querer extender tu propio registro. Pero sí, esto también podría incluir desarrollo personal, creando tus propios plugins.

Así que sí, eso es todo de mi parte. Muchas gracias por escuchar mi charla. Verdacho es un registro de código abierto hecho para desarrolladores y hecho para colaboradores, lo que hace que este proyecto sea una gran alternativa. Y así, en nombre de todos los colaboradores, gracias por ver mi charla. Y espero que te haya gustado y hayas aprendido algo hoy. Por favor, no dudes en hacer más preguntas o contribuir al código abierto. Así que muchas gracias. Adiós.

Al observar los resultados del pool, ¿qué piensas? Así que un tercio de todos los asistentes, bueno, se preocupan por alojar un registro, pero también hay muchas respuestas interesantes como la seguridad. ¿Qué piensas sobre eso? De hecho, miré los resultados, coincide con mis expectativas. Por lo general, sí, el nombre de la descripción del proyecto indica, sí, puedes alojar un registro. Este es el caso de uso más común. Pero tiene varios, como mencioné en el libro. Y las pruebas Antoine son una tendencia, que se está volviendo popular. Viste en la presentación, mencioné algunos proyectos, pero veo muchos, muchos proyectos, que tienen monolibos, que se preocupan por lo que están enviando. Las pruebas Antoine son algo importante. La seguridad, sí. El año pasado fue un año importante para los registros y la seguridad. Y el proyecto fue bifurcado para otro, que estaba más destinado a ser para desarrollo personal. Este es quizás el menos conocido. Puedes usar un registro en tu computadora. Y lo que me sorprende es la integración continua, porque como mencioné, una de las diapositivas generalmente no se usa. Confiamos mucho en los servicios y esto es peligroso. Así que sí, eso es bastante genial. Gracias.

Bueno, tenemos algunas preguntas, si no te importa. En primer lugar, esta es también mi pregunta, y creo que está en la mente de muchas personas. ¿Cuál es la mejor manera de contribuir a Vodaccio? ¿Cuál es la mejor manera de involucrarse? Bueno, solo la disposición de aprender. Esa es la más importante. Así es como comencé en Vodaccio. Sí, quiero aprender Node.js y en el repositorio, tenemos varias formas en las que puedes ayudar. Primero, si eres solo un principiante, puedes comenzar corrigiendo tipos que estamos migrando. Tenemos nuestra hoja de ruta en el repositorio, que está fijada, y puedes encontrarla fácilmente en los problemas y discusiones. Y hay una descripción de lo que puedes hacer. Ya sea que seas un desarrollador de Node.js puramente y quieras aprender algo o mejorar el código, tienes los pasos para hacerlo. Si te gusta más el front-end, tenemos una UI, que está basada en React, y Material UI, que también necesita algo de ayuda allí. Y sí, puedes tener buenas características. Y si no eres un programador, tal vez quieras ayudar con las traducciones.

Además, puedes ayudar a traducir el software a varios idiomas. Ya tenemos como 15 idiomas en la UI y también en la documentación. Y sí, también puedes ir al chat y ayudar a otros a usar Bellagio. Esa es otra manera. Muchas gracias. Eso es muy genial.

Otra pregunta es, ¿puede Verdacio usarse para hacer proxy no solo de uno, sino de múltiples registros? Sí. Cuando usas Verdacio por primera vez y estás instalando paquetes a través de él, sí, los paquetes no llegan mágicamente. Vienen del registro público, pero puedes usar varios. Quiero decir, imagina que tienes otro registro en tu empresa y quieres obtener los paquetes de allí y del público del público. Así que puedes configurar uno o más. No hay límite. Quiero decir, creo que el límite es el cielo o en este caso tu hardware. Y si es privado, puedes usar credenciales para acceder, en tu corporación puedes configurar credenciales y acceder a varios registros. Hay una de las características que no es muy conocida. Es como si pudieras definir un paquete específico, por ejemplo, React. Imaginemos. Y puedes pedir React en tu registro privado. Y puedes definir una regla, como, está bien, si no existe en el privado, entonces lo encontraré en el otro. Y puedes crear esta combinación, que es realmente agradable. Y, sí, es totalmente, totalmente posible. Eso es realmente agradable.

Bueno, otra pregunta que tenía es que estoy seguro de que otros podrían estar familiarizados con otras iniciativas para crear repositorios no-npm. Un ejemplo sería Entropec, del cual la gente podría estar al tanto. ¿Cómo crees que Vodaccio se compara o tal vez se diferencia de esos proyectos? ¿Cuál? ¿El Entropec que mencionaste? Sí, Entropec. ¿O hay tal vez algunos otros proyectos de los que estés al tanto que crees que son diferentes? No hay muchos en código abierto, desafortunadamente. Me gustaría ver más. Pero la mayoría de estos, Entropec fue una idea que todavía está abierta, pero parece que no hay mucho desarrollo. Pero fue una idea para crear un registro, un registro distribuido. Sí, así que desafortunadamente no hay mucho desarrollo allí, pero la idea era interesante.

Y aparte de eso, solo hay servicios. Hay algunas empresas que están creando registros, posibilidades para paquetes privados. Pero sí, quiero decir que necesitas pagar por ellos. Algunos tienen una prueba gratuita, que puedes usar. Pero la principal diferencia es que, aún son todos servicios, ¿verdad? Entonces necesitas internet y básicamente necesitas internet y puedo decirte, usualmente la gente se acerca a mí para preguntarme como, oh, vivo en esta área o vivo en este país, que no está permitido usar el servicio o lo que sea. Y mi única forma de aprender Node.js es porque puedo instalarlo en mi computadora y simplemente usarlo. Esto es interesante para mí. Sí, eso es realmente interesante. De hecho. Eso Furtaccio puede ser utilizado como una herramienta contra los cortes de internet o eventos similares. Otra cosa. Entonces, cuando hablamos sobre el caso del repositorio privado, creo que nos enfocamos mucho en la fiabilidad y el almacenamiento en caché y así sucesivamente. Pero por supuesto, hay otra forma de trabajar con un repositorio privado donde puedes tener un repositorio privado dentro de tu empresa donde has publicado exclusivamente tu código privado y luego puedes construir a partir de eso. ¿Permite Furtaccio esto? ¿Hay muchos usuarios de esto? ¿Qué piensas? ¿Te refieres a alojar un registro dentro de tu empresa? Sí, y alojar paquetes locales de código cerrado por así decirlo, para que no tengas que importarlos usando enlaces Git y así sucesivamente, y en su lugar puedes simplemente clonar en tu privado... Furtaccio solo admite dependencias con versionado semántico, por lo que no... Quiero decir no puedes descargar un repositorio Git o algo así. Esto no funciona. Hay otras soluciones como en package.com creo. Es como un registro pero es como un CDN. He recibido solicitudes de personas pero esto no es lo que hace Furtaccio. Sí, quiero decir que puedes tener tu registro dentro de tu empresa ya sea para almacenamiento en caché o para alojar tus privados, por ejemplo, como un sistema de diseño que no quieres publicar fuera y usualmente tienes este tipo de cosas que puedes usar en varios proyectos. Entonces necesitas el registro de alguna manera porque necesitas publicar paquetes allí. Okay, eso fue genial, muchas gracias Juan. Fue un placer escuchar tu charla y fue aún más interesante interactuar contigo. Bueno, desafortunadamente nos hemos quedado sin tiempo pero si aún no has terminado de escuchar sobre Portacio puedes unirte a la sala de chat especial. Entonces Juan, ¿estarás en el chat especial, verdad? Claro, lo estaré. Okay, genial. Bueno, en ese caso puedes unirte allí y podemos pasar a la siguiente parte. Gracias. Fue realmente agradable tenerte. Muchas gracias. Muchas gracias. Gracias por tenerme aquí.