# NodeJS-rTorrent, A NodeJS based WebUI for rTorrent



## wiak (Oct 4, 2014)

a group of us are building a nodejs based rtorrent webui
and are seeking more developers and users







you can find our project here (please fork and submit pull request, but do ask about what needs to be coded)
https://github.com/roastlechon/nodejs-rtorrent

its in *active* development at the moment, soo its a little rough between the edges
things that do work is loading torrents, stopping, pausing, remove (does not delete data), rss feeds (with auto dl and regex, a little buggy atm)
new in the dev branch is direct fcgi and embedded database support (no need for mongoDB)


----------



## Easy Rhino (Oct 9, 2014)

This would probably get more attention in the programming section of the forum.


----------



## OneMoar (Oct 27, 2014)

why nodejs ?


----------



## Aquinus (Oct 27, 2014)

OneMoar said:


> why nodejs ?


I was thinking that as well. Personally I run my big downloads on my gateway and just use a Transmission front-end while the transmission-daemon runs on my server.

I cringe at the thought of using JavaScript for anything other than client-side web programming.


----------



## ste2425 (Nov 6, 2014)

Aquinus said:


> I cringe at the thought of using JavaScript for anything other than client-side web programming.



I tried not to comment on this, i tried soooooo hard  but why? Iv'e been working with node for almost 18 month now and found it extremely powerful, epically using browserify on the client so node functionality and API's can be shim'd on the client. Yes Javascript has huge pitfalls and you can _very _easily end up in a nasty place compared to other languages but in saying that ive learnt more with JavaScript in my very short career compared to other languages. Everything has it's place, Node just as much, and the key is using the correct tool for the job (Sorry to preach or anything there).

Anyhoo Ill have a gander at this when i get home


----------



## Aquinus (Nov 6, 2014)

ste2425 said:


> I tried not to comment on this, i tried soooooo hard  but why? Iv'e been working with node for almost 18 month now and found it extremely powerful, epically using browserify on the client so node functionality and API's can be shim'd on the client. Yes Javascript has huge pitfalls and you can _very _easily end up in a nasty place compared to other languages but in saying that ive learnt more with JavaScript in my very short career compared to other languages. Everything has it's place, Node just as much, and the key is using the correct tool for the job (Sorry to preach or anything there).
> 
> Anyhoo Ill have a gander at this when i get home



Node is just JavaScipt built for a server. There are a lot of idiosyncrasies with JS that doesn't make it conducive to server side programming. The absolute only reason I can see someone using Node.js is simply to not have a different language for both your client and server side code. If you're using Node.js for async processing then there are several better options.

These are a couple reasons that Node.JS can become problematic:


> There is, of course, the question of sharing a single thread between all clients requests, and it is a potential pitfall of writing Node.js applications. Firstly, heavy computation could choke up Node’s single thread and cause problems for all clients (more on this later) as incoming requests would be blocked until said computation was completed. Secondly, developers need to be really careful not to allow an exception bubbling up to the core (topmost) Node.js event loop, which will cause the Node.js instance to terminate (effectively crashing the program).


http://www.toptal.com/nodejs/why-the-hell-would-i-use-node-js

I personally think that there are few languages that handle threading and shared memory better than Clojure but I do strongly feel that Node.js is one of those things that really is application specific weather or not the platform will be beneficial to it or not. Also Clojure has a JS compiler, so Clojure can be compiled down to JavaScript and with a tiny bit of work can be modified to run as both a client and server library.

I applogize, but I personally have a deep loathing for JS in general and Node.js was just a platform for a bad idea IMHO.


...and anther blog post I think is relevent:


> Back to Node.js, I feel that Node.js is like PHP. I am not talking about the language itself - I am talking about why it is created. PHP was created to make web programming easier and it certainly achieves that goal. That’s why it gets popular and throughout these years, it evolves a lot to overcome some of its bad design. Node.js is very similar. It was create to make writing concurrent web applications easier. It tries to achieve this by choosing a language that every web programmer has more or less experience with - JavaScript. It also chooses a coding style that is common in JavaScript - event driven and callback style (reactor model). They are probably not the best design choice, but they certainly achieves the goal. Even though callback style (or CPS, Continuation-passing style) is not a good way to organise complex logic. Luckily, the logic of most web apps are not _that_ complicated. And in case you are not lucky you can pull out _promise_ to help you deal with callback hell. Node.js has evolved several great libraries to help you on that.
> 
> Node.js is fine, it has its merit and it serves its niche market well. So when you start a new real time web app with not-so-complicated logic, try it. If you are developing an online game, you might want to deal with concurrency more seriously - coroutines might suit you better. If you start a content-centric or CRUD web app, you don’t need Node.js. If you write it with Rails or Django, you can develop much faster and you don’t need to deal with callbacks mess on top of your logic. The thing is, for these apps, you don’t have lots of concurrent requests. And for a single request, most of the time is spent on network transfer and perhaps database query - Node.js does not solve the essential problem here. So instead of squeezing a few milliseconds out of perhaps a hundred, you are way better off getting a SSD or a better bandwidth.
> 
> So only use Node.js when you _actually need_ it. Don’t just use it because it is cool / it is popular/ I heard it’s fast / I want to learn something new. And by the way, the best place to try something new is on your weekend project, not on your existing project that runs perfectly fine.


