 Go. Hello. My name is Eva Howe and I work on community relations for the Linux Foundation and I want to welcome you to our first Ask Me Anything on HTTP and Streams. Today we have Anatoly and Stephen to answer your questions and have a really good conversation about this, I hope. And so thank you guys to everybody who has contributed a question. We're gonna, what we're gonna work on this is we're gonna go through the questions and, well, in the order that makes sense to the panelists and then we will take extra questions if you guys have them at the very end. So I look forward to an interesting discussion. We'll hand it over. Stephen and Tali, go ahead. Stephen, you want to go first? Sure. I'm Stephen. I work at Elastic. I've been doing diagnostics working for years. Cool. Hey, I'm Anatoly. I work at Postmates and as a staff software engineer. I'm also a member on the Node.js Technical Steering Committee. I've been involved with Node for quite a few years now, but started contributing to Core as initially working on HTTP2 and then kind of branched out to a few other things. Do this. Just go through the questions. Do you want to kind of pick up the questions and? Sure. I'm a little bit concerned. I'll admit that my technical skills are limited. So, but I will just start at the beginning and then if that doesn't make sense to talk about, would you guys tell me? Yeah, and we can also address any of the ones that don't make sense and try to help out as much as we can. Okay, that sounds good. So let's start at the beginning. The first one says, hello, I don't have any questions now because I'm not going deep with Node.js, but I just want to know more, oh, other member questions. Sorry about that. How to get started with HTTP and strings? That's a broad question. It's a broad question. Maybe, would the better question be, how does somebody get started in contributing to HTTP and strings? I mean, I can speak to my personal experience and I'll let Stefan also jump in as much as he wants. But I mean, I've, I personally, when I was starting out with Node a while ago, I used Substax Stream Handbook and I found it quite helpful and pretty concise and easy to understand. So if somebody's trying to learn HTTP and strings, I think that's kind of a good starting point from my perspective. If you're just trying to use HTTP, I think something like Fastify or Express Arcade libraries to just use HTTP, you don't need to know a ton about the actual underlying transport layer. So that's kind of what I would say. I don't know if... Stephen, what was your experience? And then I guess I'm actually curious, did you guys start in, maybe this is not the right question to ask, but did you guys start with contributing in this project, or did you start in another one? How did you guys get a little bit more into contributing to open source and Node in general? It's probably another good question to start with too. So in my case, I'd been doing open source stuff for video game industry stuff, worked on some game engines and things. Yeah, so I actually started contributing to other projects before. I was always interested in WebDos, so my first contributions were to WebKit back in 2006, maybe, I don't know, a while ago. And then kind of just traveled around, tried a few different projects and Node was the most kind of interesting and also the most applicable because I was actually using it. So kind of necessity is a big driver. It makes a lot of sense to contribute to something you're using, right? Because there's a there's a definite immediate connection there. Yep, if it doesn't have something that you need, you just go and build it. Yep, and then you get to use it. Yep, exactly. All right, the next question, stream load balancing. What kind of techniques and patterns helped to develop high-performance streaming APIs like Netflix, etc.? Yeah, so most of that is just like tweaking the high-watermark stuff and making sure your APIs have a good balance for the buffer size. Also, some things to think about. I've often seen people chain together 10 different transform streams. There's a lot of machinery in streams, so it can be a lot faster to just have one stream that does all the things. An example might be if you have a line to limit a JSON, you might have a line split stream and then a JSON part stream, and it'd be faster to just do the two as one stream. Yeah, I agree there. I think the other thing that I've seen often is people get bottled not on the stream's functionality itself, but in the amount of processing they do and the code that they write. So the fact that note is obviously single-threaded, you have to keep in mind that CPU heavy operations are going to be blocking. So if you're processing the data, you have to be mindful about how good your code is and make sure that you're writing efficient JavaScript. There's lots of cases where I've seen streams that they don't really take advantage of the buffering features very well. So I've seen a lot of things about object streams that have no reason to be object streams. The object stream doesn't really have the buffering. It can lose performance quite quickly. Yeah, I think that's kind of a good overview. If there are more specific questions later from people around specific issues they've encountered with performance, I think we can probably dive into those. Okay. At a high level, I think this is kind of a good summary. Okay, great. Next question. Compare streams in node with Java. I don't write Java, so I'm just gonna opt out here. Stephen, what about you? Do you write Java? I have written Java, but it was like years before streams were really a thing there. So yeah, I don't really have much comments on that. Okay, then next question. I'd love an explanation. I'm not like at five or just high level understanding of HTTP and streams and why it's good to know about it. What's the strengths and the example of when it's not a good idea to use streams? That will really help, and I am sure the other developers are in the same boat. So a little bit of a drab old question, but it sounds like basically why do people use streams and when is a good idea to use it and when is a good idea not to use it? Yeah, so streams, their main function really is to just get stuff like both into and out of memory quickly. It's like getting it out of memory. I think it's the important part of that. If you're processing a giant couple gigabyte file or something like that, you probably don't want to let all that into memory. If you're just processing a couple of kilowatts or something, it may or may not matter that much. It's always kind of a balanced stuff. The amount of time you spend loading a file into memory, depending on how the system is set up, that could interfere with the application doing other things. File loading is generally fine, but if you have to do a lot of stuff on the CPU, then it's better to stream it. I'm trying to think of a good example of something that will actually block the process. Maybe if you're trying to request a route or something, the route has a loop that it's doing a bunch of computation like spitting out tons and tons of JSON. Anjali, what do you think? Do you think that's cool? I think that converted honestly from the ... For me, streams are a way to just take a big chunk of work and break it up. The main use is if you're working with big files, if you're working with anything that's using significant memory, the main application, or anything that's broken up over time. That's why HTTP obviously is naturally a streaming interface. Breaking it up over time thing is but important. You're trying to split stuff up. It fits in memory, but it also fits in a time profile that is acceptable. The loop example, you're doing a bunch of stuff within a route. If you're doing something synchronous inside of the route, that means the server can't handle other requests at the same time. Breaking that up into chunks makes it easier for the system to do multiple things at the same time. It does mean that extra machinery of streams, that it's going to technically take longer, but it's just a trade-off. Yeah, I think the time component here is important. Obviously, I think the good example would be like HTTP. You have a third party that's sending you, let's say, 10 files and they're all coming in over the course of like a minute. If you're not using streams, you're just sitting there waiting for the full file to come in and then process each one in a minute. Antelay, I think we lost, seemed to have frozen a little bit. Stephen, did you have anything else to say on this, or should I move on to the next question? No, I got it. Okay, so the next question is, what is the underlying protocol transport implementation and what are the correct reliability expectations? I'm not sure exactly what they're asking there. Okay, next question then. Let's see, how can we stream live videos using row node.js or JS node third-party modules? Does that make sense? Or two third-party modules? Yeah, I think they want to use node without other modules. I'm not sure why. Okay, for video streaming, I'd recommend just like pulling one of the existing things off the shelf because there's a bunch of like ffmpeg and things like that, but make it much, much, much easier. Antelay, what do you think? I agree, you're going to be reinventing the wheel there, I think. Video streaming is complicated. I've had to do it before and there's a reason I haven't done it again. All right, what is the best resource in learning about HCP and streams for someone new to web development? I think we, Antelay, you were already talking about some good resources. Steven, did you have anything to add or was, do you feel like that was sufficient? Not too much. Yeah, the streams handbook is pretty good. There's a blog post of streams for everyone, but it's pretty good and has like a nice little diagram just showing the sort of state machine, I guess, of how all of the functions and events fit together. Yeah, the one other thing I have to add is I believe node school used to have a nice interactive the ally tutorial that you could use to. Yeah, there's a streams adventure. Yeah, I don't know if it still works. If it doesn't work, it's a good opportunity for someone to contribute to open source. Make it work again. I believe it still works, but might target like streams to ideas or something like that. Yeah, yeah, you might have to use it on an older node version as well. That's the only thing I've seen with these. Some of them have broken on like 10 and 12. Okay, next question about HTTP. When client requests, when client requests listen to events, there's no event where we can be sure that it will be called at the end. In node eight error event can be called after close event in request in node 12. It's not possible anymore, but you can have a close event in response called after close event from a quest. Would it be possible to have one kind of flow event order? I think it would be simpler and client won't need to list multiple events for those cases. Yeah, so streams are complicated and things have changed a bunch of times over the years, so almost no one knows how to actually do that properly. There's a module end of stream that can do that for you and handles all the weird edge cases and stuff because there's a bunch of them. If you try and look at the code and get help, there's a bunch of stuff it does and there's a bunch of different events, complete and abort, all these different things that exist on certain types of streams. Just close and finish event and all those sorts of things that just tries to catch everything eventually be like, yeah, something happened, it's done. Yeah, to add to that, the HTTP side of it is even more complicated as a result of the number of streams that are involved. So there's both the request and the response and there's also the underlying socket. So the state machine gets all the more complicated as a result. I think you can generally speaking use the finished utility in, which is now in core, to kind of abstract something up. Yeah. Anything else to add? No, I would recommend using finished in core. Okay. Basics of streams. Can it be used in IoT scenario to get data from devices in real time? Yeah, I don't work with IoT, but yes. I don't see why not. I'm not sure if they're referring to running directly on the device and using that stream stuff out or consuming streams. There are some devices that you can run directly on the device. It's definitely possible to stream out. A lot don't because node is like a bigger runtime and depends on operating system and stuff. And can you stream, you're saying, can you stream into? Yeah, you can stream into a node app easily as long as whatever device you're using is capable of streaming data should be using generally. All right. I would like to know more about nodes native HTTP module and using streams from the perspective of someone with experience mainly using express. Also, how does data serialization relate to using streams? That's a vague question, I guess. I mean, I think Express obviously uses HTTP on there to hood. So it's just a nice wrapper around it with some conveniences. It has some stuff built in like handling file uploads, like body parsing. If anyone uses that and doesn't really know how it works, the body parser, it's basically just going to read the request stream. The next function triggers the next thing in the middleware chain. It's just not going to call that until the request stream is done, doing it with the body. So it's not actually too complicated, internally, like file upload to the same thing. Yeah. And I would also add that HTTP in general in node is obviously basically a implementation of the spec with kind of a state machine. There's not a ton there. It's not really ready for use as is unless you're doing a very basic server, which is why Express and Fastify and everything else exists to make it actually easy to write a server. Okay. Next one. How stable is HTTP to work currently in node also interested in hearing if there are benchmarks? Yeah, it's very stable. It's ready to use. You can use it with most of the popular libraries. I would call up Fastify and Happy as the two that probably supported the best right now. But yeah, it's very stable. The HTTP is actually implemented on top of a C library, NG HTTP, which is I believe fully compliant with the spec and very performant. There are benchmarks for the node kind of side of things. I don't know if there are benchmarks that compare HTTP to with in node with other implementations out there. I also don't know how accurate those would be anyway. But it's definitely like performance is something that was definitely considered and something that people cared about during the development of the HTTP to HTTP to a node. The one other thing I started I would call out is so HTTP to a node has two different boats. So there's the kind of the fully featured core module, which is the full HTTP to implementation, including push streams and all of the other stuff that you kind of might want. And there's a compatibility mode, which is basically just a wrapper around HTTP to make it compatible with the HTTP one API. That's what allows it to work with Fastify and other frameworks out of the box. Steven, do you have anything to add? Not really. I haven't personally used HTTP yet and I'm releasing too many users using any yet. Yeah, so I think also a node it's worth calling out unless you're doing your connection terminations yourself or you're, I don't know, using push streams, I guess. There's not necessarily a heavy use case for it. I mean, if you have most server to server communication will still be not HTTP to my experience. Okay, next question. Why are transposing streams and handling errors that might occur so difficult to write? Design reasons. I recommend it. My recommendation is just to use the pump module and make everything easy. Yeah, and I think, I think Steven also covered the why it's so difficult earlier. All right, then. Any webpack plugins to make this easier? I'm not sure what they're referring to by this. Does that make sense to you guys? Nope. I think the lack of context on what this is is unfortunately going to prevent us from answering this one. Okay, I have two questions of how to use it. Anything you want to add from our kind of original foundational questions? No, I would recommend the guides that we kind of suggested earlier. Those are good starting points. And also, I would say the node documentation itself is now pretty good. It's definitely come a long way over the years. I think it's like the streams documentation is not the worst place to start actually, whereas it used to be completely confusing, I think. Okay, all right. The next one is maybe I solved this by the time, but what is the best way to download multiple large files at the same time? I think it depends what framework you're building on or if you're using a framework at all. Each framework generally has its own body parser thing of some sorts. A bunch of them use like a module in internally. It's just body parser. So, raw body. I'm just looking at them. And yeah, we're now. Yeah, I think raw body is the one that like everything else uses internally. If you're looking to look at that or anything that uses that gives you some controls to like set limits and things like that. Yeah. Okay. Anjali, anything to add? Nope, not really. Not to this one. Okay. Let's see. Is HCP streams implemented by Libov? L-I-B-U-V for part of a different node JS dependency? Complicated. So, Libvv has its own streams concept, which is not really the same. There's kind of a layer of Libvv streams. Stuff happens in the C layer and that kind of gets translated to some extent to JavaScript concept of streams. Yeah. There's kind of like two layers of different types of stream. It's complicated to understand all of it. Yeah, I think that kind of gets at it. But yeah, so like there's also a difference between the streams itself and HTTP. And there's many different layers of what the streams are. Like the, you know, the TCP socket is obviously at some point wrapped around a TCP handle, which is a Libvv stream. But, you know, some of the higher level, not abstractions, but some of the higher level stuff in node is not necessarily using the Libvv stuff. It just depends on it because of like every, every IO resource in node. So what is HCP or FS or anything else depends on the concept of handles, where the handles are the Libvv streams. And there's a bunch of different ones. There's the TCP one, there's the UDP one, there's FS ones. Should we mean data on HTTP, the correct way? Also buffer array, I think what is the correct way? Also buffer array buffer JSON type data or what? Does that make more sense to you guys than it does to me? Not really sure. Yeah, I'm uncertain about this one. But I think some of the advice we gave earlier might be useful to them, hopefully. Okay. What about streams error handling? Yeah, we touched on that a bit before. It's a complicated beast. To use the pump module. All right. How do I get my app done on node JS? That sounds like a rather broad question. Yeah. All right. Let's see. That is about the end of the questions. Does anybody on the call have any other questions? All right. Well, if nobody has any extra questions, I will, Antly, Steven, do you have anything else you want to add about HTTP and streams that hasn't been talked about yet? I don't have anything to add to that topic. I did want to talk about some stuff about contributing to node, but I'll let Steven answer first if he has any. All right. Then you want to talk about contributing to node? That sounds awesome. Yeah. I was going to plug node here. That's the whole point, right? All right. If you're interested in node, if you're getting started, if you've been working with node for a while, if you're interested in streams or HTTP, node JS has a very broad ecosystem and a very accepting community. There's never enough contributors to do all the work that's required. There's a variety of tasks. No matter what your experience level is with node or with programming or with anything else, ranges anywhere from maintaining build infrastructure to writing documentation to fixing bugs and writing test cases. There's a ton of different things that you can contribute to. There's a good amount of mentorship available. Lots of people regularly involved who are available to assist and help out with PRs and documentation updates and other things. There's also good, there are issues in the node JS repo that are tagged as good first issues. They can start with if it's your first time. There's also issues that have the doc label. If you're interested in writing some documentation or helping out in that way, there's also Rich, or as you might know him, Trot maintains a node to do.org. It's a great resource. If you're trying to get started with node, you email Rich and he sends you a task and walks you through making it an actual PR and getting it ready. Yay. That sounds awesome. I didn't even know that existed. So that's really cool. Okay. Stephen, do you have anything to add? Nope. Okay then. Well, thank you to Inatoli and Stephen for looking at the questions ahead of time and being able to answer them and for being here and chatting about them. And thanks to everybody who's on the call. I hope this was useful and we'll see you next month for our next one. Thanks so much. Thanks everyone.