 Hi, thanks for joining my talk. I'm really, really glad to meet you, Bertali, and today I will talk about and cover your projects with a multi-propose live with Node.js registry. But the first start, please allow me to introduce myself, but let's run this comment first. Perfect. My name is Juan. I'm from Spain, but with strong roots from Nicaragua. I'm a senior front-end engineer at eBay, and I lived since one year ago in Berlin and previously in Austria for a few years. I'm the lead maintainer of the Bertali project. I'm really love open source, especially Node.js. So today I'm going to talk about a topic I'm really, really passionate about using a registry with Node.js. So at the end of this talk, you have to learn the role of the registry in your project, a small introduction to Berdasho, and all the benefits of having a perfect registry in combination with your project. So before we go to the main topic and features, I want to define one of the main ideas I'm going to mention today, the registry. So when we are installing our packages, this is the picture we have the most of us in our mind. A slow and heavy process we are forced to execute in order to achieve our goal to build or ruin a project. But independently of the package manager of your taste, those are only one part of the effort to build a project. The other part files instead of the responsibility of the registry. So what is a registry and why we should care about it? A simple definition of a registry is a repository of packages composed of tar balls made of data, also known as Sparkment, which stores and tracks the version of a package. Technically, it's more complex than this definition, but this is good enough for the purpose of this talk. So what's the role of the registry in your app? The package manager needs information to calculate the dependencies in your project. This information comes from the registry. But without a registry in the other side, the package manager, it does not match to do by itself. So the registry must have high reliability. Otherwise, you are a totally block. The registry is in the middle of the critical path of building your app. So a new solution is having a server registry in the middle to back you up. So we're actually alive with open source proxy and private registry built in OGS. And today, we'll add a new adjective, multi-propose. What this multi-propose means, the principal reason for using Verdatio is for hosting private packages. But also, it has the ability to fetch for multiple registries. But while Verdatio proxy to external registries also holds a copy of every package and persisting a copy of data for future request. Also, you can emulate real testing. This is the newest one. And I want to emphasize here, it's a complement rather a tool itself. So before we delve into what Verdatio is and how to use it, it's worth learning more about the problem domain itself and the fact that our apps must lie on external services 100% is the main issue. Services might fail. And if you need additional features, also you need to wait for it. Our apps should be able to run and deploy without external interference and reduce the scope of the failure to internal domain rather external reasons. Portability is also a big problem for other solutions. Verdatio is small enough to be a dependency. And in any of your projects that provide an interesting set of opportunities like we are going to see later. Getting started with Verdatio is really straightforward. Just install the package globally and run Verdatio command. Verdatio is so small and that can be combined with MPX command. And the default configuration is more than enough. But for the most of these cases, but also it's based in Jamon. Here I'm using MPM for simplicity, but any other package manager works fine. Verdatio has an official image and also a health official chart. And this is the way that actually you can actually you can use with Docker. The unique argument you need to use here is the port. But also you can extend it with other Docker features like volumes and so on. The next step is configuration custom registry. And there are actually three ways. The first one is the faster way which you can use the registry flag. And this works per command. The second one is set the registry property at the MPM RC file. And this is the most common way and recognized by other package managers. And also you can host in your operating system home directly as a global or in the root of your project. In the package Jamon, also you can define the publish config property. And this way you can ensure you are publishing to the specific registry. And this one cannot be overruled by any of the previous options. One personal recommendation is NRM. This tool is really handy. And actually this one works only globally. But also it has a nice allies when you can switch with the registries or to try. Hosting a private package registry is a must to have in combination with your projects. And there is many reasons for it. Security by far is the most important one. And it acts as a firewall to avoid leaks to public registries. And privacy perhaps is the most valuable one. And the fact that nobody can see your code, it's spiceless. Also you can have an offline experience for those who travel or work remotely in areas which network issues, conferences, airports, coffees, etc. And your project will feel even if any outage happens. Relature is free. And it's open source. So this is being translated to reduced cost. If you're an independent developer or a smaller startup, hosting a private package, a private registry never was easy and cheap because I didn't have to pay any monthly fees. For those who are learning Node.js, teach Node.js is hard if you cannot use a registry. NPMGS is not made for that scenario. For instance, you can spam it with fake names or use offline. Staging a registry is the best reason to host in one. Because having a hosted stage in registry is maybe the best decision you can take. And you might have, you might have the need to publish a snapshot or calendar releases that need to be hosted somewhere, to be consumed by other parts of your app. And a private registry in those scenarios became crucial. And it's a huge advantage for several reasons. Hosted within your network make packages much easier to override. And also projects in development can leak sensitive information if you are doing some snapshot publishing in private registries. And even if you're using private features. So in this picture we can observe how at Verdas we use a staging registry to deploy calendar versions per request. And for instance, I created a custom GitHub actions and that create a command in the request after publish on my staging server. If we dive into the action, I can extract relevant information from the GitHub context API and invoke the MPM version with some specific special arguments like no GitHub version which actually avoids to create a GitHub and also create which also allows you to define a specific ID for your release. So the final result looks like this. Because having a staging registry from a project makes much easier to anyone to try out right away the calendar version after the build finish. And this is just an example of how you can combine tooling with your private registry. When does a staging registry make sense? For instance, if you are doing continuous delivery which teams produce so forth in short cycles and apps need to be built regularly and having a streaming registry will allow you to create fast snapshots and also faster builds if you catch properly. There are mono repositories that can rapidly growth for several amount of models and relationships within apps. But for instance, if you have a design system which is being used across all of your orientation. When you need to batch a library, if one of your dependencies has a back and you know how to fix it, on the official batch never arrives, sounds familiar right? Let's see an example. For instance, you can publish a batch version to your private registry and use it while the real batch arrives. But that should merge the remote versions with the private versions. And all you need to do is just change the version interpret where the real batch is being published. And now let me give you an example how a small registry is handy to cover an app for teaching Node.js. Workshoper is an organization built around the Node.js platform and has roots within old school. This organization exists, you need the effort of the creation of open source learning material. And how do NPM collect my attention when I notice they were mocking a registry for teaching purposes? So you can learn how to use NPM and for a few common actually requires a registry, like NPM publish or NPM login. So why don't you integrate a real one which can be used offline anywhere? So I decided to open up a request and integrate Verdasho. Now the app can actually focus on teaching and let Verdasho to handle itself the registry features. So thankfully this idea was very welcome. And this is just an idea how you can use a private registry for teaching. So all we know, all we know the public registry is the order of registries where all our private packages projects are hosted by the phone. But there is not only one and you might have more than one in your organization. And thus a registry should be able to access multiple registries with the best developer experience. Proxies are gateways between you and internet. And Verdasho can proxy between an old package manager and any other registry with a seamless integration. Let's see. So you might have seen before in a project. And this is the way that NPM provides accessing to multiple registries via NPM RCI. But this comes with a few disadvantages like user experience or security. So to keep this on sync, scopes might be hard if your team has a considerable size. And few of your developers even might be tempted to leak accidentally password or tokens to the public repositories by mistake. And also it looks pretty chaotic. So Verdasho has a feature named uplinked that allows you to centralize all the configuration in a config file. You can configure, set up security headers and release developers for responsibility to keep this on sync. Verdasho supports multiple ways to set your tokens, locations, and any other node registry can be hooked here. So after defining the uplinks, also you can define for each package pattern to be fetched for specific remote or multiple ones. And that's all. And Verdasho will look out for the remote or for less for your developers. If you combine these with another private hosted registry, you will have only one single endpoint for all your registries. Catching means placing something in storage on the chance it might come in use of later. And being able to catch packages, it's something that the package manager does actually locally, really locally. But why don't do it at the level of your app? So why we should care about catch? And I will refresh this. And why could not happen? For instance, a missing library broke in the internet like left a few years ago. Also, this might happen also in your local environment. MPMGS having a tough day because you cannot install packages. Or intermediary are working in the internet again, like growth for this year. Or you're just stuck between your cable. Anything can happen. And you must be covered for all these scenarios. So catch is the key. And catching dependencies will save the stop of your work in your project. And catcher dependencies locally is not enough. And they can be clearly denied and they're gone. So Verdasho cast by demand and keep the latest track of all your versions, private ones, and from remote, other remote registries. And the folder that contains the cache is just a folder and that can be relocated or copied to another computer. Furthermore, the cache is backward compatible for easy upgrades. Continuation integration is part of the lifecycle of your app. And all we want those to be green. To maximize the chances of success, I recommend to put a private registry catching by demand all your advantages. And which will avoid false positive do a network or service outages. You will have better consistency in your app, faster builds with a closed location within your registry and your continuous integration server. Also, I will emphasize here to use a log file. And if you have an app, it might be not required if you're in the case you are building modules and you prefer your semantic version in place. But in any case, I also recommend to pin your dependencies, which will help to the package manager request new updates through history so often. Using Verdasho, you could apply an extra optimization. For instance, increasing the match age of your cache. This will avoid to offer a request to the more registries speeding up the build. Another usage is emulating real testing. Entwine testing is a technique used for tests whether the entire application flow behaves as expected from start to finish. Speaking in Node.js means that the package should be tested exactly as we expect to be consumed with real life tooling without mocking stuff. With a real package manager, a real registry. For instance, many Node.js models are CLIs, command line interfaces, like web CLI, Angular CLI, and so on. So those can be only tested via human interaction and only with Entwine testing, you can have a feeling of real testing. So how to test a package with Verdasho in a test runner? First of all, you need a real package manager. Any of them. Second step, you need to publish the package to the registry. And then in this case, Verdasho, because the appendix is quite easy to integrate. And the third step is run the test. In this case, we are going to use just. So here we have an example. You can see the source code in the Verdasho organization. I created a small CLI which actually only calculate the area and require two arguments, wave and hang. So first of all, you need to fork the registry using the model chili process. In combination with the required Verdasho as dependency with a few arguments, like the location of your config file in the book model. You only need to wait, you need to wait the message when the registry has booted, and then you can grab this in a promise and then await it and just do it in the before or in the first section. And just as simple. Second step will be publishing your package to Verdasho. For this, we can use exit file from chill process again to execute an external application. In this case, NPM. And here we are using a registry flag publishing to our registry. The first step is install the CLI and a specific location using specific arguments like the registry that we want to fetch and the prefix where I decide where I want to install my package. In this case, I will do it in the temporary folder. The last step is running the CLI from my previous location. And I'm using exit file again, but in this step, I want to know the output. So I do return STD out and I watch my expectations after that. And don't forget to kill the registry after you finish all your tests. Verdasho supports plugins. And on this specific scenario, I'm using storage in memory, which is the objective to run my tests faster. Another level is authentication. Here I'm installing a second plugin and having all the expensive tasks running in memory will help you to run the tests faster. Everybody has a particular setup. And in open source, you can find many users in Verdasho. For instance, I would totally recommend you check out this project and see how their setup looks like. It's really simple and it's based in Dash. Well, we are near the end of this talk, but two more things before we finish. I will highlight from this quote a small part of the tweet from Mateo Collina about this topic. Having a previous registry should be in standard. As you have seen, a registry is an important piece of a critical path of building your app. And I hope after this talk, you have a different vision of how to get registries. Later summary, a previous registry gives you more flexibility and being able to automate tasks or just for development purposes. Keep all the configuration in the server side. Don't put unnecessary waste in the developer's shoulders. Cash or the things with a previous registry. And don't block your team from building their apps. Start testing your packages and ship confidence before it's too late. So that's all. Thank you so much. You can find more documentation in the Verdasho website. Also, you can reach me out via Twitter or the developer or just follow me on GitHub, under Avicado. I'm looking forward for your questions. Thank you so much.