Open joshdcar opened 6 years ago
Accepting contributions for sure! We don't have Teams bindings on the roadmap right now, but let's make it happen!
We need to set up a proper contribution guide to help make things easier, but the gist of things is the same as other Functions projects. Feel free to use the issue tracking here for anything you run into process-wise in addition to functionality.
@ConnorMcMahon is the go-to for some of the core infrastructure pieces on this project.
Glad to help in any way we can.
Thanks for info @mattchenderson ! Looking forward to contributing! I may be able to assist on the contribution guide as well - Its on my list for one of my other extension projects as well so I may be able to fill two needs with one deed there. More to come :)
@joshdcar, that sounds great! Let us know if you need anything to help get you up to speed!
Thanks @mattchenderson and @ConnorMcMahon ! I'm putting together a post on some of my thoughts on the new Teams bindings so I can get some feedback as opposed to just diving into development just to ensure we're on the same page. I'll post it up in the next few days here. Thanks!
@ConnorMcMahon , @mattchenderson I've been spending some time with the code base this weekend and I've found that the underlying Microsoft.Graph .net library does not yet support teams (which to be fair is still in preview and they don't support betas). It does however have the ability to make requests to the underlying Graph API via the client library for unsupported requests (https://github.com/microsoftgraph/msgraph-sdk-dotnet/blob/dev/docs/overview.md).
What would be the preference here:
Go ahead with the Teams feature and we'll just make direct Graph API requests via the .Net Microsoft Graph Client Library framework. We will bake in our own Teams models based on guidance from the Microsoft Graph .Net (https://github.com/MIchaelMainer/msgraph-sdk-dotnet-beta)
Let's wait for Microsoft.Graph to support Teams and we'll pick another graph feature (Calendar, Planner, Onenote, SharePoint, @etc) or enhance some existing features (any outstanding feature requests?).
I ran into similar issues with a recent extension I'm building for Cognitive Services and decided on just using the REST endpoints instead of the library so I wouldn't have any dependency (there was an old Oxford library that was deprecated and a new one still in preview) and I don't regret it but it was obviously more work.
Let me know your thoughts!
As long as we isolate the REST calls in a way that allows us to write tests and potentially replace the direct REST calls with the client SDK in the future, I have no problems with the first option.
Following the *Client.cs
pattern already in the codebase has been a fairly successful way for me to mock the Graph API and test as much of the business logic as possible.
@ConnorMcMahon thanks for the clarification. Sounds like a plan to me.
Hi folks - just wanted to update you since it had been a little while. I got to a late start on this due to a busy schedule but I did get started on this and hoping to have a working preview in the next couple weeks if my schedule holds out :)
I'm a big fan of the Microsoft Graph and Azure Functions so I think these extensions are a fabulous pairing. Is the project accepting community contributions? I was considering looking for ways to contribute, possibly with some additional bindings (I'd love to see some Teams bindings) but I wasn't sure if there were already internal updates in the works or an existing backlog? Love to hear some feedback.
Thanks!
Josh