calvinfo

I haven't worked with unicorn specifically, but from my understanding - it should work fine given a reasonable number of child processes.

It's worth noting that when you initialize the client, the module spawns a new thread to consume messages from the queue. As long as each forked child process in unicorn initializes its own client, that process will be able to use its own in-memory queue. That means that they will all make their own web requests independently since there isn't any kind of syncing or shared state going on.

Express-resource is cool - I haven't gotten the chance to use it in a project yet so I can't comment too much on it.

Our app isn't grouped strictly into resources, though it's something we might be able to benefit from. Currently we use different pieces of middleware to load whatever items the route needs.

Thanks! I haven't been using AMD so much since I've mainly been working on the server-side js, but it seems like a similar structure.

The shared code between client and server is definitely an interesting concept. I'd be interested to see some of your posts on how this ends up working!

This is definitely a fair point. So far, we've found it to work well by keeping our packages fairly well organized.

A simpler solution might be to put your custom modules in node_modules (without symlinking) and then commit those to your source tree.

The main point that I wanted to get across was that it's worth structuring your packages in such a way that makes it easy for developers to write new modules without using a lot of relative paths in the file system. Node does this work already, so I like to take advantage of it.