Question/Feature Idea: Separating out the node 'engine' from the cli

[pmatthews05]

Looking through the code of M365 CLI, it is an awesome amount of node code that calls into Graph, SharePoint, OneDrive etc.

Is it possible to import the M365 cli into my Node Azure functions (for example) and use the engine part that makes the calls, and not worry about the CLI, as the CLI is just calling the node functions that performs the work. If so, could someone provide a blog post/example how to log in and call something in a node azure function project?

Alternatively, I understand this would be a bit of work, but have you thought about separating the project into 2, where you have the M365 Core, and the M365 CLI. The M365 CLI would depend on the M365 Core, but it would allow people to use the M365 Core in their node projects without needing to re-invent the wheel. Similar how PNP Powershell and PNP Core are split.

Happy to be shot down, but just an idea.

[waldekmastykarz]

Hey @pmatthews05, how would that differ from the existing SDKs like the Microsoft Graph SDK or PnPjs?

[pmatthews05]

I agree that those are two useful SDKs.

However, playing devils advocate, if they are so great to use, why are they not being used in M365 Cli? ;)

As you are not using them, I would say that you have written things slightly different, such as throttling handling, token refreshes, etc which from what I can see with the Graph SDK and PnPjs I would need to implement myself. (I am new to Node, and haven't really used Graph SDK or PnPjs)

If Microsoft changes something in the underlying REST calls, and I'm using M365 for my scripts, Graph SDK for Azure Functions and PnPjs for my SPFX, that's 3 different products I'm waiting on to get updated.

Maybe it's just my coding preference, I like to follow a pattern, and although Graph SDK, and what you have done within the Cli gives similar results, it's two different ways of doing it, which I need to learn and understand in a evergreen changing environment.

[waldekmastykarz]

The reason we're not using SDKs is that neither one does everything that we need. If we were to use SDKs, we'd likely end up using multiple SDKs as well as executing manual calls for other things. This would complicate our code base making it hard to reuse code and having to deal with multiple ways of testing our code. I think we're special in that sense, because we touch so many APIs across the different services. So it's not that we've built our own way of calling APIs because we think the SDKs miss something. Our motives are selfish in that sense and meant for us to have a consistent codebase and simplify work for our contributors.

If you're building solutions in Node, in 99% of cases you should be well off by using either the Microsoft Graph SDK or PnPjs (depending on what exactly is that you need in your application). I don't think that we could add any value in that sense.