Tuesday, August 12, 2008

Humane Sproutcore Server Development Environment

Recently I've started to build a new, rich user interface for OtherInbox using SproutCore, which has been very enjoyable.  One thing that was not enjoyable was properly configuring my development environment.  

In production, you'll usually deploy your SproutCore app as a static file, so all you have to do is arrange for your users to hit that URL (which out of the box is configured as /static, but could be anything).

In development mode, though, you want to be regenerating your client on the fly by serving it dynamically from sc-server.  To use your app, you talk to http://localhost:4020, and if you want your client to communicate with a backend server, you configure the "proxy" setting in sc-config.  Thus when the Sproutcore server gets a request for "/gadgets", it proxies that request to your local development server.

For some kinds of apps, this works well.  For OtherInbox though, everything the Sproutcore app does requires you to be signed-in and have an active session with the Rails application server.  This caused all kinds of cookie problems, probably because of same origin policy (e.g. my Rails app running at otherinbox.dev was issuing cookies that were somehow getting mangled by the proxying process).

Here's what I solved the problem.  Check out my local Apache setup for details about the whole stack:


 <VirtualHost *:80>

ProxyPass /app http://localhost:4020/other_inbox/
ProxyPassReverse /app http://localhost:4020/other_inbox

ProxyPass /static http://localhost:4020/static/
ProxyPassReverse /static http://localhost:4020/static

ProxyPass / http://localhost:3000/
ProxyPassReverse / http://localhost:3000

ProxyPreserveHost on
</VirtualHost>
See how that works?  When I load http://otherinbox.dev/app in the browser, Apache proxies that request to sc-server, which dynamically generates my Sproutcore client app.  

When components of that app make requests for other parts of Sproutcore, using the /static URL, Apache also proxies those back to sc-server.  

When the app makes requests for anything else, those requests get proxied by Apache to the Mongrel I have running the Rails code.  Because my Sproutcore app is making REST calls to the backend, this ensures that anything the Sproutcore app asks for from my server gets proxied properly, in this case to localhost:3000.

As soon as I did this, all of the cookie issues were done.  You'll also have to add some application-specific code about how you want to force logins if the user is not already signed-in. In our code, I just check for a logged-in cookie, and if it's not there, we open up the URL for a signin window.

2 comments:

Eric Fields said...

Thanks. I'm currently considering Sproutcore for an app I'm developing and I found this post pretty useful. Good luck.

Anonymous said...

MBT Lami Women
MBT Changa Women
MBT Chapa
MBT M.Walk
MBT Sport