Google Code offered in: 中文 - English - Português - Pусский - Español - 日本語
Currently, Google App Engine allows you to write your applications with Python 2.5. For security reasons, some Python modules written in C are disabled in our system. Also, since Google App Engine doesn't support writing to disk, some libraries that support this and other functionalities are only partially enabled. Our developer documentation gives a good overview of the Python runtime environment. A description and full reference of Python libraries that are disabled or partially disabled can be found here.
Additionally, your website templates can include Javascript along with your HTML. Among other things, this allows you to write webservices that make use of Ajax web development techniques.
Google App Engine allows most python web frameworks to be uploaded with your application. These web frameworks should need little or no modification to work with our system. For your convenience, Django v0.96.1 is included with the Google App Engine SDK.
Absolutely! Even if you don't yet have a Google App Engine account you can always download our SDK and start development.
During the Google App Engine preview release, each developer can create 3 applications with their Google App Engine administrator account. At this time, once an application is created, you may not delete the application.
If you would like to disable an existing application, first you should remove the handlers from your application's app.yaml
file. Add a handler to your app.yaml file that points to a non-existent file. Using appcfg.py, upload the blank app.yaml
file. Once the new app.yaml
file is uploaded, your application will be disabled.
Please see our Terms of Service if you have questions on what kind of content is allowed with Google App Engine.
Your Google App Engine dashboard in the Admin Console has six graphs that give you a quick visual reference of your system usage. The information displayed in these graphs gives you a 6 hour snap shot of resource consumption per second. Here are a list of the graphs you will see in the Admin Console:
The Popular URIs give you a list of the most frequently visited URIs of your application in the past 24 hours. Since each application runs on a single domain, the domain information is omitted from the URI. The column on the left hand side lists the URI path starting with the most popular URI. The corresponding information in the right hand column lists the total number of requests for that URI.
If any error occurs when attempting to load a URI, our system records that error. We then show the URIs that record the most errors in the past 24 hrs in the admin console. In addition to showing the total number of errors, we include the percentage of errors as the ratio of errors at the URI to total requests of that URI.
Applications who have not included a favicon.ico file may notice the URI /favicon.ico
on the list of errorful URIs. Favicon.ico is a file that is requested by a user's web browser when it attempts to load the page. Favicon.ico is your website's icon, and is typically displayed in the user's browser URL bar, next to the web address of your site.
For your application, favicon.ico should be a static image. You can upload a favicon.ico file with your application, and in your app.yaml file configure your application to serve the image when the url /favicon.ico is requested. Below is an example entry in your app.yaml
file for /favicon.ico
. We assume you include the favicon.ico file in the directory path static/images
:
- url: /favicon.ico static_files: static/images/favicon.ico upload: static/images/favicon.ico
GQL is a query language that is used with the Google App Engine datastore. It uses a SQL like syntax to retrieve entire entities from your application's datastore, and includes the ability to filter on properties, specify the sorting order of the results, and limit the number of entities returned. The full GQL language reference can be found here.
If you run a query that filters on multiple entity properties, or orders your entities in a descending order, you will need an index for that query. You must have an index for every query of that kind that you run with your application. The datastore index for a query maintains and updates a list of keys sorted in the manner that the query specifies to allow speedy access to the data in your datastore. A full explanation of datastore indexes can be found in our documentation.
When you develop your application with Google App Engine SDK, every query you run automatically gets indexed when necessary. If you thoroughly test your application before uploading it to your website, all of the indexes your application will need will be included in your application's index.yaml
file. You may manually add indexes to index.yaml
if you find a query that was not covered by your development testing. Our documentation includes information on how to write indexes for your application.
Our Users API allows you to authenticate users with Google Accounts, or against user accounts of your own Google Apps domain. These two forms of authentication can not be used with the same application. Please read our article on how to configure your application to authenticate against a Google Apps domain.
With our Users API, when your application requests a user sign in, they are directed to a Google sign in page where the user enters his or her username and password. The user is returned to your website, and the user credentials are communicated to your application through the Users property.
A small percentage of native C python modules, and subsets of native C python modules are not available with Google App Engine. A full list detailing native C Python module support can be found here. The disabled modules fall in to the following categories:
Please keep in mind that third party packages which use any of the above features will not function with Google App Engine (packages such as mysql, postgresql, etc).
An app may be disabled if it fails to abide by our Terms and Conditions. Additionally, during the preview release, if an application is found to be using an inordinate amount of system resources due to a bug or other issue leading to inefficient resource usage, we may disable the app so that the developer can fix the development issues using our development SDK before re-enabling the application on Google App Engine.
In our preview release, we have system quotas that limit the amount of traffic and system resources. You can read the entire breakdown of system quotas here. The current quota, with typical system usage, allows approximately 5 million pageviews a month. Though to prevent your application from running through its quota too quickly, we allocate quota over the course of the month.
With this system, if your application consumes a lot of quota in a short amount of time, you will be able to start serving traffic again more quickly. If your system runs out of system resources on a regular basis, you may apply for an increase in your quota. Please note that we do not guarantee that your quota will be increased, and each application is considered on an individual basis.
To report an application that is in violation of the Google App Engine Terms and Condition, please contact us. We will determine if the application is in violation, and if necessary, contact the application's developer over the violation.
The dev_appserver is designed for local testing and disallows external connections by default. You can override this using the -a <hostname> flag when running it, but doing so is not recommended because the SDK has not been hardened for security and may contain vulnerabilities.
Google App Engine does its best to serve gzipped content to browsers that support it. Taking advantage of this scheme is automatic and requires no modifications to applications.
We use a combination of request headers (Accept-Encoding, User-Agent) and response headers (Content-Type) to determine whether or not the end-user can take advantage of gzipped content. This approach avoids some well-known bugs with gzipped content in popular browsers. To force gzipped content to be served, clients may supply 'gzip' as the value of both the Accept-Encoding and User-Agent request headers. Content will never be gzipped if no Accept-Encoding header is present.