Engineering Insights | BJSS

Typescript 101 for Platform Engineers

Written by Mike Peachey | Oct 6, 2021 4:23:57 PM

I have just finished creating my first TypeScript project: Orgtomate. Before this project, I had an approximate grasp of JavaScript and a scant grasp of Asynchronous JavaScript, and I won't pretend that I have a total grasp of it now, but certainly enough to confidently deliver functional async modules. I chose JavaScript because, after a lot of experience throwing together lambda functions for automating AWS platform tasks in both JavaScript and Python, I know that there is a big difference in performance and significantly less overhead in trying to execute code in parallel in JavaScript than using Python's multiprocessing library. That and the fact that I’m personally not the biggest fan of Python in the first place. 

Having begun in JavaScript, it was suggested to me that I consider using TypeScript instead. I initially regarded this suggestion as a stretch goal I wouldn't have the opportunity to consider, however, I took the plunge, am very pleased that I did, and wish I had been using it from the beginning. It turns JavaScript from something powerful but dangerous into something that has the fortitude to challenge the other contenders in the space. Type-safety matters and it's available for JavaScript! 

However, with a new language, even as an extension of an existing one, comes a lot to learn, and a new ecosystem of supporting development tools. With all of these being open-source tools, with competing options and limited documentation and cohesion, it takes a long time to decide upon which tools to use and how to bring them together to construct a functional development process for a project. I've been through this process from scratch, with all the most modern options to choose from, and thought that perhaps others might benefit from the lessons I've learned, the choices I've made, and the results I've produced. 

I'm especially interested in looking at this from a Platform Engineering and a NodeJS perspective, which can be very different from approaches needed for browser-based application development. It is my hope that I can start to foster some love for JavaScript and TypeScript in the platform engineering community so that it is not a scary prospect when it is the right tool for a job. This is especially relevant in AWS Lambda functions, where every microsecond of execution and every megabyte of RAM is chargeable, and regularly executing JavaScript is going to cost less over a lot of functions over long periods of time – which all add up. 

I am going to presume a basic grasp of JavaScript from the reader, but only so far as knocking together a couple of functions to do some simple tasks with the odd required library. I am also going to try to use terms and references that are familiar to people who have not been doing JavaScript and TypeScript development for years - wording things for the purpose of understanding, rather than a scientific explanation of programming concepts. So many questions and answers available on the internet involve someone new to the language asking a simple question to try to understand what they're dealing with and being bombarded with answers that are no clearer than the documentation the asker was struggling to grasp. I prefer a Russell Stannard/Carl Sagan approach.