HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
fruchtose
muxamp
JavaScript2013–2013
fruchtose / muxamp

muxamp

Streaming media web app written in Node.js

2Distinct people
4Mentions
0Explicit recommenders
68GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Streaming media web app written in Node.js

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:03:16 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by month4 dated mentions

Observed mentions: 2013-03-17 23:58:54 UTC to 2013-12-06 01:57:51 UTC.

01232013-03-01 00:00:00 UTC to 2013-04-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 commentsMar 20132013-04-01 00:00:00 UTC to 2013-05-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2013-05-01 00:00:00 UTC to 2013-06-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2013-06-01 00:00:00 UTC to 2013-07-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2013-07-01 00:00:00 UTC to 2013-08-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 commentsJul 20132013-08-01 00:00:00 UTC to 2013-09-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2013-09-01 00:00:00 UTC to 2013-10-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2013-10-01 00:00:00 UTC to 2013-11-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2013-11-01 00:00:00 UTC to 2013-12-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2013-12-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsDec 2013

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
Mar 20132013-03-01 00:00:00 UTC2013-04-01 00:00:00 UTC312
Apr 20132013-04-01 00:00:00 UTC2013-05-01 00:00:00 UTC000
May 20132013-05-01 00:00:00 UTC2013-06-01 00:00:00 UTC000
Jun 20132013-06-01 00:00:00 UTC2013-07-01 00:00:00 UTC000
Jul 20132013-07-01 00:00:00 UTC2013-08-01 00:00:00 UTC000
Aug 20132013-08-01 00:00:00 UTC2013-09-01 00:00:00 UTC000
Sep 20132013-09-01 00:00:00 UTC2013-10-01 00:00:00 UTC000
Oct 20132013-10-01 00:00:00 UTC2013-11-01 00:00:00 UTC000
Nov 20132013-11-01 00:00:00 UTC2013-12-01 00:00:00 UTC000
Dec 20132013-12-01 00:00:00 UTC2014-01-01 00:00:00 UTC101

What Hacker News says

4 sources
I'm really excited about this kind of service. People have been moving increasingly online in everything they do, and music is no exception. I believe that in the future the vast majority of media consumption will use streaming. (As if it isn't, already!) My main side project involves this kind of service, so I know at the very least it can be complicated to write a server/website which can chomp diverse APIs. [1] What puzzles me is how this could be monetized--I'm sure YouTube and SoundCloud aren't in a hurry to stream their media for free without seeing license fees. [1] https://github.com/fruchtose/muxamp
In Bop.fm (YC S13) Links Together Music Silos Like Spotify, Rdio To Share Tracks
In other words, promises allow us to separate concerns. Document retrieval is one concern, collation another. Other programming languages have this too. They're called a 'METHOD'. Sorry, couldn't resist. On a serious note, look at your code in here: https://github.com/fruchtose/muxamp/blob/master/lib/playlist... And look at your 'playlistCount' function on line 39 (which for no apparent reason you've made a variable). Now I can't understand how a promise there is helping your programming. In fact it seems to have vastly increased the complexity of the code and it is now completely unclear from a quick scan how the method works, what the program flow actually is. It should be a much shorter function, literally just this: function playlistCount(){ return db.query('SELECT COUNT(id) AS count FROM Playlists;', function(rows) {
Read the rest
return parseInt(rows[0]['count']); }); } Your version is 28 lines! 28 LINES. HOW? For a simple COUNT! Actually to be fair to promises, 50% of the problem here is that you've not abstracted your db code and unnecessarily repeat boiler plate connection code again and again and again. But a big part of the problem is that you can't just throw an exception and let it bubble up the stack, you're constantly having to baby sit the code, and that is the promises fault. (unrelated, but as a mini-code review though I've never used node.js but the oft repeated line of `dbConnectionPool.release(connection);` in the connection failure code is an immediate code smell to me, it looks like rain dance code, why would you have to release a failed connection? It failed, how can it be released?)
In Callbacks are imperative, promises are functional
I can speak your comment, since my side project is a Node.js server that talks to several APIs, a database, and N web clients. Like you, I've worked more than a year on it, but I had a positive experience with Q [1] and jQuery promises. Promises make async code easy to manage, even at scale. Each API request gets its own promise. What happens inside that promise doesn't matter, as long as it returns a result or an error. If talking to the API takes one request or two, it does not matter with promises. We can abstract these API requests in such a way that even if document retrieval is a multi-step process or a one-step process for each document source, the collation process can know nothing about the retrieval process to work. In other words, promises allow us to separate concerns. Document retrieval is one concern, collation another. Prom
Read the rest
ises, by abstracting asynchronous control flow into synchronously appearing objects, allow us to write simple programs at higher levels. Separating concerns makes the server easier to test and easier to extend. If you want to see how I've used promises, you can take a look at my work on Github [2]. [1] https://github.com/kriskowal/q [2] https://github.com/fruchtose/muxamp
In Callbacks are imperative, promises are functional

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.