functions_framework 0.6.0 → 0.10.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 67b0d5e61bb58f49adefbff9794c960438c1577b4e3d54ee5bf072b134834b71
-  data.tar.gz: 9cb295fd8ba39ea9ad5e8eab1c3055eaa18dddef5a1838cc58d7dcdb2d12fc5e
+  metadata.gz: aefd222f82f6f3b6e54e5a9fc512e20f3cad4ff9ac5dfe3ee454efbc4bf88f70
+  data.tar.gz: ba675682be6f79c8c799336c92551955ed6d2f24bcfa5ee17373cf75151897c1
 SHA512:
-  metadata.gz: 99e58e1511a97dc9e8643a034bc089f5bb4b71d5f842b507151d8728f058a3763b0f55dcd952ac71f212773e6087cb333fcfebb814a33f57cd2057fde09d6272
-  data.tar.gz: e5afdebdc20c069c247e58196d75787a8c3b3e51924b7714851006ade62dc70bce62cd9e42501528103eb41f3ffc2d6239e9dd8c6650798bdbd1693268fa431a
+  metadata.gz: 937e27e64ad65f0f4fd9888c6bc94fcace25a39e68834f37c04d9aecb407b8fa0dc5ef35f8ebc1d78e0134914241e42cc92714f9d4236dee77daae5259cd55f1
+  data.tar.gz: 9eb7d77db1a3faae5ff91cc3c365383b96a02bbc78b7e733e9a85a8752decaf5e97b93ec78665af936840f56d89de7f542439adedef9c4a0b73912c4cc9a5748

data/CHANGELOG.md

@@ -1,5 +1,40 @@
 # Changelog
 
+### v0.10.0 / 2021-06-01
+
+* ADDED: Support raw pubsub events sent by the pubsub emulator
+* FIXED: Set proper response content-type charset when a function returns a string (plain text) or hash (JSON)
+* FIXED: Properly handle conversion of non-ascii characters in legacy event strings
+
+### v0.9.0 / 2021-03-18
+
+* BREAKING CHANGE: Servers are configured as single-threaded in production by default, matching the current behavior of Google Cloud Functions.
+* FIXED: Fixed conversion of Firebase events to CloudEvents to conform to the specs used by Cloud Functions and Cloud Run.
+* FIXED: Fixed an error when reading a global set to a Minitest::Mock. This will make it easier to write tests that use mocks for global resources.
+
+### v0.8.0 / 2021-03-02
+
+* ADDED: Support for lazily-initialized globals
+
+### v0.7.1 / 2021-01-26
+
+* DOCS: Fixed several errors in the writing-functions doc samples
+* DOCS: Updated documentation to note public release of GCF support 
+
+### v0.7.0 / 2020-09-25
+
+* Now requires Ruby 2.5 or later.
+* BREAKING CHANGE: Renamed "context" hash to "globals" and made it read-only for normal functions.
+* BREAKING CHANGE: Server config is no longer passed to startup blocks.
+* ADDED: Provided a "logger" convenience method in the context object.
+* ADDED: Globals can be set from startup blocks, which is useful for initializing shared resources.
+* ADDED: Support for testing startup tasks in the Testing module.
+* ADDED: Support for controlling logging in the Testing module.
+* FIXED: Fixed crash introduced in 0.6.0 when a block didn't declare an expected argument.
+* FIXED: Better support for running concurrent tests.
+* DOCS: Expanded documentation on initialization, execution context, and shared resources.
+* DEPRECATED: The functions-framework executable is deprecated. Use functions-framework-ruby instead.
+
 ### v0.6.0 / 2020-09-17
 
 * ADDED: You can use the --version flag to print the framework version

data/README.md

@@ -1,10 +1,10 @@
-# Functions Framework [![Documentation](https://img.shields.io/badge/docs-FunctionsFramework-red.svg)](https://googlecloudplatform.github.io/functions-framework-ruby/latest) [![Gem Version](https://badge.fury.io/rb/functions_framework.svg)](https://badge.fury.io/rb/functions_framework)
+# Functions Framework for Ruby [![Documentation](https://img.shields.io/badge/docs-FunctionsFramework-red.svg)](https://googlecloudplatform.github.io/functions-framework-ruby/latest) [![Gem Version](https://badge.fury.io/rb/functions_framework.svg)](https://badge.fury.io/rb/functions_framework)
 
 An open source framework for writing lightweight, portable Ruby functions that
 run in a serverless environment. Functions written to this Framework will run
 in many different environments, including:
 