http://ruoyusun.com/2013/03/31/node-js-is-perfectly-fine-and-probably-you-dont-need-it.html

Easier for the programmer does not mean easier for the application.

Considering that Torrets are anything but light on computation and resources, I would highly recommend choosing a different language and platform to do this in.


----------



## ste2425 (Nov 6, 2014)

Aquinus said:


> Node is just JavaScipt built for a server. There are a lot of idiosyncrasies with JS that doesn't make it conducive to server side programming. The absolute only reason I can see someone using Node.js is simply to not have a different language for both your client and server side code. If you're using Node.js for async processing then there are several better options.
> 
> These are a couple reasons that Node.JS can become problematic:
> 
> ...



Not going to reply to the entirety of this message as i don't want to de-rail the thread. (Might PM you after work though could be an interesting conversation  )

However the bit at the end regarding the need of high computation and resources, this might be useful for the op.

http://nodejs.org/api/cluster.html

I created something similar for our automated deployment and testing system i built at work (didn't know about the above at the time). It allows you to spawn up a pool of nodejs instances, communicate between them. When load is high it is spread across this pool. If some high-level computing is needed a process is spawned up deals with it then killed. If exceptions are thrown, all new connections are forwarded to a new process then once all current connections are finished the process is killed.
This almost removes the issues of blocking IO killing the server. However i have found not much reason to do this. The most blocking work i perform is creating zip files with database .bak's in and this can all be performed asynchronously.


----------



## Aquinus (Nov 6, 2014)

ste2425 said:


> I created something similar for our automated deployment and testing system i built at work (didn't know about the above at the time). It allows you to spawn up a pool of nodejs instances, communicate between them. When load is high it is spread across this pool. If some high-level computing is needed a process is spawned up deals with it then killed. If exceptions are thrown, all new connections are forwarded to a new process then once all current connections are finished the process is killed.
> This almost removes the issues of blocking IO killing the server. However i have found not much reason to do this. The most blocking work i perform is creating zip files with database .bak's in and this can all be performed asynchronously.



That's practically the same thing as HTTP load balancing. That doesn't help if node.js takes a lot of time to handle chunks. Also clustering it add issues with coordination. You couldn't effectively process more than one torrent file per cluster node because coordination overhead would be too great. As I said, Node.JS has its place and I don't think this project is one of them. You need something that's heavier with more flexibility on the concurrency side of things because shared memory is kind of a foreign concept to JavaScript because of how everything is based on callbacks and for something like a torrent client, you want to gain every advantage you can. The more you wait the slower downloads will go and no one will use the application if using Transmission or uTorrent will download something so much faster and probably can can do the same things.

Really all I'm saying is that Node.JS isn't the platform to use for an application like this. It's a good idea (the application itself) but don't set yourself into Node. It's the wrong tool for the job.


----------



## wiak (Mar 31, 2015)

i think some of you got confused
this is a web interface to rtorrent, as in rtorrent does 90% of the heavy lifting


----------



## OneMoar (Mar 31, 2015)

wiak said:


> i think some of you got confused
> this is a web interface to rtorrent, as in rtorrent does 90% of the heavy lifting


why are you bumping a 5 month old thread ?
node sucks java sucks rtorrent sucks ... nuffsaid
never mind the fact that webui's are STUPID


----------



## R-T-B (Mar 31, 2015)

OneMoar said:


> why are you bumping a 5 month old thread ?
> node sucks java sucks rtorrent sucks ... nuffsaid
> never mind the fact that webui's are STUPID



Possibly because he missed some content.  It is his thread afterall.

Won't comment on the rest because it's largely opinion, which you have a right to.


----------

