Applications often need to serve static files such as JavaScript, images, and CSS in addition to handling dynamic requests. Apps in the flexible environment can serve static files from a Google Cloud option like Cloud Storage, serve them directly, or use a third-party content delivery network (CDN).
Serving files from Cloud Storage
Cloud Storage can host static assets for dynamic web apps. The benefits of using Cloud Storage instead of serving directly from your app include:
- Cloud Storage essentially works as a content delivery network. This does not require any special configuration because by default any publicly readable object is cached in the global Cloud Storage network.
- Your app's load will be reduced by offloading serving static assets to Cloud Storage. Depending on how many static assets you have and the frequency of access, this can reduce the cost of running your app by a significant amount.
- Bandwidth charges for accessing content can often be less with Cloud Storage.
You can upload your assets to Cloud Storage by using the
gsutil
command line tool
or the Cloud Storage API.
The Google Cloud Client Library provides an idiomatic client to Cloud Storage, for storing and retrieving data with Cloud Storage in an App Engine app.
Example of serving from a Cloud Storage bucket
This simple example creates a Cloud Storage bucket and uploads static assets using Google Cloud CLI:
Create a bucket. It's common, but not required, to name your bucket after your project ID. The bucket name must be globally unique.
gsutil mb gs://<your-bucket-name>
Set the ACL to grant read access to items in the bucket.
gsutil defacl set public-read gs://<your-bucket-name>
Upload items to the bucket. The
rsync
command is typically the fastest and easiest way to upload and update assets. You could also usecp
.gsutil -m rsync -r ./static gs://<your-bucket-name>/static
You can now access your static assets via
https://storage.googleapis.com/<your-bucket-name>/static/...
.
For more details on how to use Cloud Storage to serve static assets, including how to serve from a custom domain name, refer to How to Host a Static Website.
Serving files from other Google Cloud services
You also have the option of using Cloud CDN or other Google Cloud storage services.
Serving files directly from your app
Serving files from your app is typically straightforward, however, there are a couple drawbacks that you should consider:
- Requests for static files can use resources that otherwise would be used for dynamic requests.
- Depending on your configuration, serving files from your app can result in response latency, which can also affect when new instances are created for handling the load.
Example of serving static files with your app
Go
The following sample demonstrates how to serve static files with your app for
Go runtime version 1.15 and earlier, and version 1.18 and later. Note that
you must update your app.yaml
to use the new version. See
Go runtime for more information
about using the new runtimes.
You can use the standard
http.FileServer
or http.ServeFile
to serve files directly from your app.
v1.18 and later
v1.15 and earlier
Java
The following sample demonstrates how to serve static files with your app for
Java runtime version 8 and version 11/17. Note that
you must update your app.yaml
to use the new version. See
Java runtime for more information
about using the new runtimes.
The Java runtime's servlet container will use your app's deployment
descriptor,
web.xml
file, to map URLs to servlets, including static assets. If you do not
specify a web.xml
, a default is used that maps everything to the default
servlet.
In this example, ./src/main/webapp/index.html
refers to a stylesheet served
from /stylesheets/styles.css
.
version 11/17
version 8
The styles.css
file is located at ./src/main/webapp/stylesheets/styles.css
.
You can explicitly configure how static files are handled in the web.xml
file.
For example, if you wanted to map requests for all files that have the .jpg
extension:
<servlet-mapping>
<servlet-name>default</servlet-name>
<url-pattern>*.jpg</url-pattern>
</servlet-mapping>
If you are using a web framework, such as Play, you will need to refer to the framework's documentation on static assets.
Node.js
The following sample demonstrates how to serve static files with your app for
Node.js runtime version 16 and earlier, and version 18 and later. Note that
you must update your app.yaml
to use the new version. See
Node.js runtime for more information
about using the new runtimes.
Most web frameworks include support for serving static files. In this sample,
the application uses the
express.static
middleware to serve files from the ./public
directory to the /static
URL.
The view refers to /static/main.css
.
The stylesheet itself is located at ./public/css
, which is served from
/static/main.css
.
Other Node.js frameworks, such as Hapi, Koa, and Sails typically support serving static files directly from the application. Refer to their documentation for details on how to configure and use static content.
PHP
The PHP runtime runs nginx
to serve your app, which is configured to serve static files in
your project directory. You must declare the document root by specifying
document_root
in your app.yaml
file:
Python
The following sample demonstrates how to serve static files with your app for Python runtime version 3.7 and earlier. For Python version 3.8 and later, see Python runtime for more information about using newer versions.
Most web frameworks include support for serving static files. In this sample,
the app uses Flask's built-in ability
to serve files in ./static
directory from the /static
URL.
The app includes a view that renders the template. Flask automatically
serves everything in the ./static
directory without additional configuration.
The template rendered by the view includes a stylesheet located at
/static/main.css
.
The stylesheet is located at ./static/main.css
.
Other Python frameworks, such as Django, Pyramid, and Bottle typically support serving static files directly from the app. Refer to their documentation for details on how to configure and use static content.
Ruby
Most web frameworks include support for serving static files.
The following sample demonstrates how to serve static files with your app for
Ruby runtime for version 3.1 and earlier, and version 3.2. Note that
you must update your app.yaml
file to use the new version. See
Ruby runtime for more information
about using the new runtimes.
Sinatra
The Sinatra web
framework serves files from the ./public
directory by default. This
app includes a view that refers to /application.css
.
The stylesheet is located at ./public/application.css
which is served
from /application.css
.
Ruby on Rails
The Ruby on Rails
web framework serves files from the ./public
directory by default. Static
JavaScript and CSS files can also be generated by the Rails asset
pipeline.
These example apps contain a layout view that include all the application stylesheets:
version 3.2
version 3.1 and earlier
version 3.2
The stylesheet itself is a .css
file located at ./public/application.css
.
version 3.1 and earlier
The stylesheet itself is a
Sass file located
at ./app/assets/stylesheets/main.css.sass
.
By default, Rails apps do not generate or serve static assets when running in production.
The Ruby runtime executes rake assets:precompile
during deployment
to generate static assets and sets the RAILS_SERVE_STATIC_FILES
environment
variable to enable static file serving in production.
.NET
The following sample demonstrates how to serve static files with your app for
.NET runtime version 3.1 and earlier, and version 6 and later. Note that
you must update your app.yaml
file to use the new version. See
.NET runtime for more information
about using the new runtimes.
version 6 and later
To enable static file serving, add:
version 3.1 and earlier
To enable static file serving, add:
Serving from a third-party content delivery network
You can use any external third-party CDN to serve your static files and cache dynamic requests but your app might experience increased latency and cost.
For improved performance, you should use a third-party CDN that supports CDN Interconnect.