Are you curious about what's involved in building custom apps for #MicrosoftTeams... WITHOUT Power Apps or the SharePoint Framework? Subscribe to my 9-day FREE email course "Microsoft Teams App Development OnRamp" to learn not just WHAT, but HOW you can create apps for Teams! vtns.io/ytvecoursemsteamsonramp-CdlFs7CITyE
It does depends. If its a quick solution with a small data set and collaboration required, then I'll consider power apps. Otherwise, I have to go full stack because of the lack of development ability.
Exactly… it always depends on the situation. Quick & small 1-off solution would be good for a PowerApps, but for something more robust… not sure PA is a good option. But… IT DEPENDS
VERY quick... I'm seeing more & more customers port their more LOB/enterprise style Power Apps => Teams apps for cost, performance, and management reasons. The biggest surprise they see is how much faster a Teams app is... not because it's fast, but because model-driven Power Apps are just SO SLOW!
@Andrew_Connell 100% agree with you. My concern is moving into team at some point ms likely to charge everyone at some point. They did this with powerapps we free then started to segment it as more people moved that way
For our intranet, we use a non-Microsoft web publishing cloud solution by Igloo for our main News and Blogs for each department.. So a Power App, like a Leave Form, embedded in an iFrame is the preferred option, though we have to click a button to authenticate for the app to load. Can an SPFx or SPA be embedded in an iFrame on and authenticate via SSO?
Sort of... that's called an isolated web part (rendered with an IFRAME vs. a DIV as it normally is), but Microsoft announced those would be retired (learn more in my video: ruclips.net/video/4cMLFpWB6bs/видео.html). As for SSO, you'll need for force a popup authentication as no reputable modern auth provider (Microsoft/Google/etc) allows their login prompts to be IFRAMEd and thus, subject to click jacking attacks.
I work in a team that develops apps with SPFx. However, instead of writting them as SPAs (or single part app page), these apps are composed of multiple webparts and one site extension (usually for a custom navigation). The approach is to place each webpart in a site page, so eventually the app is formed with mutiple pages with only one webpart in every page. Is this a common/good approach?
I wouldn't say its a good/bad approach, because it all depends on the scenario and project. For the way you describe it, giving the user/customer the ability to compose the experience, that's a great approach. But so is an approach where a single SPA has a more predictable and defined layout. Just nice we have multiple options.
@@Andrew_Connell Ok, I see your point. However, it still bugs me a little bit is the (self-imposed) constraint of one webpart per page, almost mimicing an old fashioned web app. Nonetheless, it has worked so far, so I guess it's a valid approach too. Thanks for the reply, Andrew :)
@@darom_96 That's the point though... a SPA is _JUST_ a web part that takes up the whole page. This way, there's no new concept developers have to learn. They can leverage their existing web part knowledge to create a web part that's either just a small box on a page, or takes up the entire content area of the page as a SPA.
Are you curious about what's involved in building custom apps for #MicrosoftTeams... WITHOUT Power Apps or the SharePoint Framework? Subscribe to my 9-day FREE email course "Microsoft Teams App Development OnRamp" to learn not just WHAT, but HOW you can create apps for Teams! vtns.io/ytvecoursemsteamsonramp-CdlFs7CITyE
I use both Power Platform and SPFx
Thanks for sharing! What kinds of things do you think are best suited for a Power App/Platform or for using the SharePoint Framework?
It does depends. If its a quick solution with a small data set and collaboration required, then I'll consider power apps. Otherwise, I have to go full stack because of the lack of development ability.
Exactly… it always depends on the situation. Quick & small 1-off solution would be good for a PowerApps, but for something more robust… not sure PA is a good option. But… IT DEPENDS
as a consultant i use powerapps but starting to use spfx more as its next to no cost. PA cost quick rack up.
VERY quick... I'm seeing more & more customers port their more LOB/enterprise style Power Apps => Teams apps for cost, performance, and management reasons. The biggest surprise they see is how much faster a Teams app is... not because it's fast, but because model-driven Power Apps are just SO SLOW!
@Andrew_Connell 100% agree with you. My concern is moving into team at some point ms likely to charge everyone at some point. They did this with powerapps we free then started to segment it as more people moved that way
@Andrew_Connell 100% agree with you. My concern is moving into team but at some point ms likely to charge everyone at some point
For our intranet, we use a non-Microsoft web publishing cloud solution by Igloo for our main News and Blogs for each department..
So a Power App, like a Leave Form, embedded in an iFrame is the preferred option, though we have to click a button to authenticate for the app to load.
Can an SPFx or SPA be embedded in an iFrame on and authenticate via SSO?
Sort of... that's called an isolated web part (rendered with an IFRAME vs. a DIV as it normally is), but Microsoft announced those would be retired (learn more in my video: ruclips.net/video/4cMLFpWB6bs/видео.html).
As for SSO, you'll need for force a popup authentication as no reputable modern auth provider (Microsoft/Google/etc) allows their login prompts to be IFRAMEd and thus, subject to click jacking attacks.
@@Andrew_Connell I see, just watched other video. Thanks for the prompt response Andrew.
❤
Thanks for liking the video!
I work in a team that develops apps with SPFx. However, instead of writting them as SPAs (or single part app page), these apps are composed of multiple webparts and one site extension (usually for a custom navigation). The approach is to place each webpart in a site page, so eventually the app is formed with mutiple pages with only one webpart in every page. Is this a common/good approach?
I wouldn't say its a good/bad approach, because it all depends on the scenario and project. For the way you describe it, giving the user/customer the ability to compose the experience, that's a great approach. But so is an approach where a single SPA has a more predictable and defined layout. Just nice we have multiple options.
@@Andrew_Connell Ok, I see your point. However, it still bugs me a little bit is the (self-imposed) constraint of one webpart per page, almost mimicing an old fashioned web app. Nonetheless, it has worked so far, so I guess it's a valid approach too. Thanks for the reply, Andrew :)
@@darom_96 That's the point though... a SPA is _JUST_ a web part that takes up the whole page. This way, there's no new concept developers have to learn. They can leverage their existing web part knowledge to create a web part that's either just a small box on a page, or takes up the entire content area of the page as a SPA.