Introduction to Node.js, v2 Wrapping Up

[00:00:00]
>> Well, that's pretty much all I wanted to cover today as far as the curriculum and walk you through Node. The stuff I wanna leave you with is what I recommend doing next and how to take advantage of the community and really how to get the best of it.

[00:00:14] So, we did talk about Frontend Master's Node API design. I guess I should just look up my name, that's what I should do. Frontend Masters, Scott, there we go. So I do have a course on here for the API design a Node JS v3. If you want to really get into it, you can see I'm talking about a whole bunch of APIs, databases, routes, caching, crud, automations, authentication, pretty much everything.

[00:00:45] So this is a really good next step if you want to just focus on building APIs. There's also a really nice course on here. I forgot what it's called exactly, but I think it's by Jim Young. It's about like, DevOps or back end for front end engineers. That one's really good, I actually took that one.

[00:01:03] It was really nice. And then I also have an introduction to MongoDB, if that's what you're interested in if you wanna learn how to do Mongo. So check that one out as well. So I recommend doing one of those. There we go learn, learning paths, and then you go down to Node, bam, here you go.

[00:01:21] Look at that, look at that guy, who's that guy? Yeah, Will Siddons has a really good one. Look at this, this is a really great path that's already, that's the one I was looking for a full stack for for engineers, v2, the capstone project. So, I highly recommend going through this if you're really interested in NodeJS.

[00:01:38] I've taken a lot of these courses myself. The instructors here are super talented. So, check those out if you want to know more, and you wanna do a deep dive. But at this point, you pretty much know more than the basics of what it takes to build something.

[00:01:53] Something that I like to do is I like to take a small chunk of time, whether it's 60 minutes or 90 minutes. Especially in Node and like pick a technology that I'm just not familiar with in Node, whether it's like streams, WebSockets, HTTPS, a different database. And I'm like, all right, 60 minutes, build the smallest thing you can make with this.

[00:02:14] Whether it's following a HelloWorld tutorial on the documentation website, or watching a video. I try to build the smallest thing that I can and I try to do that multiple times. And usually within a week, I really understand that technology to the point where I'm comfortable talking about it, and it's no longer foreign to me.

[00:02:29] And I might not be great at it, but I'm no longer foreign. And that's kinda how I develop my knowledge, and that's kinda how I move through things. And then when I come across it in the real world, and I use it at work, that's when I develop a deep knowledge for it.

[00:02:41] So that's just some of the tips that I wanted to pass on to you and I don't know if that'll work or not, but that's just how I do things. Other than that, I can leave you with some really cool JavaScript projects or NodeJS projects that I think are really cool.

[00:02:55] So we have like NestJS, which is a progressive NodeJS framework. They have a cat, I mean, if that doesn't sell for you, I don't know what will. There're more cats. So, try out NestJS. If you ever use Angular two you'll feel at home with NestJS, it's a really good framework.

[00:03:14] And then you have something called, we talked about Hapi, so Hapi with an i. This is another framework that serves the same purposes Express but just built differently. So Hapi is a very good one. And I would say another good one would be looking at just serverless functions and those are pretty much everywhere.

[00:03:36] You have those in Netify, Vercel, AWS, Google Cloud. I mean, everyone has some type of flavor of serverless functions. I highly recommend checking those out. I wouldn't say that they're great for doing APIs, but they're really great for doing one off things that someone isn't waiting on. So I would recommend it for that.

[00:03:56] Other than that, one thing that helped me out a lot was I would go into the source code of projects like Webpack or Parcel or RollUp just to see how these things worked. Cuz they always seemed so magical to me, I wanted to understand how they worked. They're just written in JavaScript and they do so much with the file system.

[00:04:17] I would recommend just going through the code and observing some of the patterns and see if you can make sense of what's actually happening. And even if it's confusing, you're gonna see something that I think, might enlighten you onto how this works and might give you some inspiration on how you can make some plugins or things like that.

[00:04:33] And that's usually how I like to start when I want to contribute. And speaking of contributing, if you find a package that you want to contribute to whether it's React or something like that. Did you know that if you go to GitHub, for instance if I go to React, which obviously is not going to give me what I want it because it's like Facebook, React.

[00:04:52] And you click on issues and if you click on label and you type in good first issue, A lot of them really put really good issues on here. And sometimes they'll even put like the answer that you can copy and paste, I won't say answer, the solution that you can copy and paste cuz they really want to invite more people to come in here and contribute.

[00:05:15] So if you wanna get that nice badge on your GitHub profile, go to some of these big projects, see if you can find one with a good first issue. It might be something simple as fixing a typo on a Readme, and it says you're a contributor. So it's a really good way to get started in the community.

[00:05:30] It's something that I did a couple of years ago, and I don't regret it. So, I highly recommend doing that to contribute to the community, and give back, and start making your own stuff. So, other than that, does anyone have any other questions about anything that we covered today?

[00:05:45]
>> A question about upgrading NPM packages, what's the best path forward?
>> [LAUGH] Every time I upgrade packages, I'm always scared what's about to happen. So I would say, don't just upgrade a package because there's a new version. Only upgrade the package if there's something in the package that you need.

[00:06:08] So, if you identify the fact that like, this new version of this package that we use came out and we need this feature, because you gotta think about it depends on what type of upgrade it is. If it's a major upgrade, a major version went from version 7 to version 8, that means there's a breaking change.

