Closed vasyl-shumskyi closed 3 years ago
Hello,
yt-search
actually only ever does one single network (http) request. Even if you get more results, only one single http request was made. When you search on the YouTube page it gives you a bunch of results ~10-30 on the http request you made.
So just grabbing the first result from the resulting video array would have the same network load regardless at the moment.
The actual parsing that yt-search
on the data returned by the http request is negligible and would not effect CPU performance in any meaningful way and has no impact on network performance.
Thanks for the update @talmobi
You are right. Since youtube returns a bunch of results and there is no way to request a smaller chunk of results from youtube there is no need to implement this. data.videos[0]
should work perfectly in this case.
Ah yes in theory you could cut the chunk off early, didn't even think of that. But like you say the cost of attempting to do this wouldn't impact network load significantly and the way YouTube provides the data would probably result in a broken JSON object that would be hard to parse. I think we both agree it's way too much trouble practically at the moment for consideration.
This library also hits YouTubes internal throttling if you use it too much, some ~60 times per minute I'm not entirely sure what it is. If performance is of concern it's recommended to use YouTube's own API (although it costs some money I think).
Thanks for the suggestion and input~
Maybe { limit: videos }
options will be useful to do the opposite thing as well.
For example, returning the first 100 videos (i.e. 5 pages instead of 1)
Nevermind, just found your comment here
It will be cool to pass
{ limit: 1 }
while searching to get only the first video without extra network overload.Not sure if its possible.