Do not expose protobuf to the bindings

[pragnagopa]

Tracking issue to investigate decoupling azure.functions and azure.functions.worker.

Use type annotations if the function expects a custom type such as
singnalRConnectionInfo which is not a basic type like: string or byte[] or rich binding type defined in azure-functions-python-library

def main(req: func.HttpRequest, connectionInfo: signalRConnectionInfo) -> func.HttpResponse:
    return func.HttpResponse(connectionInfo)

Python worker needs to convert the input data sent by the functions host to the type requested by the function. This is the goal of issue #135 as well.

Here is the flow for the above example:

• User function includes reference to the library where signalRConnectionInfo is defined
• On function invocation, host sends input data as String/Json
• Python worker examines the type annotation and converts input data to type signalRConnectionInfo
• If type conversion fails, throw error

[asavaritayal]

Brainstorming item, not currently scheduled. @pragnagopa to update objective and problem statement.

[pragnagopa]

Azure/azure-functions-host#3140

[maiqbal11]

@pragnagopa, @asavaritayal, reviving this old thread because I've got some time on my hands. Work on exposing generic data types is almost finished (#66). Once that is checked in, we can potentially get rid of azure.functions altogether + the binding specific code in the language worker. Wanted to lay out some top-of-mind benefits and drawbacks.

Benefits:

1. Having some rich data types helps with getting users started instead of them having to deal with raw data in the form of bytes, strings etc.
2. This would be a big breaking change and would require re-education about how to use these types.
3. It should also help with intellisense but that's a work in progress.

Drawbacks:

1. I see the comments at Decouple dependency between language worker and their SDKs azure-functions-host#3140 and it makes sense that we might not want to be in the business of owning these libraries and maintaining them. We've been bitten by this before: Python DateTime Error For Blob Events In Event Grid Azure Function #269. Arguably, if this had been handled by the appropriate SDK, we wouldn't have to worry about it. This adds engineering complexity as we need to maintain/service a different code base - aspects of which are not in our control if something about the format of the messages changes, for example.

A middle way might be just to leave things as they are right now and not expand the set of rich data types that we provide. We'd still maintain the ones we have but that's been okay so far.

Lemme know what you think!