[00:06:24] So you need to identify what that breaking change is and determine how bad is gonna be for you to refactor in your app. Like for instance, if React came out tomorrow and was like, we don't use we don't use JSX anywhere, we use this other thing. Okay, imagine how many components you'd have to refactor to use this other thing.

[00:06:40] So you probably wouldn't want to upgrade, right? So you just don't want to upgrade all the time simply because there's a better version. So, identify if you need it, and then if you do wanna upgrade, you can actually just type in NPM updates followed by the package, so using Express.

[00:07:01] So if you do like NPM update, followed by the package, it'll update that package for you. And it'll save it and do the config file and all that stuff. But again, that's only if you've identified that you need to update. That's what the lock files are for, to make sure you're always on the locked in version.

[00:07:16] And that way you guarantee that there aren't any bugs. Because the last thing you want is an update causing you a bug that you didn't find out until after your user found it when you deployed it. So be cautious of that.
>> I believe you covered this earlier in the course so you don't need to repeat yourself, but in case you didn't.

[00:07:34] What's the best way to import ES module package into a common JS one?
>> The best way to import an ES module into a common JS one is, in that case it wouldn't be any different. You will still use require and you would have to determine if was it a default exports.

[00:07:56] So, if they did, where am I doing [INAUDIBLE], here, here, here we go. Inside of a non ES file, so it'll look something like this right? It'll literally look the same. It'll be like this. Like that, except for it'll say = require. So this will work the same as the non ES equivalent, cuz that's a named export.

[00:08:34] Now, if this wasn't names, and this was a default one, as in, like, if we just did FS, which also works, then this will also be the same. It would be FS. So it's pretty much the same. You just swap the import of a var, a lit, or a const, and you swap the from with the require.

[00:08:52] Everything else should stay the same when you're coming from ES modules to common. It's the other way around that you have to watch out for. It's like, well, hold on now there's no concept of default exports or common JS. So if you tried to import a default, it might not work.

[00:09:09] So you gotta figure that part out. But, yeah, that's how you do that.
>> For this next question, I will say that we do have a webassembly course by Gem, so you should check that out. But this person's asking if you personally have experience with importing a webassembly module from a compiled from a different language into Node and using it.

[00:09:31] And what's your thoughts on that?
>> That's a really good question. Unfortunately, I have no experience importing webassembly into Node and that's simply because I just haven't had a reason to yet. Don't get me wrong, it sounds interesting, and amazing. But I'm one of those people where I'm very problem driven.

[00:09:49] And I just haven't ran into a problem yet that webassembly is gonna help me solve. And it's mostly also because I'm a product person. I like to just focus on building products that people love and the technology behind it is not that important to me. It's mostly just something that I can use really fast to get things done really fast and really quick to test them out.

[00:10:10] So yeah, for that reason I haven't tried webassembly. Although I am up to date on what it is and how to use it and why it's here. But, I think Jim Young's course will probably be better and I would imagine he would have a way better answer to that question and give a better opinion than what I currently just did.

[00:10:25]
>> What's your opinion on TypeScript in Node, have used TypeScript?
>> Yeah.
>> You think there's a lot of value in it on the back end?
>> I believe TypeScript is the future, to be honest. I mean, Dino is literally TypeScript native. So I literally write everything in TypeScript.

[00:10:44] It actually feels weird right now writing something in JavaScript. I haven't written non typed files in a long time. So, I love TypeScript, using it on Node is amazing. It's not native. So you would have to compile that with like the TSC command line, which is the TypeScript compiler command line instead of a config file, TS config file to do that.

[00:11:05] But other than that, yeah, it's really cool. You can actually use Babel now, Babel supports TypeScript, Babel 7. So you could do that as well, either of which you would need to compile it. But, there is just as much value on the back end with TypeScript as there is on the front end.

[00:11:19] And maybe even more, because there's no visual representation of what you're getting on the back end. So at least on the front end, you can go like, I'm using a React box. What does it look like? You can just use it and see what it looks like. It's a box but you can't really see what it looks like on the server.

[00:11:36] So having that TypeScript kind of be your eyes about what is the IO between this method and yours, it's really nice. So, I highly recommend using TypeScript whenever you can, in my opinion. Because you could use TypeScript and not use any types and it's still just like the latest JavaScript.

[00:11:52] And also on that point I just remembered, so I've talked about using like MJS files and JavaScript files. But that's only if you want to use ECMO script modules natively in Node. If you do something like Babel or TypeScript, then you can use the ECMO script files without the MJS and all that nonsense.

[00:12:08] Because those tools actually fix that for you, right, they handle the modules and stuff for you in the interrupt. So this is just if you don't want to build a compiler, but if you use a transpiler, like Babel or TypeScript, then no, you don't have to worry about oil MJS versus JS Node.

[00:12:25] No, you can just call it JS and you can use the module syntax because it's not Node that's processing that. By the time Node reads it, it's going to be the output of that, which will probably just be common JS. Awesome, I appreciate everyone coming to this course.

[00:12:39] I'm glad I got the chance to come in and update it. I hope you got some value from it. There's anything else I could do hit me up on Twitter at Scottups, I respond on Twitter all the time. If I can spell my own thing. So hit me up on there if there's anything I can do for you, or even on LinkedIn, I'm pretty responsive on there as well.

[00:13:00] And, yeah, I hope you continue on with your Node stuff. Let me know if this was helpful for you, if you got some value out of it and what you've done in your job. And how I could potentially make this better for the next one, or maybe I'll do an advanced course on Node.

[00:13:13] Who knows, let me know, any feedback will be great. And again, thanks for coming.