Story: OpenFaaS SDKs for each language

[alexellis]

Story: OpenFaaS SDKs for each language

Since this will be a big piece of work and potentially involve multiple languages and features, I'm calling it a Story.

Use-case

We have been asked 4-5 times in as many months for an SDK for Java which can be used to integrate with the OpenFaaS API. This aligns well with the developers-first value of OpenFaaS and the mission: Serverless Functions Made Simple.

The official Java template also has code bundled for its entrypoint and function model, which need to be submitted to jCenter or similar so that enterprise developers can get a good experience in their IDEs.

Whilst invoking a function, or listing functions can be as simple as creating a HttpClient and then doing a GET / POST, this can and should be made easier. It may be that some developers within an organisation write OpenFaaS functions, other teams should be able to integrate with those easily and this story is part of that.

Coverage

I think this is my priority order:

• JavaScript (nodejs)
• Java
• .NET Core 2.x
• Go (perhaps this can be vendored from the proxy package of the faas-cli)
• Python

Followed by PHP, Ruby, Perl and potentially some others.

Other concerns

I think we need a degree of similarity between each SDK and we also need to be idiomatic in each language as far as possible.

I wanted to highlight some prior work that may be useful for reference from the CNCF Serverless Working Group for CloudEvents; JavaScript, Java, Go - .NET also exists.

These packages should be distributed through the appropriate channels as Ruby Gems, NPM modules and jCenter for JARs.

[burtonr]

What would the SDK do?

I'm thinking we would essentially copy the functionality in the CLI that interacts with already deployed functions: invoke, list, describe, etc...

I don't think it would make much sense to include the new or template functionality since that's more operational, not functional.

Should the SDK enable users to interact with functions that are deployed, or would it also permit the users to alter the OpenFaaS deployment by deploying, building, etc?

[alexellis]

We could start with?

1. Invoke (top priority, and no auth needed)
2. CRUD (auth required)
3. List / deploy via Function Store

Another way of looking at it - what would a team in your org need to do in order to integrate with your OpenFaaS functions that were developed in your team?

Alex

[ewilde]

• Read secrets?

[martindekov]

So by SDK we want to have means to communicate with the API through code?

I am asking as my first impression was SDK for developing providers, like we do with the faas-provider but on different languages.

Otherwise I am interested in taking a part of this.

[stefanprodan]

Has anyone tried using Swagger to generate the API clients?

[LucasRoesler]

@stefanprodan we use swagger and the code generator here at work and .... it leaves a lot to be desired, unfortunately. But, I think our spec is relatively simple and straightforward, so it might actually be good enough.

[alexellis]

Given how awful the generated SDK I saw for Java was, and how simple our API is, I would recommend a first class implementation in each language.

[viveksyngh]

I think these SDKs will be useful if we someone is building something and orchestrating openfaas system's API rather than using our CLI or UI. For invoking the deployed function the http client code will be relatively simple, do we need an SDK for that ?

[haozibi]

Hello, I want to ask about the progress of the SDK, I should be able to help in the code.

[alexellis]

@haozibi

As far as I am aware, nobody in the community - whether end-users, regular contributors or otherwise has worked on this.

I would like to see some discussion and consensus on design and how we will keep the SDKs consistent across several languages.

Your input is welcome on this issue.

[zcourts]

I've just started working on a Java client. I'm not a huge fan of the generated client either but it does cover a lot of the boiler plate so what I'm doing is providing what I think is a nicer API but it ultimately just wraps it.

I'm expecting to start testing with it later next week. Open sourcing it won't be an issue either under Apache V2, BSD, MIT or similar.

Our integration with OpenFaaS is in its infancy (migrating from internal FaaS impl.) but it's entirely programatic access so this is crucial for us. We're not the consumers of OpenFaaS our customers are so we will build, deploy and everything else programatically. I'll be interested in knowing what the community is thinking around this so we don't go off in a totally diff. direction on our own.

[briandowns]

Happy to help with a C SDK.