Are there plans to develop a Go client library for Microsoft Graph?

[justinbarias]

Hi

Are there plans to support Go?

Cheers

AB#7098

[MIchaelMainer]

Currently, we have no plans for a Go client. We are willing to reconsider with enough information. Looping in @funkeyfreak since he has interest in a Go Microsoft Graph client library story.

I leave this issue open in case there is other interest in this area.

[funkeyfreak]

Hello @justinbarias,

Thanks for your interest. As @MIchaelMainer stated - I am extremely interested in a go client for Microsoft Graph. Not only would this open Graph to one of the more rapidly evolving open source communities, but it would allow we here at Microsoft a chance to gain a better understanding of industry standards.

I am curious, what are the scenarios where leveraging a go client would be more preferred? I am asking for the sake of understanding your state of application - that is where you would like use a go client - so if/when a client is created, it leverages go in a way that complements your use case.

Adding @emily2zhou - a fellow go fan 👍

[justinbarias]

Hello @justinbarias,

Thanks for your interest. As @MIchaelMainer stated - I am extremely interested in a go client for Microsoft Graph. Not only would this open Graph to one of the more rapidly evolving open source communities, but it would allow we here at Microsoft a chance to gain a better understanding of industry standards.

I am curious, what are the scenarios where leveraging a go client would be more preferred? I am asking for the sake of understanding your state of application - that is where you would like use a go client - so if/when a client is created, it leverages go in a way that complements your use case.

Adding @emily2zhou - a fellow go fan 👍

Hi @funkeyfreak

Thanks for reaching out - firstly, the most immediate use case would be to allow graph to be leveraged by the Hashicorp ecosystem (terraform, for example) - which is slowly becoming the defacto standard for cloud infrastructure code tooling - which me and my team in Microsoft Consulting have started to adopt in key engagements.

The more overarching outcome is that this would reach CNCF (https://www.cncf.io/) community - where Go has unofficially been the defacto language for CNCF projects (Kubernetes, Helm, etc).

Having said that, I would love to help out and contribute if/when this gets accepted as a backlog item.

Cheers Justin

[darrelmiller]

@justinbarias Have you had scenarios where customers would be interested in using Terraform for deploying M365 services?

I'm not sure it would be quite as straightforward to create Terraform providers for Graph as it is for Azure ARM due to the fact that Graph uses server generated Ids for many resources and does not provide idempotent creation like Azure does. It is definitely something that is important for us to monitor to see where and when customers are moving from using scripting for deployment to things like Terraform.

Would a xPlat command line client for interacting with Graph help to fill the gap for Kubernetes and Helm?

[rrey]

Hi, since 2018 I guess things have evolved since Azure Graph API is now considered the proper API to use (the other being named Legacy). Is the Go library in your plan now ?

[chris-annino-sp]

Bumping this as I've been trying to use openapi generators against the msgraph openapi.yaml file. openapi-generator currently doesn't support anyOf, which msgraph spec uses extensively (i made comments in this issue). Another tool oapi-generator doesn't support yaml 1.2 and fails to generate with errors in this issue.

We've considered using https://github.com/yaegashi/msgraph.go or https://github.com/open-networks/go-msgraph but they aren't production ready. Our only course of action seems to be rolling our own. Help us MSGraph-SDK, you are our only hope.

[MIchaelMainer]

@chris-annino-sp This is being worked on now. https://github.com/microsoftgraph/msgraph-sdk-go

[chris-annino-sp]

Oh goodness, how did I not see this!