I chose NPM as my package manager since it comes bundled with node and so I decided to try out NPM workspaces as my MonoRepo approach.

So here are my takeaways

1. Setup

• The NPM workspaces Monorepo has one root dir with one package.json which defines the workspaces, but besides this it is more or less empty. The package.json defines a workspace directory which contains the sub projects.
  As of now you can’t use npm init for this but have to create the main package.json manually.

  "name": "workspaces-example",
  "workspaces": [
    "packages/*"
  ],

• The sub projects each have their own package.json with all necessary dependencies for this specific project. The sub projects can be initialised by npm init -w packages/cli
• To add dependencies you can add the workspace to the npm add command and the dependency will be added to the respective package.json:
  npm add commander -w packages/cli
  To install dependencies, run npm i from the root directory. This will install all deps of all workspaces in a node_modules folder in the root directory, but none in the projects in the workspaces folder. This already is a win because it will avoid having dependency duplettes.
  However if you have conflicting versions of the same dependency in your packages, you will have a separate node_modules directory with the only the specific version for this single package.

2. Development

• Updating dependencies can happen just like adding dependencies:
  npm update commander -w packages/cli
• When you need different versions of a dependency in your workspaces, NPM will create a new node_modules folder in the one divergating workspace with only the dependency where you have the different version.
• When you need to share code between workspaces you can import code from one package of the workspaces in another package just as a normal dependency from the NPM registry.
  For example when you want to share types in a typescript project you can add a types workspace and just import in the other workspaces files.
  import {Name} from "types";
• It is probably good practice to add shortcut scripts to your main package.json to run commands of your workspaces. So you don’t need to change to the workspaces directory, which is of course still possible.

  "scripts": {
    "hello-cli": "npm --workspace=@workspaces-example/cli run hello",
    "hello-web": "npm --workspace=@workspaces-example/web run hello"
  }

3. Deploy

• Deploying from a Monrepo needs to take the different packages into account, which need to be deployed separately but from the same CI config.
  For Github Actions i used a path directive which changes to the package directory and runs instructions there.
  with:
path: packages/astro
• Other prefabricated actions like f.e. actions/deploy-pages have a
  working-directory: ./packages/astro
  directive which have the same effect.

You can check out the example project here: https://github.com/ivoba/npm-workspaces-example

One probably does not necessarily need a Monorepo for this example, but it is good to know that Monorepos are quite simple to achieve just with NPM, in case you need to.

As I moved the code to github this week, I wanted to give a quick overview of the project and its technical underlyings, just in case someone might be interested :)

As the title of this post might already suggest, its about selecting and layering loops from audiofiles hosted on soundcloud.com and thereby creating new music.

Those collections of layered loops are called a session. Sessions can be created anonymously by everyone and are auto-saved on every action. By distributing the URL of a session other users can join and every action is synced between all users in realtime.
(complete mayhem, indeed :)

The application is built with HTML5 and JS w/ jQuery using the soundcloud API on the client side and runs on node.js & mongoDB with express, socket.io and mongoose on the server side.

I basically started the project to find out if you could play multiple loops asynchronous and synced with low latency using the Web Audio API while collaboratively working together with multiple users in realtime. 

As that turned out to be not only possible but performed real nicely, the experiment then developed in somewhat of an application and finally got a name and a face.

There’s a whole lot of things i’d like to implement / refactor and do when i get some time on my hands, as

– adding a “record” feature to record, save and export created sessions as audiofiles

– rewriting the client side with backbone.js (as things got a bit messy …)

– adding some audio effects to the tracks

– write some tests

I’d appreciate any form of contribution as much as any questions or feedback on the project :)

Feel free to check out the live version at  http://mashcloud.net/ or the sources at https://github.com/gherkins/mashcloud

Starting with Apache and mod_proxy, i ended up with a plain node solution, which i really like.

Let’s take a quick look on some different approaches out there:

—1—

Using apache on port 80 as a proxy

ProxyPass /nodeurls/ http://localhost:9000/
ProxyPassReverse /nodeurls/ http://localhost:9000/

