How can two AppEngine applications inter-communicate? - google-app-engine

I try to build an application in Google App Engine, but i have some question and don't know how to solve it.
I try to build two application, one is get a String from user, and other is process the String like divide or encrypt.
My question is how to transmit the String between two application in Google App Engine? And can I build an application just process the String, don't present the WEB page.
Any one can give me some tips? thanks a lot.

The only way for two AppEngine applications to communicate with one another is through the normal HTTP request/response model. For your case, we'll have App A, which answers requests from a User, who provides a string to be processed. App B will receive requests from App A, which passes along the string to be processed.
App A handles the URL /providestring?string=... where ... is some arbitrary value
App B handles the URL /processstring?string=... where ... is some arbitrary value
User uses a browse or writes an application that makes a call to /providestring
App A's URL-handling code runs and extracts the value of the string parameter
App A uses URLFetch to call App B's /processstring
App B's URL-handling code runs and extracts the value of the string parameter and does whatever kind of processing it does and
sends some sort of response to the caller.

One way to do this would be to have a shared database. App A would intake user data and save it to the database. App B would pull the user data and process it.
An Accepted feature request is for multiple App Engine applications to share datastore access [1].
Multiple App Engine applications can share access to Google Cloud SQL instances [2].
To grant access to your App Engine application:
From the Google Cloud SQL pane of the APIs Console, find the instance that you
want to grant access to and click the on the name of your instance.
Click on the Instance settings button on the instance's dashboard.
On the Instance settings window that appears, enter your Google App Engine
application ID under the Authorized applications section. You can grant access to
multiple applications, by entering them one at a time.
Note: you can achieve this with one app using the datastore. Here are a couple of accepted patterns:
A RequestHandler takes in user data, queues a task to process the data and save it.
A RequestHandler takes in user data & saves it. A cron job pulls all recent models of that type, processes them, and saves the processed data.
[1] https://code.google.com/p/googleappengine/issues/detail?id=1300
[2] https://developers.google.com/cloud-sql/docs/before_you_begin#configure_access_control

Related

Google App Engine : How can I access sessions inside a cloud endpoint?

I have developed a standard Google App Engine backend Application for my Android client. Now, there is search functionality in the App and during one request, I plan to return 20 results but I search for more in advanced(like 100) so that for the next hit, I will just search in these records and return. So, I need a mechanism to save these 80 records so that the same user might get them quickly.
I searched for it and found out that we can enable sessions in appengine-web.xml but all the session access has been done in doPost() and doGet() while my code is entirely Google's cloud endpoints.(like Spring)
Another thing is that I would like to persist the data both inside the Datastore and some cache(like Memcache).
My end goal is storing this data across search sessions. Is there any mechanism that will allow me to do this?
The usual approach here is to provide a code value in the response which the user can send in the next request to "continue" viewing the same results. This is called a "cursor".
For example, you might store the 80 records under some random key in your cache, and then send that random key to the user as part of the response. Then, when the user makes a new request including the key, you just the records and return them.
Cookie-based sessions don't usually work well with APIs; they introduce unnecessary statefulness.

App engine project-1 trying to access BQ in project-2?

My App engine is running in project-1. I want to access the BQ present in project-2. How can i make app engine in project-1 access the BQ present in project-2?
You should request "can view" (or "can edit") permissions on the dataset of your interest. Owner of project-2 (or respective dataset) will be able to do so.
You don't need to be present on project level and in some cases it is not even appropriate - but you must have appropriate permissions on dataset level
If, by chance, you are the owner of project-2 or respective dataset - you can easily do this by following below instructions
https://cloud.google.com/bigquery/bigquery-web-ui#sharedataset
The easiest way to accomplish this is to add the default service account of "project-1" to the permissions list of "project-2":
within the cloud console go to the permissions section of project-1
select the service accounts sub tab
look for the default service account (or create a new one)
add the service account to the permissions of project-2
EDIT
You need to create your client in a fashion that uses the applications default service account. For example if you're using python it would look something like:
# Grab the application's default credentials from the environment.
credentials = GoogleCredentials.get_application_default()
# Construct the service object for interacting with the BigQuery API.
bigquery_service = build('bigquery', 'v2', credentials=credentials)
Now with your PK file you can launch the dev appserver in a fashion that the same client client will work correctly: Unable to access BigQuery from local App Engine development server

