Skip to content
This repository has been archived by the owner on Feb 14, 2018. It is now read-only.

Heroku support for the node/express server? #241

Open
RandomEtc opened this issue May 31, 2012 · 4 comments
Open

Heroku support for the node/express server? #241

RandomEtc opened this issue May 31, 2012 · 4 comments

Comments

@RandomEtc
Copy link

I just started following the "Using Heroku" section in the Hosting-and-Installation-Guide. Since that section follows the "Using NodeJS (Express)" section I thought that it was describing how to deploy the Node server. I now realise it is describing how to deploy the Sinatra server. In the short term, that's fair enough... I will try the Sinatra server first :)

In the medium term, if someone can confirm that the Heroku instructions refer to the Sinatra server I'd be happy to run through them and clarify where I think it would help people new to the project (as I currently am but won't be for long).

In the long term, I'd love to contribute to getting the Node server running on Heroku as that's the stack I'm most familiar with. From reading #190 it sounds like the Node server doesn't yet have Couch storage support - do you consider the Couch support in the Sinatra server to be stable enough to port over to Node? Is anyone already working on that? Is there a branch I could test/help with? Would it be interesting to abstract the storage and provide other options (S3, Redis, MongoDB, Postgres)? Etc :)

@hallahan
Copy link
Contributor

You are correct, the NodeJS server has not been tried on Heroku. An effort in this direction would be appreciated. For it to work on Heroku, you would need to port Couch support, because the Node implementation stores data as .json files on the filesystem. Heroku does not allow this.

The Node server does work well, and this is the one I use primarily. It is easy to set up on your local computer, and it is also easy to install NodeJS on an AWS EC2 instance as well as Rackspace. The nice things about these services is that you actually have root access to your server, so you can install and run anything you please.

@RandomEtc
Copy link
Author

Thanks - I'm up and running with the Sinatra server on Heroku. After I've kicked the tyres a bit and worked out what goes where I'll try the Node server locally and see what it would take to get it running on Heroku as well. I imagine one issue might be that the repo is already set up for a Rack-based Ruby app (the presence of config.ru triggers this on Heroku I believe) - it might be possible to manually set the Heroku build pack so that node.js takes precedence. Time for tinkering begins ... now :)

@RandomEtc
Copy link
Author

A couple more things I've noted as I start to read the coffeescript, which I leave here for myself or a future node-positive contributor to tackle:

  • as noted above, and in server.coffee, a new page factory will need to be implemented and selected when running against a database
  • the owner and favicon methods in server.coffee also use the filesystem and need abstracting to use the db if available
  • the express session should use a database too (I favor https://github.com/visionmedia/connect-redis for this, there's a free redis addon for Heroku)
  • alternatively since it is small (just user id?) you could store the entire session in an encrypted cookie and not require a database for the session at all https://github.com/caolan/cookie-sessions
  • regardless of session store, the session secret should be configurable to avoid spoofing a user's session

@harlantwood
Copy link

Hey Tom, great to have your energy and enthusiasm on the project. I did the work to get SFW on Heroku, including (primarily) abstracting the storage of page and other data, so it can live in the filesystem or CouchDB. This is (emergently) architected to allow easy plugging in of other "stores". The next store that I'm currently excited about is a GithubStore ( update: see this comment ) -- partly so that we get content addressable de-duplication for free, and partly to provide a kind of backdoor compatibility to Gollum wiki and Github Pages (both git backed). But I digress.

I have been using the Couch servers on Heroku with no problem, and I don't know of bugs. I encourage you to use it as a basis for a Node version. The closer we can keep the code bases the better. I'm happy to learn from and draw from your efforts on the Node side.

I'm now using Foreman and a Procfile to boot up and manage env vars on Heroku. I'm cranking on getting a demo out, so this is currently just in a branch of my repo:

https://github.com/harlantwood/Smallest-Federated-Wiki/blob/oyp/Procfile
https://github.com/harlantwood/Smallest-Federated-Wiki/blob/oyp/.env.example

Please consider this strategy for the Node server on Heroku -- it's worked wonderfully for me. I don't know how we can have two Procfiles! But maybe you can. Maybe we can point Heroku to a procfile on deploy.

Testing: the test for Couch are thin and mocky. I would love to see integration specs that test against a real Couch instance. Couchrest, the excellent gem we use to talk to couch from ruby, has specs that talk to a real couch DB (as you'd expect). If I was trying to implement more rigorous testing, I'd start by looking there.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants