Should this be 2 logical applications?

[englercj]

Should we write this as two logical applications? The first being the audiostream application itself, providing an API to control it. Then the web interface as a second app that just uses the API?

This opens up the app to have other UI contributions, and separates out logic for us.

You can just make the main app be a dependency of the webapp so they can still deploy together. Just a thought.

[sr-ix]

What core functionality do you see the audiostream app providing? Parsing, encoding and uploading songs to a(n) (arbitrary) database and the ability to then serve those songs in some form?

[englercj]

I'm saying everything that audiostream does can be in one application, where the only "interface" is via an HTTP API. Thn we also build a web UI that consumes the API to provide a GUI. We would be doing something similar anyway if we built them together; so why not make it two separate articles?

[englercj]

Another way to say this is that the webapp would not "do" anything except consume the API and provide a user-friendly interface.

[nickdesaulniers]

If we write our own table system, that uses a ajax source in json format, and has pagination, and makes fields user editable, etc., that would be nice. I'm seriously considering writing one myself because I'm not happy with the alternatives. Some have everything I described, but nothing has really made me happy.

[englercj]

Yeah most of the ones that implement all of those features are so bloated it is stupid, then the "lightweight" ones don't do anything. I've always had a hard time finding a good datagrid. Usually I end up using a hacked up version of Flexigrid.

[nickdesaulniers]

I really liked flexigrid (from what I saw, never worked with it before). Would a custom one be more worthwhile?

[englercj]

Perhaps, I still feel like a majority of this app will be scrapped and rewritten when we actually map out what we want for the project, so I wouldn't get too far down that path unless you have to.

[nickdesaulniers]

If we wanted CRUD support, I could bang this out much faster with Rails: http://nodeguide.com/convincing_the_boss.html#bad-use-cases

But I wouldn't mind learning mongodb, mongoose, and backbone. I think with those an express, would make a nice stack, and we'd learn some new things. It would be easier to build the crud app, since the transcoding stuff we already know.

[englercj]

But we aren't doing a crud based app; and no need for a heavy MVC framework for something like this. There is only one database with only one kind of data, I would argue that node is great for something like this.

[nickdesaulniers]

Earlier you mentioned enabling the user to update metadata through the client. That's CRUD to me. This app lends itself perfectly to having nicely normalized tables.