Can I have GCS private isolated buckets with a unique api key per bucket?

I'd like to give to each of my customers access to their own bucket under my GCS enabled app.
I also need to make sure that a user's bucket is safe from other users' actions.
Last but not least, the customer will be a client application, so the whole process needs to be done transparently without asking the user to login.
If I apply an ACL on each bucket, granting access only to the user I want, can I create an API key only for that bucket and hand that API key to the client app to perform GCS API calls?
Unfortunately you only have two good options here:
Have a service which authenticates the individial app according to whatever scheme you like (some installation license, a random GUID assigned at creation time, whatever) and vends GCS signed URLs, which the end user could then use for a single operation, like uploading an object or listing a bucket's content. The downside here is that all requests must involve your service. All resources would belong entirely to your application.
Abandon the "without asking the user to login" requirement and require a single Google login at install time.

Use Google's App Engine framework to read a mail and extract its attachments?

I'm developing a tool that lets an user receive some data through an email account, in the form of a regular file. The goal is to implement this:
file → email attachment → canbeanything#myapp.com → system backend copies attachment.
Can I use Google's App Engine to develop this application? I have read their documentation on handling email but I think it's bound to just the admin's account. Can you explain me the process for achieving this?
App Engine application can receive emails to a specific list of address. If my-app-id is your application then any email ending with #my-app-id.appspotmail.com will be sent to your application.
For example the following emails are valid destinations that will be received by your app :
hello#my-app-id.appspotmail.com
no-reply#my-app-id.appspotmail.com
...
Note that even if you app has a custom domain like myapp.com, the destination email address will remain in #my-app-id.appspotmail.com. You can probably circumvent this by configuring your domain's email settings to forward all emails to App Engine.
Once received by the App Engine infrastructure, the emails are POSTed to a specific URL of your app, where you can write a handler (a Servlet in Java) to process the email content and save it somewhere. Here is the Python documentation on receiving email, and the Java documentation.
Note that there probably is a limit to the size of attachments you can receive this way. I expect something along the line of 25Mo, which is GMail's attachment limit or 32Mo which is App Engine's POST request size limit.
Once you receive an email, I strongly recommend you perform the processing in a task queue, to avoid temporary issues (out of memory, faulty process) that would lead to the email being lost.
When it comes to saving the attachment, consider using Google Cloud Storage, since the Datastore is limited to 1Mb per entity.

Google AppEngine ClientId and Client Secrets

I am writing an travel itinerary app engine application which will interact with the calendars of my users. In order to manage access to my user's calendar I intend to use OAuth 2.0. I looked online for various code examples and the closest to what I am trying to acheive is (http://code.google.com/p/google-api-java-client/source/browse/calendar-appengine-sample/src/main/java/com/google/api/services/samples/calendar/appengine/server/?repo=samples). I have the following questions
1) I find that the server needs access to the application's client id and client secrets. Most of the sample code I have seen so far loads this from a local file. Does AppEngine give some API which will enable me to retrieve the client id and client secret without me having to worry about storing it ?
2) If I have to store the client secret in a secure fashion what are my options ?
3) What is the best way to store a user's access token and refresh token ?
It almost never changes, so hardcode it. It's only really loaded from a file in the sample programs so that you can get the samples running without touching the code.
See 1.
You can use the Google provided Credential class which uses a dedicated kind. Or, given that they are simply strings, you can store them as part of the User kind which your app almost certainly has to track your registered users.
As a tip, separate writing your oauth code from writing your calendar code. I would start by writing an app that only authorises, stores the refresh token, and refreshes the access token. You can test your access token using curl. Once you have that all working, then add your Calendar functionality as phase 2.

Resources