More javascript web stack development configuration woes



I’m afraid that I’m beginning to sound like a broken record with my questions, but once again my attempt at utilizing cloud9 for my web development has hit a snag and would really appreciate some explanation/help on how to address this.
I have this workspace
That is a working (or is on my desktop development system with Idea) project that demonstrates the use of, among other things, node, reactjs, graphql, express, javascript based development technologies.
If you clone my git project , run > npm install (assuming npm/node pre-installed and up to date) and run > node run dev (see package.json for details on this macro) it will simply just run and hitting http://localhost:4000/graphql should just work.
Within my cloud9 environment however the >npm run dev just crashes, complaining about some syntax error (maybe a es6 configuration issue?)
Could someone please provide some insight on why this might be so and how I can get it adjusted to run properly?


Can you please post the entire error here? Also, in your code, you should replace app.listen(4000, etc...) with app.listen(process.env.PORT, etc...) or app.listen(8080, etc...), as port 4000 isn’t accessible using the workspace preview URL at


Okay… this issue had to do with an older version of node being used. Updating to latest fixed this problem, however, now it will start up and the server is listening… nodemon will (as it should) restart as the result of source code changes so all seems to be mechanically sound. However, when I run this locally I do this from a browser:
localhost:4000/ (4000 is the port that graphql will run on)
and up comes my app. I can’t do this from cloud9 preview. What url would I use for preview under this condition? I don’t believe I can redirect graphql to another port (without a ton of hacking on 3 party code).


You can’t use port 4000 on c9 workspaces, last I checked - only ports 8080, 8081, 8082.

The URL you should visit to visit your running c9 application is in this format:


replace [workspace] with the name of your workspace, [username] with your username, and [port] with the port that you are running the server on (8080-8082). Make sure your final URL does not have any brackets.


So therein lies my ongoing (losing) wrestling match with cloud9.
This is a reactjs app that’s utilizing an express server which in turn uses the express-graphql library that sets up the listening on this port (4000) for request/response graphql interaction. So I don’t have any control over changing this, short of hacking up the express library code. Would prefer not to do this on distributed production code.


We generally recommend people use $PORT when defining their ports (this defaults to 8080). That way, when you move to Production, you can define the $PORT variable on your Prod server to be whatever you want it to be.


Yes, I understand what the recommendation are in regards to this, but I can’t determine how, in the context of the project that I called out in the OP, how this might work, or where such a setting be applied. I was hoping that someone from your team could simply access my existing project and provide some feedback on what would work in this case.

I’m just dubious that it can be done at all, though I’ve been wrong before.


Are you sure it’s not possible to change the port that GraphQL is listening on? If not, then you probably can use nginx to reverse proxy your app to the correct port. Here’s how:

Add the following configuration to a new file at /etc/nginx/sites-available/mysitename.conf:

server {
        listen 8080;
        location / {
                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_pass http://localhost:4000;

Symlink the file to the enabled sites directory:

sudo ln -s /etc/nginx/sites-available/mysitename.conf /etc/nginx/sites-enabled/mysitename.conf

Restart nginx:

sudo service nginx restart

Check to make sure it is running properly:

sudo service nginx status

Now, run your GraphQL server as normal, and try to visit the URL in your browser