views:

333

answers:

3

For our e-commerce service running on AppEngine we would like to offer the option for customers to run the stores on their custom domains (eg: www.mystore.com instead of www.enstore.com/mystore).

From a user perspective, I'd like them to enter the domain name they want to use in their preference screen and tell them how to configure their dns.

I know how you normally add domains to an AppEngine instance (through Google Apps) but I'm not sure you can automate that. And even if that's possible they would be all (hundreds) listed on our google apps page.

Anyone know if this is possible/if there is a good way to do it?

+3  A: 

I don't think there is a way to add domains "programatically" to an AppEngine instance. Apparently, domains can only be added by using the Google Apps method that you described. This is confirmed in this SO post: How do i get foo.somedomain.com get handled by myapp.appspot.com/foo on appengine

The only options that pop to mind are the following:

  • HTTP Redirection

    Many DNS providers support HTTP Redirection. In this case, your clients would be able to set up mystore.com and www.mystore.com to redirect to www.enstore.com/mystore. There are some obvious disadvantages with this method that might not be acceptable. First of all, with 301 and 302 redirects, the users will still be forwarded to the registered AppEngine URL: www.enstore.com/mystore, and it will show in their browser. In addition, choosing between a 301 and 302 redirect can make SEO tricky, since you'd have to get into how search engines behave with these redirects. For example most search engines will not use the original URL as a source for keywords when you use a 301 redirect.

    In addition to 301 and 302 redirects, some DNS providers (like DNS Made Easy) also provide what they call a "masked hidden-iframe redirect". The page will render inside a hidden iframe, so the URL does not change in the user's browsers. However this makes SEO even more tricky, and it will not allow users to bookmark internal pages, or to reference them easily.

    As you can see, this option is less than ideal, but it is one option to consider in some situations. Also note that at the moment, HTTP Redirection using 301 redirects is the suggested workaround for the Naked Domain Issue 777 on the AppEngine issue tracker.

  • Reverse Proxy

    Another option could be to set up a small server somewhere else, like a small Amazon EC2 Instance, and set up a simple reverse proxy. You would be able to set this up very easily, just by using Apache and mod_proxy (or various other alternatives). This would allow you to ask your clients to set up a normal A Record pointing to this instance, while the Apache HTTP server would be acting as a proxy to your AppEngine.

    The fundamental configuration directive to set up a reverse proxy in mod_proxy is the ProxyPass. You would typically set it up with one line like these for each VirtualHost (for each client domain):

    ProxyPass / http://www.enmystore.com/mystore/

    The configuration of the remote proxy could be easily handled by your back-end software.

    This is a neater solution which gives you plenty of control - but there are obviously some costs for these benefits. First of all, there is the expense to host the reverse proxy. You would also be adding another point of failure, so you have to add this to your high-availability plan. In addition, if you are serving some pages through SSL it can become quite complicated.

Daniel Vassallo
Great answers, thanks! Unfortunately exactly what I was afraid of :-) Redirection is not a great option as indeed the SEO is tricky, but people really just want to keep seeing their domain in the location field. I guess we'll go for option #2 for now, but putting a single point of failure in front of gae takes a away lots of advantages of using it in the first place. I hope they will come up with something better in the near future.
Koen Bok
@Koen Bol: Also don't forget to consider scalability, you'd have to maintain a setup of load balanced proxy server with sticky session (for SSL). This does not sound very fun for a simple shop. This might suggest that AppEngine it not the correct solution for your use case.
Maxim Veksler
+2  A: 

Another option is to have each customer sign up for google apps, and then add your appengine app to their app. That way they can manage the url. They will need to use a cname for this, so urls will be limited to something like 'store.customer.com' You will have to support the multitenancy off of the host-header, but that isn't hard to do given that you already have a way to support multitenancy already. You might want to do the setup for the first couple of clients yourself so you can document the easiest way to set it up.

The rietveld code review app does this as you can add it to your google apps domain. See http://code.google.com/p/rietveld/wiki/CodeReviewHelp#Using_Code_Reviews_with_Google_Apps for more detail.

The preferred option is probably to offer your solution through the Google Solutions Marketplace: http://www.google.com/enterprise/enterprise_marketplace/about.html

dar
Great info! Thanks!
Koen Bok
A: 

wrt the reverse proxy. any feedback on issues encountered?

Jrrto
I just set up a simple WSGI proxy app behind Nginx and it seems to work fine.
Koen Bok