| 💥 ALERT!! |
|---|
| This repo will soon be relocating to GoogleCloudPlatform as we better organize these code samples! Stay tuned as more info is coming soon. |
This is the repo for a set of sample apps and corresponding codelabs (self-paced, hands-on tutorials) demonstrating how to call Google APIs from Google Cloud serverless compute platforms (App Engine, Cloud Functions, Cloud Run). More on each platform below. Working wth Cloud APIs differs from non-Cloud Google APIs, so that is how the samples are organized. The common aspect of all of sample apps is that they can be run locally or deployed to any of the 3 platforms without code changes (all done in configuration).
- App Engine (standard environment) — source-based application deployments (app-hosting in the cloud; "PaaS")
- App Engine is for users who wish to deploy a traditional (but not containerized) web stack (LAMP, MEAN, etc.) application direct from source code.
- Cloud Functions — cloud-hosted functions or microservices ("FaaS"), possibly event-driven
- If your app is relatively simple, is a single function, or perhaps some event-driven microservice, Cloud Functions may be the right platform for you.
- Cloud Run — fully-managed serverless container-hosting in the cloud ("CaaS") service
- If your apps are containerized or you have containerization as part of your software development workflow, use Cloud Run. Containers free developers from any language, library, or binary restrictions with App Engine or Cloud Functions.
A "fourth" product, App Engine flexible environment, which sits somewhere between App Engine standard environment and Cloud Run, is out-of-scope for these sample apps at this time.
When running on App Engine or Cloud Functions, the Python runtime supplies a default web server (gunicorn), but for Node.js, Express.js was selected. No default servers are available at all for Cloud Run, so Python developers can either run the Flask development server (default) or self-bundle gunicorn (per your configuration). All Node.js deployments specify Express.js.
These samples were inspired by a user's suboptimal experience trying to create a simple App Engine app using a Cloud API. This was followed-up with the realization that there aren't enough examples showing users how to access non-Cloud Google APIs from serverless, hence those samples.
The table below outlines the development languages, supported versions, deployments tested, and selected web frameworks (whose bundled development servers are used for running locally):
| Language | Versions | Deployment | Framework |
|---|---|---|---|
| Python | 2.7 | local, cloud | Flask |
| Python | 3.6+ | local, cloud | Flask |
| Node.js | 10, 17 | local | Express.js |
| Node.js | 10, 12, 14, 16 | cloud | Express.js |
While many Google APIs can be used without fees, use of GCP products & APIs is not free. Certain products do offer an "Always Free" tier which you have to exceed in order to be billed. Reference any relevant pricing information linked below before doing so.
When enabling services, you may be asked for an active billing account which requires a financial instrument such as a credit card. Reference relevant pricing information before doing so. While Cloud Functions and Cloud Run share a similar Always Free tier and pricing model, App Engine is slightly different.
Furthermore, deploying to GCP serverless platforms incur minor build and storage costs. Cloud Build has its own free quota as does Cloud Storage. For greater transparency, Cloud Build builds your application image which is then sent to the Cloud Container Registry, or Artifact Registry, its successor; storage of that image uses up some of that (Cloud Storage) quota as does network egress when transferring that image to the service you're deploying to. However you may live in region that does not have such a free tier, so be aware of your storage usage to minimize potential costs. (You may look at what storage you're using and how much, including deleting build artifacts via your Cloud Storage browser.)
More specific cost information for each sample is available in their respective README files.
Each app has its own testing battery; refer to each sample's folder to learn about implemented tests.