via stackoverflow

— no websockets
++ probably the easiest way to integrate with your running AMPP-stack

—2—

Using a node.js app on port 80 as a Wrapper for other node apps.

express.createServer()
  .use(express.vhost('hostname1.com', require('/path/to/hostname1').app)
  .use(express.vhost('hostname2.com', require('/path/to/hostname2').app)
.listen(80)

via stackoverflow

++ you can use websockets on port 80
— apps crash/restart/stop globally
–what about your apache or the like?

—3—

Using node.js with node-http-proxy on port 80

var http = require('http')
, httpProxy = require('http-proxy');

httpProxy.createServer({
  hostnameOnly: true,
  router: {
    //web-development.cc
    'www.my-domain.com': '127.0.0.1:3001',
    'www.my-other-domain.de' : '127.0.0.1:3002'
  }
}).listen(80);

++ proxy websockets to any port
— you might need to move your old web server to another port

The really cool thing about using node-http-proxy is its capability of proxying websockets.
So you can have your apps running independtly on different ports while serving everything to the user over port 80 and use stuff like socket.io.

Since i’m new to node.js and miles away from beeing a admin, any feedback is highly appreciated :)

Here are some things that come real hany when you are working with jade.

This one really saved my mental health in more than one case.
Just paste your HTML and you get nice and clean jade code:

http://html2jade.aaron-powell.com/

If you are using Netbeans, make sure you don’t miss to install the beautifully working plugin for .jade files.

https://github.com/lumenlunae/jade-netbeans-syntax-highlighting

If you are developing in PHP and want to check out jade anyway, check this out:

No seriously, check THIS:

https://github.com/everzet/jade.php

So i’d like to share some of my experiences in the cloud since i am still trying to figure out if it its worth for me or if i am better suited with an VPS.
Maybe somebody feels like feedbackin.

I tried PHPFog for PHP and no.de by joyent for node.js.
First i have to admit: yes i only tried the free models and of course they are limited and because its free you cant expect to get it all, right?
Yes and thats true.

With PHPFog i set up an app based on symfony 1.4. After some inital problems due to some bugs on PHPFog side, i got it running.
I really like to mention the kind and immediate chat support by PHPFog. It really made me feel like dealin with humans and not only machines. Big up!
By then everything felt really smooth with git deploy, configurations, mysql setup etc.
But i had to shut down the app again, because there are restrictions to PHP which killed the app like disabling “file_get_contents for remote URLS”, probably only in the free model. But that killed it for me at that point.
So read this carefully before going to cloud: http://docs.phpfog.com/index.php/features/article/shared_vs_dedicated
I guess with dedicated hosting you get more power, sure.

That brings me to the pricing plans, which means if you pay more you get more.
That reminds me of good old shared hosting days.
Of course in the cloud you get more and faster if you have to scale.
Also if you have more apps you can bundle up, it can be a win, like read here: http://blog.phpfog.com/2011/12/08/but-isnt-php-fog-expensive-compared-to-vps/
Thats just fine, but if not you might be wrong there.
And remember you are not in fully in control. So if you decide to checkout the Twig C extension: you cant.
That also reminds me on good old shared hosting days.

With the node.js cloud i had similar deja vu’s:
Gettin my node app running was not that easy but i made it after some approaches.
Then it was cool: git deploy, npm support, console on the smartOS machine, having node on port 80, etc. That was great.

But then i tried my app and had to realize sockets are not really working on Chrome and Firefox, wtf?
It seemed that there was an issue with an node-http-proxy, as you can read here: http://discuss.joyent.com/viewtopic.php?id=30975.
So that patch wasnt patched and all you could do is waiting, just like in good old shared hosting days.
Get me?

So what am i trying to say?
I am not really sure, but my resumee is if youre not building the next tumblr resp. you are not expecting high scaling you might improve your server skills and stick to an VPS.

What else? I am confused about the pricing!

With an VPS its clear, with Heroku and thelikes it could be 60$ per month or more, or less, or what?, I dont know.
So its pretty much testing, see what your app is actually consuming and decide then.

And remember for PaaS Services as described you rely on the grace of the admins in the cloud.

Actually its all said on the post itself: installation, features and restrictions.
So go and read it.

Its still a bit early stage and only runs on a nightly-build netbeans but it already has some helpful features.

For me i just like to have a node.js icon as my project icon ;).
No serious, i like the npm support, see image, especially for browsing the modules to see what is all available.

