When customers signup to my service (myservice.com), they get assigned a subdomain. So customer A would get a url to customerA.myservice.com, customer B would get a url like customerB.myservice.com etc.
I am working on a new version of the service, and would like to redirect some of the new customers to the new version to test the new version.
I know I can create different versions of the service, and split the traffic by ip and cookie between them. It is also possible to split traffic based on routing, but it seems, that in the end GAE still relies on either ip or cookie information to split the traffic: https://developers.google.com/appengine/docs/adminconsole/trafficsplitting#Routing. So if my customer accesses the my service on desktop, ipad and smartphone, he might sometimes get one version of my service on his desktop (at home) and another on his smartphone (on the road).
So my question is if it is possible to always direct customerA.myservice.com to one version of my service and customerB.myservice.com to another version, regardless of device, cookie or ip?
thanks
Thomas
It's not possible with Traffic Splitting feature of App Engine, but you can implement this logic yourself. When users hit your domain, you can choose which version of the app to serve them. There are three drawbacks:
It won't look pretty - the URLs pointing to individual versions may be confusing.
Users might bookmark the version URL, and later they will get an error when they hit it, if the version is no longer available.
You have to make sure that all URLs in your app are relative, if they point to your domain. Otherwise you might link across different versions.
Also, some versions may not be compatible due to the changes in the data model, i.e. you cannot run them in parallel.
Similar issues also arise with the App Engine's splitting - or any other traffic splitting. This is why I recommend to have a trusted group of your most enthusiastic users. Send them a new version as a "preview" and ask for their feedback. They will appreciate you reaching out to them, and they will not be confused if they hit a different version on a different device.
Related
I have a front-end angular app using firebase to store user data.
I currently do not have a backend set up, such as a node.js server.
I would like to use the Google Docs API to upload files from my app.
Since the Great Firewall of China does not (or makes unstable) the use of Google services, is it possible to place those services on the backend server and still use them reliably?
Perhaps after they have uploaded the document to firebase, a backend script retrieves it, uploads it to google docs, and then removes the record from firebase? Just trying to see if Google or similar services are even feasible for this use case.
I suppose the crux of my question is whether or not the calling of the Google API would be taking place on the user's computer, in which case would it become unstable?
** Updates for clarity:
I am deciding whether my firebase-backed app needs a more traditional backend like a node server to do things like: upload images and documents, send mail via Mandrill, etc... It would be helpful to me if I knew whether, after putting in the time to create a server, some of the services I am after (aka APIs) are any more resilient to the GFW than they would be if they ran on the client side. So if any one has had success in such a task, I would like to know.
** Technical update:
So, for example, if I run the Google Maps API on the client side, if the user is in China and is not running a VPN, accessing the API calls will either lag or time out or (rarely) success in returning the scripts. If I was somehow able to able to process the map query "off-site" aka on the server, could I then return with a static image of the map to a Chinese user without fail?
If I was somehow able to able to process the map query "off-site" aka
on the server, could I then return with a static image of the map to a
Chinese user without fail?
Yes, of course. What you are going to miss this way is all the front-end interactive functionality Google Maps offers. But if that's ok in your use case, sure.
I have never tried it with the GCF, but what I would do is this:
Google Maps <-> Your Reverse proxy <-> User
So, instead of the user visitng the real google maps site, it will be visiting your maps.mydomain.com site, that will be sitting in between, proxying everything.
Nginx is an excellent choice for a reverse proxy. If you need more control, there are good node.js reverse proxying packages that you an use to rewrite the content extensively before serving it (perhaps to obfuscate it in case the GCF blacklists content based on pattern matching, or to change the script names/links again to avoid pattern matching).
You are misunderstanding about the great firewall of China. I consulted for a couple of Chinese companies after the dot com crash so I can say this from personal experience, not hearsay.
It is mostly high-end Cisco hardware behind gateways behind their government telecom infrastructure. Nowadays they knock off what hardware they can, every chance they can, and spend money on specialized hardware to monitor cell phones systems.
There was a brief mention of the street-level surveillance hardware on 20/20 before the crash if you are interested in looking it up.
Not to discourage you, but I say set up whatever open servers you want with whatever frontends or backends you want, but the reality is the traffic is not going to be there.
That is why they call it an oppressive regime, they do not get to decide for themselves, remember?
Problem I want to solve
I want to be able to send different users to different versions of my Google App Engine application, on a custom domain, with SSL enabled. This needs to be done in a controlled way, i.e., even landing page should be different, and it has to work on multiple units for the user.
Solution I can't get to work
I am trying to setup a custom domain with sub-domains, and want to be able to access different versions of the application. For example, I have myapp.mydomain.com, and I want to run one version (alpha) on alpha.myapp.mydomain.com, and one version (beta) on beta.myapp.mydomain.com (where alpha is default).
I use the Google Developers Console to set up custom domains, using myapp.mydomain.com, and *.myapp.mydomain.com as custom domains.
This works perfectly as long as I don't try to add on SSL as well, i.e., beta.myapp.mydomain.com serves the version named beta. When I set up SSL I start by adding my application to Google Apps, (per https://developers.google.com/appengine/docs/ssl) and then set up my domain to point to my app. First I add myapp.mydomain.com, then alpha.myapp.mydomain.com, and last beta.myapp.mydomain.com.
When that is done beta.myapp.mydomain.com start to serve the default version instead. Except that it sometimes also serves the beta version (this happens one in every 20 tries or so, I assume it's a glitch for now).
My questions:
a) Should I set up my domains in both Google Apps and Google Developer Console? Or should I remove the setup from Google Developer Console? I tried both, seems to give the same results.
b) It seems like it is possible to get it done by using modules as indicated in
Google App Engine custom domains, subdomains and SSL and in Appengine modules dispatch.xml routing with custom domain. Is this the only way, or am I doing something wrong in my setup?
Suggestions I have received so far
One suggestion is to use traffic splitting and set a unique cookie depending on what version I want the user to end up with. I did not know about this, and it will solve some other issues I have been looking at. It does not solve my current problem though, as I need to have this set before log in. The answer is useful though.
I'll answer with what I did to make this work for me.
Instead of sending users to different versions of the app, I created a new module called alpha, and directed users using alpha.myapp.mydomain.com to that module using dispatch.xml.
<dispatch>
<url>*alpha.myapp.mydomain.com/*</url>
<module>alpha</module>
</dispatch>
I set up custom domains in the App Engine Console (https://console.developers.google.com) under Compute->App Engine->Custom Domains, for *.myapp.mydomain.com and alpha.myapp.mydomain.com. I also added the URL alpha.myapp.mydomain.com to the accepted URLs for my App Engine app on Google Apps (https://admin.google.com). This allowed me to run over SSL as well.
I intend to run the app under another domain (domain alias to my primary domain), so I tried that as well. To make this work I ONLY added the domain alias in Google Apps as www.mydomainalias.com and alpha.mydomainalias.com, because if I added it to Google App Engine custom domains I got an error message ("We are unable to process your request at this time. Please try again later. (Error #1000)"). I have no idea why it that did not work out.
The easier approach is to do traffic splitting on a cookie level compared to setting up extra subdomains AND extra SSL certificates.
The domain name to access your alpha version does not have to change using this approach.
from the docs :
The response from your app does not already contain a Set-Cookie:
GOOGAPPUID=... header. This allows your app to control which version a
user gets.
I have been used the Google App Engine for multiple hobby projects and I have even published a few of them and setup associated domains with moderate success. Of the few, one of those apps even uses sub-domain mapping.
In spite of the multiple setup attempts, I have still had a bit of difficulty setting up my domains for new projects and I've had to cross-reference multiple help articles (many found on SO). Some times those solutions, however, are close to what I've needed because of setup mistakes or variations in my application.
Even with a bit of experience, it still feels like I'm hacking the domain implementation together because there is no good start-to-finish setup for a GAE application that involves creating the necessary Google Apps application, the App engine application, domain registration and DNS setup.
So, could someone please offer a very high-level walk-through of setting up a GAE application from start to finish with the following requirements.
Requirements
A domain should point to the GAE application
The application should allow for sub-domain integration, pointing to different application handlers.
Can dynamic sub-domains be easily handled in the application? If so, what must you do in the setup process to assure that all requests to your domain are forwarded to the GAE app?
Forward "Naked" domain requests are forwarded to the right place. (There are multiple response to this requirement. What is the best approach to solving this requirement.)
If you must create a Google Apps application, when should it be created? Include this in the instruction list at the appropriate place.
Again, many of the above requirements have been asked on many forums, including this one. Usually it comes from someone who is in the middle of a problem setting up there domain with their application. Some of these requirements can be easily fulfilled if certain "gotchas" are avoided in the early stages of setup or application requirements are slightly modified to work around (or with) the limitations of the GAE.
In a nutshell, what I'm looking for is a very simple, straight forward response that provides a list of steps should be followed in order to setup a domain with a GAE application.
Thanks gurus.
All of the steps are independent - setting up a Google Apps account is the same whether you're going to add an App Engine app to it or not - except mapping the domain, which is documented here. Domain registration and DNS setup depends on your registrar, so it's not possible to write a universal guide to those. Handling subdomains in your app, meanwhile, is something that's not App Engine specific - it's just standard WSGI (or Servlets, depending on language).
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?
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.
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
We did something similar to Daniel Vassallo second proposal.
We created a python app on the Heroku cloud
(there is no limit for connecting custom domains).
This app is using python requests 1.2.0 lib to get the correct page from your app engine application according to the request domain.
all you need to tell your clients is to put your Heroku app url as their CNAME
For naked domains you can always use wwwizer
I've been fooling around with the Google App Engine for a few days and I have a little hobby application that I want to write and deploy.
However I'd like to set it up so that users are not directly accessing the app via appspot.com.
Is hosting it through Google Apps and then pointing it at my own domain the only way to go? I looked at that a little bit and it seemed like a pain to implement but maybe I'm just missing something.
My other thought was to write the app-engine piece as a more generic web-service.
Then I could have the user-facing piece be hosted anywhere, written in any language, and have it query the appspot.com url.
Anyone have any luck with the web-service approach?
The reason Google Apps is required is because you need somewhere to a) verify you own the domain (otherwise, you might point it at app engine, then I might hijack it by adding it to my account) and b) set up domain mappings (which subdomains point to which of your appengine apps).
Since this stuff already exists in Apps, it seems silly to duplicate it in AppEngine.
As has been pointed out, it doesn't cost anything, and you do not need to "move" anything to Google. You simple created a cname record with a random name to verify you own the domain, and a cname for the subdomain you wish to point at App Engine. This only takes a few minutes, and once it's done, it's done forever.
Note: If you host your site elsewhere and use webservices, you need to scale the site/frontend. If you host on app engine, you get this for free :-)
I wrote an article on my blog about redirecting *.appspot.com domains to your custom domain to keep your branding:
http://blog.dantup.com/2009/12/redirecting-requests-from-appid-appspot-com-to-a-custom-domain
To do this, I believe you need to be using Google Apps and have a custom domain setup for Google Apps. Then, you deploy your app into your Google Apps domain.
Here is google's official instructions on how to do that:
http://code.google.com/appengine/docs/domain.html
I have used this process for a couple of sites and it is easy and painless, provided you have control on the DNS records for your domain (you should).
OK, we're now at the end of 2017 and things are a lot different regarding App Engine and custom domains. It's easy now!
Go to the app engine dashboard for your app and choose Settings, then go to the Custom Domains tab. From there, choose Add custom domain.
The tricky part is that Google needs to verify that you control the domain, so they ask you to put a TXT record in the DNS for your domain. Once you do that and Google it, you become "verified" as the owner of the domain.
After that, Google will give you a bunch of A and AAAA (for IP6) records to put in your DNS. Once you've done that, you should be good to go.
It can be easily done using request.getRequestURI() method. If the URL doesn't include your domain, just redirect it to the desired URL using
resp.sendRedirect("<your domain>")
Otherwise load a error page using
request.getRequestDispatcher("<error-page>").forward(request, response);