As an SPFx TypeScript developer, you’re also a ‘full-stack’ developer!

As an SPFx TypeScript developer, you’re also a ‘full-stack’ developer!

Let’s face this reality: today as a SharePoint developer (Online or On-Premises), it has become an absolute necessity to know JavaScript since Microsoft has switched to a client-side development model with the SharePoint Framework.

TypeScript is the new black

Even though Microsoft says that is totally possible to write Web Parts in pure JavaScript without any framework, I really doubt people actually use this possibility (simply look at the number of pure JS samples in the PnP sp-dev-fx-webparts repository to understand…). So let’s be honest: TypeScript just became the main programming language for the large majority of SharePoint developers (in combination with React but this is not the purpose here).

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

Azure Functions are probably the most popular back-end service solution to combine with SPFx because of it serverless architecture and therefore its convenience. When creating an Azure Function, except ‘funky’ languages like Java or F#, which most of SharePoint developers (including me) barely know, you have basically the choice between C# or JavaScript in the list of production supported languages. Here is the situation from here:

  • 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.
  • Secondly, using pure JavaScript with Node.js can pretty rough at first glance for a non-initiated developer (typically, a former ‘old fashion’ SharePoint developer with almost zero notion with Node.js except ‘npm’). JavaScript is good but it can become a real mess for large projects due to lack of handy features like C# of TypeScript offer.

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! »…

At first glance, this might be a good option but first, this option is still experimental, and second, I don’t think Microsoft will push further with this way. Why? Because TypeScript is a metalanguage of, guess what…JavaScript, which is already a supported language in GA for functions.

It means , you can transpile your TypeScript code in JavaScript by your own and that’s precisely what I want to demonstrate here.

JavaScript ≠ browser only

Don’t think JavaScript is limited to front-end components and only used to build apps running the browser. Like Azure Functions tell you, with Node.js, it is not the case anymore. Like SPFx components, you can use tools like Webpack to transpile your TypeScript code to JavaScript.

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 sample TypeScript function that can be executed in a plain JavaScript Azure Function thanks to Webpack and Node.js.
  • 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!

+ There are no comments

Add yours

This site uses Akismet to reduce spam. Learn how your comment data is processed.