SOLVED

Develop using SharePoint Add-In or SPFX Framework?

Brass Contributor

Hello All,

I am in need of some opinions with respect to a method that makes sense to focus when developing apps for Sharepoint Online.

I have been tasked with building a customized Leave application for the company i'm employed with. It's also important that the application is built in a way that will cater not only for internal use but to eventually end up on the app store for other companies to use. Since SPFx came along, i've been torn between choosing to build a SharePoint Add-in or get on board with SPFx development. While I understand the differences between both, I assumed that SharePoint Add-ins would eventually become 'buggy' in some form or fashion with the change to the modern SPO, so I ended up going with learning and building this application with SPFx and React.js. I have not been able to find any talk about Add-ins at the time since the trending topic is around SPfx development, therefore, I assumed that I chose the right path :sad:.

So far, I have accomplished building out multiple web parts: each having their own purpose, from representing data from Sharepoint lists and displaying a form for data intake. In the end, I have created a sort of dashboard look and feel to the Leave application I have been trying to accomplish. However, this method is not in a form where it can be packaged up and "Added-on" to another SharePoint environment seamlessly.

After spending a lot of time on SPFx, I've now realized that it makes more sense to build a Sharepoint Hosted Add-In to cater for the functionality of this application and the scope that we are aiming for. However, I'm very fearful that in the time I would spend learning how to build an Add-in, it would all crumble due to unforeseen errors that may occur in the new modern sharepoint environment. I am also guessing that Add-in development does not cater for modern pages and I will be using classic pages and web parts. This can allow limited functionality as well, and this also influenced my decision in choosing SPFx.

Has anyone recently and successfully developed an Add-In that works well with this new environment? If so, can you shed some light on my fears? All opinions and recommended resources to point in the right direction are welcomed...

Thank you very much!

3 Replies
best response confirmed by Yarrah (Brass Contributor)
Solution

Dear @Yarrah

I can tell you that you are in the right place, so keep calm and talk together :)

SPFX solutions can be published on any tenant, however, it is essential to follow best practices, but this applies to any approach.

 

SPFx Custom Webpart (dashboard?) must be deployed to tenant app catalog or site collection app catalog https://docs.microsoft.com/en-us/sharepoint/dev/general-development/site-collection-app-catalog

 

SharePoint assets like lists, content type could be deployed already using SPFx https://docs.microsoft.com/en-us/sharepoint/dev/spfx/web-parts/get-started/provision-sp-assets-from-... or using PnP Provisioning engine https://docs.microsoft.com/en-us/sharepoint/dev/solution-guidance/introducing-the-pnp-provisioning-e...

 

SharePoint Add-ins approach is already valid, in my opinion, it depends on technology approach, architectural approach and dependency, and isolation/security (governance) level you want to introduce in your solution.

 

What I understand, your SPFx WebParts and Custom lists is a classic solution you could easily deploy and maintain everywhere, in every tenant.

 

If you can, please check already Implement Continuous Integration and Continuous deployment using Azure DevOps  https://docs.microsoft.com/en-us/sharepoint/dev/spfx/toolchain/implement-ci-cd-with-azure-devops in order to understand the great potential of how to build a solution with SPFx and deploy/maintain it according to the DevOps principles.

Cheers,
Federico

Hey @Federico Porceddu ,

 

Thank you for your assurance :happyface:!  I feel better now lol. Also, thank you very much for your tips, they are pointing me in the right direction as I have been using them as a checklist before deploying to production.

 

Hi @Yarrah 

you're welcome :)

Feel free to ask the community what you need :)

Cheers,

Federico

1 best response

Accepted Solutions
best response confirmed by Yarrah (Brass Contributor)
Solution

Dear @Yarrah

I can tell you that you are in the right place, so keep calm and talk together :)

SPFX solutions can be published on any tenant, however, it is essential to follow best practices, but this applies to any approach.

 

SPFx Custom Webpart (dashboard?) must be deployed to tenant app catalog or site collection app catalog https://docs.microsoft.com/en-us/sharepoint/dev/general-development/site-collection-app-catalog

 

SharePoint assets like lists, content type could be deployed already using SPFx https://docs.microsoft.com/en-us/sharepoint/dev/spfx/web-parts/get-started/provision-sp-assets-from-... or using PnP Provisioning engine https://docs.microsoft.com/en-us/sharepoint/dev/solution-guidance/introducing-the-pnp-provisioning-e...

 

SharePoint Add-ins approach is already valid, in my opinion, it depends on technology approach, architectural approach and dependency, and isolation/security (governance) level you want to introduce in your solution.

 

What I understand, your SPFx WebParts and Custom lists is a classic solution you could easily deploy and maintain everywhere, in every tenant.

 

If you can, please check already Implement Continuous Integration and Continuous deployment using Azure DevOps  https://docs.microsoft.com/en-us/sharepoint/dev/spfx/toolchain/implement-ci-cd-with-azure-devops in order to understand the great potential of how to build a solution with SPFx and deploy/maintain it according to the DevOps principles.

Cheers,
Federico

View solution in original post