Functions framework refactoring

[benjaminhuo]

We need to refactor functions-framework with the following considerations:

• Function type to keep: Async, Http, CloudEvent
• Function Signature adjustment including:
  1. Add OpenFunctionContext parameter to each function type
  2. Keep the HTTP req & resp or not
• Function plugin mechanism

[benjaminhuo]

As mentioned in @tpiperatgod’s plugin proposal: https://hackmd.io/XwHWmAJwQWeCu18zQ97s_A?view= , a few concerns here:

• Do we really need to adjust all function signature to the same as func(*ofctx.OpenFunctionContext, []byte) ofctx.RetValue ?
• The input of HTTP function is different, it's more natural to keep the original signature func(w http.ResponseWriter, r *http.Request)? How the []data is composed of for a Http function?
• Can context.GetInput get all necessary HTTP parameters?
• How to handle output of HTTP function?
• besides the func(*ofctx.OpenFunctionContext, []byte) ofctx.RetValue , we might need to add func(*ofctx.OpenFunctionContext, CloudEvent) ofctx.RetValue as well

[benjaminhuo]

Another point is we might need to add a callback in the function signature?

[benjaminhuo]

It might not be proper to unify function type into one single func(*ofctx.OpenFunctionContext, []byte), the following function type should co-exist for different scenarios:

Async functions:

• func(*ofctx.OpenFunctionContext, CloudEvent)
• func(*ofctx.OpenFunctionContext, []byte)

Sync functions

• func(http.ResponseWriter, *http.Request)
• func(context.Context, cloudevents.Event)
• func(context.Context, []byte) // act as an simplified version of the previous two function types

The question is do we need to add *ofctx.OpenFunctionContext to sync functions

cloud event is becoming a standard in the serverless areas, we have to support cloud event type functions https://github.com/cloudevents/sdk-go

@tpiperatgod @wanjunlei

[benjaminhuo]

aws lambda function:

• the function context is just call ctx context.Context

  ctx context.Context: Provides runtime information for your Lambda function invocation. ctx is the variable you declare to leverage the information available via AWS Lambda context object in Go.

  https://docs.aws.amazon.com/lambda/latest/dg/golang-handler.html https://docs.aws.amazon.com/lambda/latest/dg/golang-context.html

• Valid handler signatures

  
  You have several options when building a Lambda function handler in Go, but you must adhere to the following rules:

The handler must be a function.

The handler may take between 0 and 2 arguments. If there are two arguments, the first argument must implement context.Context.

The handler may return between 0 and 2 arguments. If there is a single return value, it must implement error. If there are two return values, the second value must implement error. For more information on implementing error-handling information, see AWS Lambda function errors in Go.

The following lists valid handler signatures. TIn and TOut represent types compatible with the encoding/json standard library. For more information, see func Unmarshal to learn how these types are deserialized.

func () func () error func (TIn) error func () (TOut, error) func (context.Context) error func (context.Context, TIn) error func (context.Context) (TOut, error) func (context.Context, TIn) (TOut, error)

[benjaminhuo]

Proposal created for this : https://github.com/OpenFunction/OpenFunction/blob/main/docs/proposals/202112_functions_framework_refactoring.md

[benjaminhuo]

Close this via https://github.com/OpenFunction/functions-framework-go/pull/22