Cloud Functions can be written in Node.js, Python, Go, Java, .NET, and Ruby programming languages, and are executed in language-specific runtimes. The Cloud Functions execution environment varies by your chosen runtime. The runtime overview pages provide further details about each runtime environment:
- Node.js 8 Runtime
- Node.js 10 Runtime
- Python Runtime
- Go Runtime
- Java Runtime
- .NET Runtime
- Ruby Runtime
Types of Cloud Functions
There are two distinct types of Cloud Functions: HTTP functions and event-driven functions. Event-driven functions can be either background functions or CloudEvent functions, depending on which Cloud Functions runtime they are written for.
HTTP functions
You invoke HTTP functions from standard HTTP requests. These HTTP requests wait for the response and support handling of common HTTP request methods like GET, PUT, POST, DELETE and OPTIONS. When you use Cloud Functions, a TLS certificate is automatically provisioned for you, so all HTTP functions can be invoked via a secure connection.
For details, see Writing HTTP Functions.
Example:
Node.js
Python
Go
Java
C#
Ruby
Event-driven functions
Cloud Functions uses event-driven functions to handle events from your Cloud infrastructure, such as messages on a Pub/Sub topic, or changes in a Cloud Storage bucket.
Cloud Functions supports two sub-types of event-driven functions:
As explained below, the sub-type you use will be governed by the runtime your function targets.
Background functions
Event-driven functions written for the Node.js, Python, Go, and Java Cloud Functions runtimes are known as background functions. See Writing Background Functions for more details.
Example:
Node.js
Python
Go
Java
C#
Ruby
CloudEvent functions
Event-driven functions written for the .NET Cloud Functions runtime are known as CloudEvent functions. See Writing CloudEvent Functions for more details.
Example:
C#
Structuring source code
In order for Cloud Functions to find your function's definition, each runtime has structuring requirements for your source code. In general, we recommend splitting up large, multi-function codebases into smaller per-function ones to reduce code complexity and per-function dependency counts.
Node.js
For the Node.js runtimes, your function's source code must be exported from a
Node.js module, which Cloud Functions loads using a require()
call.
In order to determine which module to load, Cloud Functions uses the
main
field in your package.json
file. If the main
field is not specified,
Cloud Functions loads code from index.js
.
For example, the following configurations of source code are valid:
A single
index.js
located in your function's root directory that exports one or more functions:. └── index.js
An
index.js
file that imports code from afoo.js
file and then exports one or more functions:. ├── index.js └── foo.js
An
app.js
file that exports one or more functions, with apackage.json
file that contains"main": "app.js"
:. ├── app.js └── package.json
Python
For the Python runtime, your function's entrypoint must be defined in a Python
source file named main.py
located in the functions's root directory.
For example, the following configurations of source code are valid:
A single
main.py
file in your function's root directory that defines one or more functions:. └── main.py
A
main.py
file with arequirements.txt
file that specifies dependencies:. ├── main.py └── requirements.txt
A
main.py
file that imports code from a local dependency:. ├── main.py └── mylocalpackage/ ├── __init__.py └── myscript.py
Go
For the Go runtime, your function must be in a Go package at the root of your
project. Your function cannot be in package main
. Sub-packages are only
supported when using Go modules.
For example, the following configurations of source code are valid:
A package at the root of your project that exports one or more functions:
. └── function.go
A package at the root of your project that imports code from a sub-package and exports one or more functions:
. ├── function.go ├── go.mod └── shared/ └── shared.go
A package at the root of your project with a sub-directory that defines a
package main
:. ├── cmd/ | └── main.go └── function.go
Java
For the Java runtime, you should create a top-level function directory
containing a src/main/java/
sub-directory and a pom.xml
file. We recommend
putting tests in a src/test/java/
sub-directory.
. ├── pom.xml └── src/ ├── main/ | └── java/ | └── MyFunction.java └── test └── java/ └── MyFunctionTest.java
If your .java
file declares a package (for example, functions
), your
directory hierarchy would look like this:
. ├── pom.xml └── src/ ├── main/ | └── java/ | └── functions/ | └── MyFunction.java └── test/ └── java/ └── functions/ └── MyFunctionTest.java
If your function is defined in a specific package as most Java functions are, it
must be specified as part of your --entry-point
value at
deployment time.
Grouping multiple functions
If you are thinking of grouping multiple functions into a single project, be aware that every function may end up sharing the same set of dependencies. But some of the functions may not need all of the shared dependencies.
We recommend putting each function in its own top-level directory as shown
above, with its own src/main/java
sub-directory and pom.xml
file.
This approach minimizes the number of dependencies required for a particular
function, which in turn reduces the amount of memory your function needs.
Furthermore, separate functions make it easier to specify a single function when running functions locally via the Functions Framework. This can be helpful for local development and testing.
C#
For the .NET runtime, you can structure your projects as you would any other .NET source code.
When you use the templates to create a C# function, it creates the following files at the same level in the file system:
- A function source file named
Function.cs
. - A project file with a
.csproj
extension.
For example:
. ├── Function.cs └── HelloHttp.csproj
The same pattern applies when you use the templates to create F# and Visual Basic
functions. For F#, the file name is Function.fs
, and the project file has the
extension .fsproj
. For Visual Basic, the file name is CloudFunction.vb
,
and the project file has the extension .vbproj
.
However, these patterns are just conventions, not requirements. You can structure your code as you would any other regular C#, F#, or Visual Basic project, which can contain multiple source files, resources and so on.
Additionally, if you only implement a single function per project, you can start hosting that function without specifying the function name, which can make local development and debugging simpler.
Ruby
For the Ruby runtime, your function's entrypoint must be defined in a Ruby
source file named app.rb
located in the function's root directory.
Additionally, dependencies, including at least the
functions_framework
gem, must be listed in a
Gemfile
and associated Gemfile.lock
file also located
in the function's root directory. Your function can include additional Ruby
files in the root directory or subdirectories.
For example, the following configurations of source code are valid:
. ├── Gemfile ├── Gemfile.lock └── app.rb . ├── Gemfile ├── Gemfile.lock ├── app.rb └── lib/ └── my_class.rb
Specifying dependencies
You specify your function's dependencies idiomatically based on the runtime you are using. For more details, see the appropriate page:
- Specifying dependencies in Node.js
- Specifying dependencies in Python
- Specifying dependencies in Go
- Specifying dependencies in Java
- Specifying dependencies in C#
- Specifying dependencies in Ruby
Naming Cloud Functions
Cloud Functions have a "name" property that is set at deploy time, and once set, it cannot be changed. The name of a function is used as its identifier and it must be unique within a region. See the deployment documentation for details.
Next steps
- Deploying Cloud Functions.
- Calling HTTP Functions.
- Calling Cloud Storage Trigger Functions.
- Calling Pub/Sub Trigger Functions.
- HTTP Functions Tutorial.
- Cloud Functions with Cloud Storage Tutorial.
- Cloud Functions with Pub/Sub Tutorial.