Whats also is nice and that you have the modules in the file tree and that they show the module info.

A GUI for installing the modules and editing the package file i dont really need but its nice to have.
Then starting the app from a button in netbeans is also nice.

I guess whats missing the most is code completion, maybe that will be added sometime soon.
I hope so, because having code completion for node modules would be pretty cool.

Also node.js via macports holen:

$ sudo port install nodejs

Und den node.js-eigenen Package-Manager:

$ sudo port install npm

Mit diesem installieren wir als nächsts less, und zwar “global” (via -g)-Flag (“global” bedeutet, dass das Modul unter $nodejs_lib_path/../node_modules abgelegt wird, ansonsten wird es im aktuellen Arbeitsverzeichnis unter ./node_modules installiert):

$ sudo npm install -g less

Damit haben wir alles, um unsere less CSS Stylesheets kompilieren zu können.

Als nächstes holen wir uns den Yui-Kompressor, diesen habe ich mir einfach aus dem Netz gezogen und unter app/java/yuicompressor-2.4.6.jar abgelegt (Die Binary findet ihr unter http://developer.yahoo.com/yui/compressor/).

Nun die Konfiguration:

app/config.yml:

# Assetic Configuration
assetic:
    debug:          %kernel.debug%
    use_controller: false
    filters:
        cssrewrite: ~
        less:
          node: /opt/local/bin/node
          node_paths: [/opt/local/lib/node, /opt/local/lib/node_modules]
        yui_css:
          jar: %kernel.root_dir%/java/yuicompressor-2.4.6.jar

Zu beachten sind die “node_paths”. Der node.js-Modulpfad muss explizit angegeben werden, sonst kann node.js die require()-Statements nicht auflösen (das sind sozusagen die node.js-“Classpaths”). /opt/local/lib/node zeigt auf Core-Module, in /opt/local/lib/node_modules liegt unser less.

Um den Yui-Kompressor zu aktivieren, reicht der simple Pfad zur .jar-Datei.

Nun müssen wir nur noch unser Twig-Layout anpassen:

src/Nerdpress/DemoBundle/Resources/views/layout.html.twig:

<!DOCTYPE html>
<html>
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
        {% stylesheets
                '@NerdpressDemoBundle/Resources/public/css/main.css'
                '@NerdpressDemoBundle/Resources/public/css/layout.css'
        	filter='less,?yui_css'
                combine=true
        %}
          <link rel="stylesheet" href="{{ asset_url }}" type="text/css" media="all" />
        {% endstylesheets %}

Das “?” vor dem Filter “yui_css” bedingt, dass die CSS-Compression nur angeschaltet wird, wenn der Debug-Parameter auf false steht. “Combine” bedeutet, dass alle CSS-Dateien in einer einzigen, großen Datei zusammengefügt werden, und “less” bedeutet letztlich, dass alle CSS-Dateien mittels less CSS precompiled werden.

That´s it. Die Seite im Browser öffnen und das Ergebnis bewundern. Viel Spaß! Symfony ist schon was feines…

…and so it goes Asynchronous:

 for(var i = 0; i < loop.length; i++)
 {
	var proxy = http.createClient(PORT,SERVER);
	var request = proxy.request('GET', url, 
        {
            "host": SERVER
        });
	request.end();
	...
 }

fire, fire, fire, fire

… and so it dont, Synchronous then:

var proxy = http.createClient(PORT,SERVER);
 
for(var i = 0; i < loop.length; i++)
 {
	var request = proxy.request('GET', url, 
        {
            "host": SERVER
        });
	request.end();
	...
 }

point – shoot, point – shoot, point – shoot

well i didnt know that :)