TypeScript is the new black
So, as a good SharePoint zealot, you’ve learned TypeScript like Microsoft and the community told you. So what next? If it is not a problem to create Web Parts, extensions, etc. thanks to the huge quantity of samples and tutorials, it can be complicated when it comes to enhance these front-end components with back-end services…
Azure Function is the new orange
- Firstly, not everyone has C# skills, especially in the case where developers use exclusively SPFx in their day-to-day tasks. In the new SharePoint development landscape, in my opinion, you’re absolutely fine with the TypeScript/PowerShell couple for a large majority of projects. Personally, I didn’t use C# since the end of the old full trust solutions model almost 3 years ago and frankly, I don’t want to invest in this language. Why? First because, the ratio “time consumed to master C# at a good level to deliver code with good quality”/”frequency where I effectively will use my C# skills in my SharePoint day-to-day job” is simply not worth it. Then, the development tool chain is completely different which forces me to learn even more tools. I prefer concentrate deeply over one or two languages instead knowing multiples ‘averagely’. That’s why I use TypeScript to build front-end components and PowerShell to do the scripting and provisioning stuffs with PnP and that’s enough for what I have to do.
If you are in one of these situations, in real life, either you will have to add a dedicated back-end developer to your team, who already knows C# or Node.js, or, if not possible (re)-learn C# or Node.js to build your service knowing it is not your main language. In any solution, it means a downtime in your project.
“But wait, you didn’t mention the “TypeScript” option in Azure Functions!”…
Because I didn’t want to use plain JS or C#, I’ve started from a very good article showing how to setup a TypeScript project to run with Azure Function and it made my day. From here, I decided to build my own boilerplate project to kick start my TypeScript Azure Functions.
The project can be retrieved here:
Typically, in this project you get:
- A example of how to deal with multiple configurations per environment (JSON files, etc.).
- Setup for function tests.
- Setup to debug locally (code and tests) within Visual Studio Code and Postman/SPFx.
- Deployment script to integrate with CI tools using Azure CLI and azure-functions-core-tools.
TypeScript functions, ok ,but not in every case.
For some cases, C# is still the preferred way especially if we talk about provisioning with PnP (especially with site designs). PowerShell is also here but currently in experimental mode. I personally use PowerShell for this purpose but at my own risk I admit even if I guess Microsoft will keep this language in the future along Azure Automation RunBooks.
TypeScript Azure functions are a good candidates when the logic involves to manipulate subsequent web services for data light processing. A perfect example of this is the new feature I released for the react-search-refiners SPFx sample: process search box user query with NLP tools like Microsoft LUIS and Text Analytics. With this approach, I don’t expose sensitive information like API keys in my SPFx Web Parts and I also reduce the overall complexity of my front-end components!
As a conclusion, you can use TypeScript for both front-end and back-end services with only a minimal setup so don’t hesitate to use this boilerplate to start your SharePoint projects!