Add support for generating web applications communicating with Office 365

[waldekmastykarz]

Add support to generate scaffolding of web applications communicating with Office 365. Sample of how this could look like is available at https://github.com/waldekmastykarz/sample-generator-office365app.

[andrewconnell]

I want to punt this to @jthake ... to me this isn't an Office thing, rather it's a web app that talks to Office 365... but it needs AAD. So it would make more sense to me in a theoretical yo azure generator rather in Office. I think that's where @jthake stands, but let him comment...

[jthake]

no i totally think that this could be a yo office thing...its' office 365 api's. it'd be nice if this could be run not to just generator a standalone web application though. also if it could configure up a office add-in too. may be as a sub generator some how?

[waldekmastykarz]

For the add-ins would it work the way we discussed it in #42?

[andrewconnell]

@jthake this would be it's own subgenerator so you could run it directly with yo office:aadweb or something like that

I'd like to take one more stab at keeping this out of this generator... feel free to shoot me down:

Today this is focused on client-side solutions, such as Office Addins. The technology options are HTML / Angular. If we go with creating a web app that's going to talk to Azure AD, then are you going to start looking at what server side tech you're going to use for the web app? Please think this through... if you extend this generator with this, then what about the technology question... it's going to ask HTML / Angular. But if you're building a website to talk to AAD, are you going to build some random angular / html scaffold in it? What about the server side tech... are you going to add those questions to the existing addins and then create variants of them for each tech? You're biting off a lot...

We made a decision a while back to not worry about adding things like Python, Ruby, PhP, Node, ASP.NET MVC, ASPNET5, etc because there are generators for those things plus they add zero value to creating an addin... they are server-side technologies that would host an API or something like that to support the client side addin. We decided that you would run a generator to create one of those assets, then you'd run yo office within the same folder to sub out the addin stuff.

Sorry, but I just don't see how this issue is any different from the decision we made previously. I strongly believe this should be in a different generator... maybe yo azure. Plus, no external "customers" of this are asking for it...

Said my peace :)

[andrewconnell]

@waldekmastykarz no... none of the other subgenerators for creating addins really apply to this...

[waldekmastykarz]

@andrewconnell with the reference to #42 I meant that we implement ADAL support for add-ins as a separate technology next to Angular, HTML and manifest only. Web apps are a whole different thing.

If the advised way of developing on O365 is developing off the box, wouldn't it mean that in the future more folks will start building web apps? Theoretically these web apps could be client-only living as Angular SPAs using OAuth implicit flow to communicate with O365 but I guess time will tell how viable it is to build complete solutions and whether there is still a need for serve-side components or not.

If there is little need for this at the moment, we could also put it off for the time being and watch how things will develop.

[andrewconnell]

I don't think we can make the assumption that the advised way of developing on O365 is developing off the box... IMHO this generator shouldn't go with what the marketing wants rather what people are doing.