- *  [Google Cloud Functions](https://cloud.google.com/functions) *(alpha)*
+ *  [Google Cloud Functions](https://cloud.google.com/functions) *(public preview)*
  *  [Google Cloud Run](https://cloud.google.com/run)
  *  Any other [Knative](https://github.com/knative)-based environment
  *  Your local development machine
@@ -42,11 +42,11 @@ requiring an HTTP server or complicated request handling logic.
 
 ## Supported Ruby versions
 
-This library is supported on Ruby 2.4+.
+This library is supported on Ruby 2.5+.
 
 Google provides official support for Ruby versions that are actively supported
 by Ruby Core—that is, Ruby versions that are either in normal maintenance or
-in security maintenance, and not end of life. Currently, this means Ruby 2.4
+in security maintenance, and not end of life. Currently, this means Ruby 2.5
 and later. Older versions of Ruby _may_ still work, but are unsupported and not
 recommended. See https://www.ruby-lang.org/en/downloads/branches/ for details
 about the Ruby support schedule.
@@ -60,7 +60,7 @@ Create a `Gemfile` listing the Functions Framework as a dependency:
 ```ruby
 # Gemfile
 source "https://rubygems.org"
-gem "functions_framework", "~> 0.5"
+gem "functions_framework", "~> 0.10"
 ```
 
 Create a file called `app.rb` and include the following code. This defines a

data/bin/functions-framework

@@ -16,4 +16,7 @@
 
 require "functions_framework/cli"
 
+puts "WARNING: The functions-framework executable is deprecated and will be"
+puts "removed in a future version. Please use functions-framework-ruby instead."
+
 ::FunctionsFramework::CLI.new.parse_args(::ARGV).run.complete

data/docs/deploying-functions.md

@@ -31,12 +31,8 @@ Functions Framework is designed especially for functions that can be hosted on
 Cloud Functions.
 
 You can run Ruby functions on Google Cloud Functions by selecting the `ruby26`
-runtime. This runtime uses a recent release of Ruby 2.6. Support for other
-versions of Ruby may be added in the future.
-
-> **Note:** Ruby support on Cloud Functions is currently in limited alpha.
-> It is not yet suitable for production workloads, and support is best-effort
-> only. Access is currently limited to selected early-access users.
+runtime or `ruby27` runtime to use a recent release of Ruby 2.6 or Ruby 2.7.
+Support for Ruby 3.0 is forthcoming.
 
 ### Deploying and updating your function
 
@@ -64,7 +60,7 @@ Then, issue the gcloud command to deploy:
 ```sh
 gcloud functions deploy $YOUR_FUNCTION_NAME \
     --project=$YOUR_PROJECT_ID \
-    --runtime=ruby26 \
+    --runtime=ruby27 \
     --trigger-http \
     --entry-point=$YOUR_FUNCTION_TARGET
 ```
@@ -90,7 +86,7 @@ and above, set `FUNCTION_LOGGING_LEVEL` to `WARN` when deploying:
 
 ```sh
 gcloud functions deploy $YOUR_FUNCTION_NAME --project=$YOUR_PROJECT_ID \
-  --runtime=ruby26 --trigger-http --source=$YOUR_FUNCTION_SOURCE \
+  --runtime=ruby27 --trigger-http --source=$YOUR_FUNCTION_SOURCE \
   --entry-point=$YOUR_FUNCTION_TARGET \
   --set-env-vars=FUNCTION_LOGGING_LEVEL=WARN
 ```
@@ -125,7 +121,7 @@ Dockerfile that you can use as a starting point. Feel free to adjust it to the
 needs of your project:
 
 ```
-FROM ruby:2.6
+FROM ruby:2.7
 WORKDIR /app
 COPY . .
 RUN gem install --no-document bundler \
@@ -151,8 +147,8 @@ command may ask you for permission to enable the Cloud Build API for the project
 if it isn't already enabled.
 
 Because you provide your own Docker image when deploying to Cloud Run, you can
-use any version of Ruby supported by the Functions Framework, from 2.4 through
-2.7.
+use any version of Ruby supported by the Functions Framework, from 2.5 through
+3.0.
 
 ### Deploying an image to Cloud Run
 

data/docs/overview.md

@@ -8,7 +8,7 @@ The Functions Framework is an open source framework for writing lightweight,
 portable Ruby functions that run in a serverless environment. Functions written
 to this Framework will run in many different environments, including:
 
- *  [Google Cloud Functions](https://cloud.google.com/functions) *(alpha)*
+ *  [Google Cloud Functions](https://cloud.google.com/functions) *(public preview)*
  *  [Google Cloud Run](https://cloud.google.com/run)
  *  Any other [Knative](https://github.com/knative)-based environment
  *  Your local development machine
@@ -46,11 +46,11 @@ requiring an HTTP server or complicated request handling logic.
 
 ## Supported Ruby versions
 
-This library is supported on Ruby 2.4+.
+This library is supported on Ruby 2.5+.
 
 Google provides official support for Ruby versions that are actively supported
 by Ruby Core—that is, Ruby versions that are either in normal maintenance or
-in security maintenance, and not end of life. Currently, this means Ruby 2.4
+in security maintenance, and not end of life. Currently, this means Ruby 2.5
 and later. Older versions of Ruby _may_ still work, but are unsupported and not
 recommended. See https://www.ruby-lang.org/en/downloads/branches/ for details
 about the Ruby support schedule.
@@ -64,7 +64,7 @@ Create a `Gemfile` listing the Functions Framework as a dependency:
 ```ruby
 # Gemfile
 source "https://rubygems.org"
-gem "functions_framework", "~> 0.5"
+gem "functions_framework", "~> 0.10"
 ```
 
 Create a file called `app.rb` and include the following code. This defines a

data/docs/testing-functions.md

@@ -165,3 +165,53 @@ class MyTest < Minitest::Test
   end
 end
 ```
+
+## Testing startup tasks
+
+When a functions server is starting up, it calls startup tasks automatically.
+In the testing environment, when you call a function using the
+{FunctionsFramework::Testing#call_http} or
+{FunctionsFramework::Testing#call_event} methods, the testing environment will
+also automatically execute any startup tasks for you.
+
+You can also call startup tasks explicitly to test them in isolation, using the
+{FunctionsFramework::Testing#run_startup_tasks} method. Pass the name of a
+function, and the testing module will execute all defined startup blocks, in
+order, as if the server were preparing that function for execution.
+{FunctionsFramework::Testing#run_startup_tasks} returns the resulting globals
+as a hash, so you can assert against its contents.
+
+If you use {FunctionsFramework::Testing#run_startup_tasks} to run the startup
+tasks explicitly, they will not be run again when you call the function itself
+using {FunctionsFramework::Testing#call_http} or
+{FunctionsFramework::Testing#call_event}. However, if startup tasks have
+already been run implicitly by {FunctionsFramework::Testing#call_http} or
+{FunctionsFramework::Testing#call_event}, then attempting to run them again
+explicitly by calling {FunctionsFramework::Testing#run_startup_tasks} will
+result in an exception.
+
+There is currently no way to run a single startup block in isolation. If you
+have multiple startup blocks defined, they are always executed together.
+
+Following is an example test that runs startup tasks explicitly and asserts
+against the effect on the globals.
+
+```ruby
+require "minitest/autorun"
+require "functions_framework/testing"
+
+class MyTest < Minitest::Test
+  include FunctionsFramework::Testing
+
+  def test_startup_tasks
+    load_temporary "app.rb" do
+      globals = run_startup_tasks "my_function"
+      assert_equal "foo", globals[:my_global]
+
+      request = make_get_request "https://example.com/foo"
+      response = call_http "my_function", request
+      assert_equal 200, response.status
+    end
+  end
+end
+```

data/docs/writing-functions.md

@@ -53,7 +53,7 @@ require "functions_framework"
 
 FunctionsFramework.http "request_info_example" do |request|
   # Include some request info in the response body.
-  "Received #{request.method} from #{request.url}!\n"
+  "Received #{request.request_method} from #{request.url}!\n"
 end
 ```
 
@@ -68,7 +68,7 @@ require "functions_framework"
 
 FunctionsFramework.http "logging_example" do |request|
   # Log some request info.
-  request.logger.info "I received #{request.method} from #{request.url}!"
+  request.logger.info "I received #{request.request_method} from #{request.url}!"
   # A simple response body.
   "ok"
 end
@@ -111,7 +111,7 @@ dependency on Sinatra in your `Gemfile`:
 
 ```ruby
 source "https://rubygems.org"
-gem "functions_framework", "~> 0.5"
+gem "functions_framework", "~> 0.10"
 gem "sinatra", "~> 2.0"
 ```
 
@@ -197,67 +197,239 @@ FunctionsFramework.http "error_reporter" do |request|
 end
 ```
 
-## Shared resources
-
-Generally, functions should be self-contained and stateless, and should not use
-or share any global state in the Ruby VM. This is because serverless runtimes
-may spin up or terminate instances of your app at any time, and because a
-single instance may be running multiple functions at a time in separate threads.
-
-However, it is sometimes useful to share a resource across multiple function
-invocations that run on the same Ruby instance. For example, you might establish
-a single connection to a remote database or other service, and share it across
-function invocations to avoid incurring the overhead of re-establishing it
-for every function invocation.
-
-When using a shared resource, it is important to keep three things in mind:
-
- 1. **The shared resource should be thread-safe.** This is because serverless
-    runtimes such as Google Cloud Functions may run multiple functions at a time
-    in separate threads.
-
- 2. **Use `FunctionsFramework.on_startup` to initialize shared resources.**
-    Do not initialize a shared resource at the top level of your app. This is
-    because serverless runtimes may load your files (and thus execute any Ruby
-    code at the top level) in a build/deployment environment that may not be
-    equipped to support the resource. Instead, initialize resources in a
-    `FunctionsFramework.on_startup` block, which the Functions Framework will
-    call only just before starting a server.
-
-    For example:
-
-    ```ruby
-    require "functions_framework"
-
-    # This local variable is lexically shared among all blocks.
-    storage_client = nil
-
-    # Do not create the storage client here. This may run during deployment
-    # when, e.g., your storage credentials are not accessible.
-    #   require "google/cloud/storage"
-    #   storage_client = Google::Cloud::Storage.new # <- may fail
-
-    # Use an on_startup block to initialize the shared client.
-    # This block runs only when the framework is starting an actual server,
-    # and is guaranteed to complete before any functions are executed.
-    FunctionsFramework.on_startup do
-      require "google/cloud/storage"
-      storage_client = Google::Cloud::Storage.new
-    end
-
-    # The storage_client is shared among all function invocations
-    FunctionsFramework.http "storage_example" do |request|
-      bucket = storage_client.bucket "my-bucket"
-      file = bucket.file "path/to/my-file.txt"
-      file.download.to_s
-    end
-    ```
-
- 3. **There is no guaranteed cleanup hook.** The Functions Framework does not
-    provide a guaranteed way to register a cleanup task. You can register a
-    `Kernel.at_exit` task, but remember that it is possible for the Ruby VM to
-    terminate without calling it. It is strongly recommended that you use
-    resources that do not require "cleanup".
+## The runtime environment
+
+A serverless environment may be somewhat different from server-based runtime
+environments you might be used to. Serverless runtimes often provide a simpler
+programming model, transparent scaling, and cost savings, but they do so by
+controlling how your code is managed and executed. The Functions Framework is
+designed around a "functions-as-a-service" (FaaS) paradigm, which runs
+self-contained stateless functions that have an input and a return value. It's
+important to understand what that means for your Ruby code in order to get the
+most out of a cloud serverless product.
+
+For example, multithreading is a core element of the Functions Framework. When
+you write functions, you should assume that multiple executions may be taking
+place concurrently in different threads, and thus you should avoid operations
+that can cause concurrency issues or race conditions. The easiest way to do
+this is to make your functions self-contained and stateless. Avoid global
+variables and don't share mutable data between different function executions.
+
+Additionally, a serverless runtime may throttle the CPU whenever no actual
+function executions are taking place. This lets it reduce the CPU resources
+used (and therefore the cost to you), while keeping your application warmed up
+and ready to respond to new requests quickly. An important implication, though,
+is that you should avoid starting up background threads or processes. They may
+not get any CPU time during periods when your Ruby application is not actually
+executing a function.
+
+In the sections below, we'll discuss a few techniques and features of the
+Functions Framework to help you write Ruby code that fits well into a
+serverless paradigm.
+
+### Startup tasks
+
+It is sometimes useful to perform one-time initialization that applies to many
+function executions, for example to warm up caches, perform precomputation, or
+establish shared remote connections. To run code during initialization, use
+{FunctionsFramework.on_startup} to define a _startup task_.
+
+```ruby
+require "functions_framework"
+
+FunctionsFramework.on_startup do |function|
+  # Perform initialization here.
+  require "my_cache"
+  MyCache.warmup
+end
+
+FunctionsFramework.http "hello" do |request|
+  # Initialization will be done by the time a normal function is called.
+end
+```
+
+Startup tasks are run once per Ruby instance during cold start -- that is,
+after the Ruby VM boots up but before the framework starts receiving requests
+and executing functions. You can define multiple startup tasks, and they will
+run in order, and are guaranteed to complete before any function is executed.
+
+The block is optionally passed the {FunctionsFramework::Function} representing
+the function that will be run. You code can, for example, perform different
+initialization depending on the {FunctionsFramework::Function#name} or
+{FunctionsFramework::Function#type}.
+
+**In most cases, initialization code should live in an `on_startup` block
+instead of at the "top level" of your Ruby file.** This is because some
+serverless runtimes may load your Ruby code at build or deployment time (for
+example, to verify that it properly defines the requested function), and this
+will execute any code present at the top level of the Ruby file. If top-level
+code is long-running or depends on runtime resources or environment variables,
+this could cause the deployment to fail. By performing initialization in an
+`on_startup` block instead, you ensure it will run only when an actual runtime
+server is starting up, not at build/deployment time.
+
+```ruby
+require "functions_framework"
+
+# DO NOT perform initialization here because this could get run at build time.
+#   require "my_cache"
+#   MyCache.warmup
+
+# Instead initialize in an on_startup block, which is executed only when a
+# runtime server is starting up.
+FunctionsFramework.on_startup do
+  # Perform initialization here.
+  require "my_cache"
+  MyCache.warmup
+end
+
+# ...
+```
+
+Because startup tasks run during cold start, they could have an impact on your
+function's startup latency. To mitigate this issue, it is possible to run parts
+of your initialization lazily, as described below in the section below on
+[lazy initialization](#Lazy_initialization).
+
+### The execution context and global data
+
+When your function block executes, the _object context_ (i.e. `self`) is set to
+an instance of {FunctionsFramework::Function::Callable}. Each function
+invocation (including functions that might be running concurrently in separate
+threads) runs within a different instance, to help you avoid having functions
+interfere with each other.
+
+The object context also defines a few methods that may be useful when writing
+your function.
+
+First, you can obtain the logger by calling the
+{FunctionsFramework::Function::Callable#logger} convenience method. This is
+the same logger that is provided by the HTTP request object or by the
+{FunctionsFramework.logger} global method.
+
+Second, you can access global shared data by passing a key to
+{FunctionsFramework::Function::Callable#global}. _Global shared data_ is a set
+of key-value pairs that are available to every function invocation. By default,
+two keys are available to all functions:
+
+ *  `:function_name` whose String value is the name of the running function.
+ *  `:function_type` whose value is either `:http` or `:cloud_event` depending
+    on the type of the running function.
+
+Following is a simple example using the `logger` and `global` methods of the
+context object:
+
+```ruby
+require "functions_framework"
+
+FunctionsFramework.cloud_event "hello" do |event|
+  logger.info "Now running the function called #{global(:function_name)}"
+end
+```
+
+To avoid concurrency issues, global shared data is immutable when executing a
+function. You cannot add or delete keys or change the value of existing keys.
+However, the global data is settable during startup tasks, because startup
+tasks never run concurrently. You can use this feature to initialize shared
+resources, as described below.
+
+Using the global data mechanism is generally preferred over actual Ruby global
+variables, because the Functions Framework can help you avoid concurrent edits.
+Additionally, the framework will isolate the sets of global data associated
+with different sets of functions, which lets you run functions in isolation
+during unit tests. If you are testing multiple functions, they will not
+interfere with each other as they might if they used global variables.
+
+### Sharing resources
+
+Although functions should generally be self-contained and stateless, it is
+sometimes useful to share certain kinds of resources across multiple function
+invocations that run on the same Ruby instance. For example, you might
+establish a single connection to a remote database or other service, and share
+it across function invocations to avoid incurring the overhead of
+re-establishing it for every function invocation.
+
+The best practice for sharing a resource across function invocations is to
+initialize it in a {FunctionsFramework.on_startup} block, and reference it from
+global shared data. (As discussed above, the best practice is to initialize
+shared resources in a startup task rather than at the top level of a Ruby file,
+and to use the Functions Framework's global data mechanism rather than Ruby's
+global variables.)
+
+Here is a simple example:
+
+```ruby
+require "functions_framework"
+
+# Use an on_startup block to initialize a shared client and store it in
+# the global shared data.
+FunctionsFramework.on_startup do
+  require "google/cloud/storage"
+  set_global :storage_client, Google::Cloud::Storage.new
+end
+
+# The shared storage_client can be accessed by all function invocations
+# via the global shared data.
+FunctionsFramework.http "storage_example" do |request|
+  bucket = global(:storage_client).bucket "my-bucket"
+  file = bucket.file "path/to/my-file.txt"
+  file.download.to_s
+end
+```
+
+Importantly, if you do share a resource across function invocations, make sure
+the resource is thread-safe, so that separate functions running concurrently in
+different threads can access them safely. The API clients provided by Google,
+for example, are thread-safe and can be used concurrently.
+
+Also of note: There is no guaranteed cleanup hook. The Functions Framework does
+not provide a way to register a cleanup task, and we recommend against using
+resources that require explicit "cleanup". This is because serverless runtimes
+may perform CPU throttling, and therefore there may not be an opportunity for
+cleanup tasks to run. (For example, you could register a `Kernel.at_exit` task,
+but the Ruby VM may still terminate without calling it.)
+
+### Lazy initialization
+
+Because startup tasks run during cold start, they could have an impact on your
+function's startup latency. You can mitigate this by initializing some globals
+_lazily_. When setting a global, instead of computing and setting the value
+directly (e.g. constructing a shared API client object directly), you can
+provide a block that describes how to construct it on demand.
+
+Here is an example using the storage client we saw above.
+
+```ruby
+require "functions_framework"
+
+# This startup block describes _how_ to initialize a shared client, but
+# does not construct it immediately.
+FunctionsFramework.on_startup do
+  require "google/cloud/storage"
+  set_global :storage_client do
+    Google::Cloud::Storage.new
+  end
+end
+
+# The first time this function is invoked, it will call the above block
+# to construct the storage client. Subsequent invocations will not need
+# to construct it again, but will reuse the same shared object.
+FunctionsFramework.http "storage_example" do |request|
+  bucket = global(:storage_client).bucket "my-bucket"
+  file = bucket.file "path/to/my-file.txt"
+  file.download.to_s
+end
+```
+
+The block will not be called until a function actually attempts to access the
+global. From that point, subsequent accesses of the global will return that
+same shared value; the block will be called at most once. This is true even if
+multiple functions are run concurrently in different threads.
+
+Lazy initialization is particularly useful if you define several different
+functions that may use different sets of shared resources. Instead of
+initializing all resources eagerly up front, you could initialize them lazily
+and run only the code needed by the function that is actually invoked.
 
 ## Structuring a project
 
@@ -271,12 +443,14 @@ and methods that assist in the function implementation.
 By convention, the "main" Ruby file that defines functions should be called
 `app.rb` and be located at the root of the project. The path to this file is
 sometimes known as the **function source**. The Functions Framework allows you
-to specify an arbitrary source, but suome hosting environments (such as Google
+to specify an arbitrary source, but some hosting environments (such as Google
 Cloud Functions) require it to be `./app.rb`.
 
 A source file can define any number of functions (with distinct names). Each of
 the names is known as a **function target**.
 
+Following is a typical layout for a Functions Framework based project.
+
 ```
 (project directory)
 |
@@ -296,13 +470,16 @@ the names is known as a **function target**.
 ```ruby
 # Gemfile
 source "https://rubygems.org"
-gem "functions_framework", "~> 0.5"
+gem "functions_framework", "~> 0.10"
 ```
 
 ```ruby
 # app.rb
 require "functions_framework"
-require_relative "lib/hello"
+
+FunctionsFramework.on_startup do
+  require_relative "lib/hello"
+end
 
 FunctionsFramework.http "hello" do |request|
   Hello.new(request).build_response
@@ -317,7 +494,7 @@ class Hello
   end
 
   def build_response
-    "Received request: #{request.method} #{request.url}\n"
+    "Received request: #{@request.request_method} #{@request.url}\n"
   end
 end
 ```