I have had a Python-based Google App Engine app working great using Cloud Endpoints 1.0 for several years without incident. I have had nothing but trouble migrating to Cloud Endpoints 2.0.
Currently I'm in the following state after already clearing many previous hurdles described in other similar questions:
I have one version of my service called gce1 which uses Endpoints 1.0 and is set as the default service receiving 100% of my traffic. I can point API clients and the APIs Explorer to both gce1-dot-myservice.appspot.com and the default myservice.appspot.com and everything works fine. I can verify in the logs that anything that goes through here is using GCE 1.0.
I have a second version of my service called gce2 which is not receiving any traffic by default, but if I point an API client or the APIs Explorer to gce2-dot-myservice.appspot.com it works just fine, and I can verify in the logs that anything that goes through here is using GCE 2.0.
Great, right? So it would seem that all I need to do is migrate all my traffic to gce2 and I'm done.
But... when I do that everything breaks! The default myservice.appspot.com serves up 405 POST Method Not Allowed responses to my existing clients, and if I look at the APIs Explorer, suddenly it now shows a bunch of obsolete methods that I think are from years ago and are no longer used in my current API. I can't tell where those are coming from (they are nowhere in my code, and haven't been for years), and I can't get the default service to serve the GCE 2.0 API no matter what I do.
The biggest problem is that I have thousands of users in the wild that all point to the default API URL, so it isn't so easy to just have them start pointing to gce2-dot-myservice, and besides, it doesn't make sense that I can't make the new default the new default. I've been working on this migration to GCE 2.0 for months, the deadline for getting off GCE 1.0 is getting closer by the day, and Google Support has not responded since late last year on this topic.
I should also mention I have tried:
Pushing a new service with the GCE2.0 code directly to default
Pushing a new service with no API at all (to maybe clear a cache or something)
Pushing services with all different sorts of version names
None of these have worked, although I haven't done any of them allowing a long delay since I'm working on a live service with real users.
This issue is now resolved, so for most people it should no longer occur. However, in my specific case, I had a legacy API that was getting in the way and had to be deleted, which did require specific attention from a Google engineer.
If you have similar issues, visit issuetracker.google.com/issues/76031966 and comment there.
Thanks to #saiyr for help tracking this down.
Related
We have Java servlets up and running on GAE, using blobstore, datastore and other cloud services.
Currently, we're starting a migration process to cloud Endpoints and we've hit an issue: if we use a different GAE project, we would not be able to query regarding current datastore entities (to the best of my knowledge, Google doesn't want you to do this - see
this question
and the GAE terms of service - section 3.3d), so we need to use the same project for both.
I looked up whether it's possible to have one GAE instance running Java servlets and one instance running Endpoints, but I found no conclusive answer anywhere.
If we try to implement and something goes wrong, we're looking at a potentially major issue for our users, so we need to be sure beforehand.
Has anyone tried something similar, and can assure us that this works?
You have 2 options to run the old and the new code inside the same app (thus with no issues sharing access to the datastore) but as separate engine instances, so they can be developed/deployed/managed independently:
as different versions of the same app/module(s):
the old version remains the default, the new one can be accessed at a different URL during development (possibly via URL routing)
you can use traffic splitting to do live A/B testing on the new code and for gradual final migration until you make the new version the default
as different modules of the same app:
both can run (fully functional) side by side indefinitely, but you need to be more careful during development
traffic is routed to the modules in several possible ways
final migration is done by publishing the new URLs, eventually re-directing the old URLs and finally bringing down the old module code
The 2 approaches can even be combined, if needed, as the final solution described by the OP's in this somehow similar question (for the python environment, but java equivalents exist): Google App Engine upgrading part by part
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?
I have an issue with our Python 2.7 Google App Engine project where after a lot of research it appears as though App Engine is repeatedly sending through the same request to our servers. Is anyone else experiencing this issue?
EDIT:
It's a standard request with all the same parameters as it was first sent with (some of which are 15 days old now). I'm wandering if it's a similar situation to this https://groups.google.com/forum/#!topic/google-appengine-downtime-notify/9fAYP7UyppQ
Typically App Engine doesn't send requests, it's the framework you use to handle requests.
If you're getting duplicate requests coming in, you should look to see where it's coming from. If it's coming from an app engine server to your own external server, then somebody is running some sort of process on their app engine account that's accessing data from your server during its execution.
The details, including what you would do about it, are all situation-dependent. There's no catch-all response. Just be aware that, yes, any computer on the Internet can make web requests to any other. And that includes app engine (in both directions).
I have created a small project in Google apengine and like it apart from one thing: It seems virtually impossible to delete or change an endpoint, once it has been made. The API often stays the same, regardless of code changes in the java endpoint classes. I tried to delete the complete API, but that is not possible either. Is there any way to do this?
RE: Deletion
it's not currently supported, but we're working on it.
RE: API Changes
The Google APIs Explorer web app aggressively caches, so you'll need to clear your cache or force a refresh when you update your API server side to see the changes in the client.
I would like to write a client application for Android that uses the Google App Engine as a database backend. My Android client would connect to the App Engine to save information, then it would connect later for reports. Is it possible to use the App Engine as a backend like this?
If you're looking for something like the remote api that the App Engine has in python, then you'll be disappointed to find it missing in Java.
That said, absolutely nothing stops your from hitting your app and posting data either through POST / JSON / XML / any other format you can think of. The same thing goes for getting your reports back.
If security is a concern, the OAuth protocol allows you to authenticate to app engine from your android device.
This is an aside, but as far as reporting is concerned, you might not find the app engine a very suitable platform for reporting type apps. Just make sure you understand its limitations - the lack of joins, 1000 object limit, no sum / average, necessary indexes, etc. It's certainly not impossible, but do think carefully about how you're going to model your data.
Yes, it is possible.
Without more details in your question, any more details in the answer would be speculation.
Yes, its very much possible. It's something I am also currently working on.
My code uses HTTP GET and HTTP POST and I am using a RESTful service on the GAE.
I'm sorry I can't provide any code because I am still learning however the library I'm using is called RESTLET. They have libraries for both GAE and Android however I'm only using RESTLET on the GAE and I'm just using the HTTP library in the Android SDK for the client.
http://www.restlet.org/
The version you require is 2.0 M6 and not the stable release.
No.
In your response to Laurence, you said you want a direct DB connetion. A client cannot connect directly to the GAE datastore. You must write web handlers to interface between the client and your data. It doesn't have to be much, but it must be something.
Yes, it is very possible. You would not connect directly to the GAE database though. A better architecture would be to make your app hit a URL that writes to the DB. For example, you could set up a Struts 2 action that takes the values of your query parameters and then mutates and validates them as necessary before persisting them.