Transcript

Hi everyone and welcome to Beyond Nodejs I space where we explore the ideas in real world insights behind node JS and the ecosystem. Today we are joined by Ulysses. He is maintained of some of the most widely JavaScript tools now JS Express, Lodash, Yeoman and also his. Nine delegate en. Senior Software Engineer at Melters Ulysses is great to have you here to get started. What is the worst thing you've ever seen in a production Node JS application? Well, I think one of the worst things that I saw in Nodejs production applications most of the time is how the people do the error handling, especially when you are. Producing events, right, Most of the time the people forget about their own error events and these kind of things so that you don't have the right mechanisms to prevent your application from crashing or it's behaved in a way that you don't expect, right? That's that's a common thing, common people. Also a very common thing is when you use when you are not used to work with asynchronous mechanisms and mechanisms and stuff like that. So you and that for example, don't catching promises and things like that, which also is also part of the. Handling and I will say also that some people try to abuse a lot on the sync methods and so you end up for example, writing sync on the disk and stuff like that and you end up blocking the application unintended 3 So that's also about experience. And it happened that I think nowadays is more easy because we have a better mechanisms to handle asynchronous and stuff. But in the past it was more prone to errors, especially when we just started to use callbacks and stuff like that, like in the old days of the Node JS application. And I see a bunch of these errors in. Production and sometimes it's a nightmare to the book this kind of thing so yeah, the events a lot but they are highly recommended for who is watching this. Always try to do the error handling please and try to use the right mechanisms when you are doing asynchronous operations and try to prioritize asynchronous operations with make sense for you. What's the best feature No JS has happened in the past year and why does it matter Well for me personally, I think one of the most relevant things that no 25 added. In my case was fine grained network control with a low net attack basically so you can have a more security around your services, especially if you are running microservices and you are having a specific rules for networking and communication. I think it's an important feature so you don't have to depend on external things for doing that, which was the use case in the past. I think also in terms of passive gains as well, we have now a better implementation of Jason Stringify because the version of V8. So, so basically also you get a lot of boosting. Four months, a lot of things are using Jason Stringify under the hood. So that's also a good important thing. And I will say from the last years, probably the most important things for me in terms of features that they wanted was the test runner. Definitely I started to use the nodes test running natively a lot. I migrated a lot of from from a lot of tests running in the past and then start to use native one was a really nice relief. And I think also by having the option to retain environmental file data, different nodes, that's just great. Been so we avoid to have another library. I think that that was a good addition from the last year. Yeah, I think those those are my favorite ones. I think recently maybe notes, but yeah, that was a big win for us. What's 1 common misconception about ninjas in production? Well, I think one of them, especially for me as an open source maintainer one one of the Commons misconception about no Jason production is how much do depend on open source projects and libraries node JS. Must know these projects, we see a lot of dependencies, even if just transitive dependencies. So you end up needing to be involved somehow on the ecosystem in order to get an idea of how large your dependencies, what your depend on, build good relationship with maintainers and so on. Not everybody's doing that and I think that's a pitfall in many ways. I think if you start to getting more involved with the community and what is around, you are going to get a more understanding on your dependencies and you can have a build a better trust with your own dependencies. It's very hard to survive. You know, GPS, uh, without, you know, having a lot of dependencies even now with the node JS runtime getting much more and building stuff. So you depend on listing, but you still need a lot of frameworks, libraries and so on. I mean, we're trying to build a lot of complex projects where a lot of dependencies and I think it's important to get the good relationship. I think in the past was more like about technical concepts of nodes because it was a new way of doing things in the back end, mostly on time. So a lot of people didn't understood the single. Good work. I didn't understood a lot of the ecosystem how how to do this back end now work right when people migrate from other systems. And now it's more about how you have a better relationship with the ecosystem and how you understand your own dependencies and how you get involved with those. And the last question, what's the most valuable feature of insulin for production teams? This is a great question. I actually probably one of the features that I like the most is the simplicity one. It's we try to. So estimate how hard it is to get telemetry working on Node JS applications. Sometimes you need to rely on third parties. You need to get somehow these orchestrated and get this telemetry flow into one. That's where something where you can get this info right. So the good thing often Solid is you have already done with the notes and you don't have to include any additional external library and so on. So you can go just with this note fork with this in Solid with all the telemetry layer on it. So you don't have to worry about that and you automatically can get these metrics showing that as well. So. That option to see this information faster, I think is one of the best ways when you start to get on board on this, right? Because sometimes if you are not used to use, you know, this performance tool in monitoring tool and so on is the date you need these kind of tools that you are stuck on a memory on a memory leak on a big book that you cannot resolve with your own tooling. And you existed tooling, right? You need to jump to a new technology to help you. So I think that is one of the best features that we have that is super easy just to change Nodejs for unsolid and run your application and you will get the metrics and you will understand what's going on, right? Including their flame graphs and everything. So it's very easy to start solving the problem. I think that that autumn boarding easy makes a lot of our customers very happy, I think over the time, and it's one of the best entryways for many people into the performance universe and to metrics and so on is when you get that real problem and you need something to figure out how to solve that. That was amazing. New leases. Thank you so much for being here and thanks everyone for watching Beyond Our JS. See you in the next episode.