The common ground for all of us developers is how we used to extend SharePoint in the past. We built farm solutions, and there were pros and cons. Even though that method isn’t heavily used today, I will use it as a reference point to analyze the customization journey.
Other blogs in this series:
- Farm solutions vs. SharePoint Framework (this blog)
- SharePoint Framework challenges – part 1
- SharePoint Framework challenges – part 2
- Manual vs Automatic SPFx package analysis
Trip down memory lane
Let’s recap on how we used to create WSPs. I think we can agree that we would run .NET code on the SharePoint server, and it would use the server-side rendering. Because we are talking about the period 2006/ 2007 even until the present, you can still use them.
In the past, we didn’t have rich experiences like frameworks to do things on the client-side. Therefore, we would heavily rely on ASP.NET and server-side rendering to perform all the operations on the server-side instead.
The caveat
The upside to customizing in this way is that everything built would tightly integrate into the farm. Consequently, you could get the benefits of building timer jobs and taking part in backups as your code would run accordingly. No matter what you built, it would become an integral part of the whole farm.
However, that was also the downside. Because your code was such a big part of the farm, it could also bring it down if things went bad. Over the years, we learned the hard way at times about these commonly known issues, for example:
Memory disposal – If you didn’t dispose of an object such as a SharePoint site, you could eat up memory from the farm, eventually bringing it down. You would first see the farm slow down, then to the point where you wouldn’t see it do anything at all.
Iterating over list items – If you would iterate over items in a list (re-retrieving all items on the list), it would bog down resources.
So, we learned the do’s and don’ts in server-side code or SharePoint code to avoid the above known issues.
Fast-forward to the present time, for three years now, we have had SharePoint Framework (SPFx) available to extend both SharePoint on-premises and Online to our needs. The way you would customize both platforms are not quite comparable because there are some things that you cannot do, for example, embed JavaScript on modern pages in SharePoint Online.
If you need a long-running operation, you wouldn’t implement that in the browser. Someone might move to another page, close the tab, or browser, and the process would die.
Instead, you would probably do something like build a function app on Azure that would do the operation. You would call it out from your web part or UI part. So, you can think of SPFx as the UI piece of how you would extend SharePoint to your needs. It runs exclusively on the client-side rendering.
SPFx limitations
There are also somethings which we could call limitations, but also just some things to take into account regarding SPFx. I posed the question in my recent Rencore Webinar, which I recently delivered that you can watch on-demand. Here are some considerations the community attending felt were important.
- Conflicts in external libraries.
- Potentially making proprietary information accessible.
- Giving away business logic because the code works in-browser.
- Authentication, information protection.
- Lack of APIs to access LOB.
These are all valid concerns, and the issues vary in complexity, from lack of skills to APIs to permissions. There are multiple things to take into account alongside code quality, and poor performance, which can still bring down the tenant for the whole company.
Furthermore, it’s important to keep in mind that there is always a need to validate all of your SharePoint code because there are things that could have an impact on your SharePoint tenant regardless of the framework you use.
The solution
Theoretically, it’s quite possible to manually assess code but in practice it falls short because it doesn’t scale, is very time-consuming, and it very much depends on the experience of the individual.
As I openly state and show examples of in my webinar, I advocate Rencore’s SPCAF software. It is the only solution on the market that analyzes and assures your SharePoint code quality. You can check violations against a growing number of rulesets (including SPFx) regarding security, performance, best practices, maintainability, and supportability.
What do you think are the limitations or things to consider regarding SPFx applications in production? Please leave a comment below.
