One of the things I took out of 2021 was a CLI written in Rust to reimplement the "deploy" command from the Netlify CLI, aptly named netlify_deploy. I will have a post at a later date going into detail the process of building it and the roadblocks I hit as I progressed. For now, I wanted to highlight some main points on why I decided to remake this in Rust.
The Netlify CLI does a lot and for good reason. On top of allowing to deploy built sites, it also can run a dev-mode completely locally that can test out the site and even serverless functions without having to push a new deploy up to the public. With that in the case of it being a node.js application, that comes with the downside of a very large node_modules folder. At the time of writing, it ends up being just over 400MB of just the CLI and it's dependencies (not including anything from your actual project). Projects like pnpm could reduce the file size on your computer by only having one instance, but in my setup, I wanted to push it down to be as lean as possible. At the moment, the binary that is outputted ends up being about 5MB large.
With that, my CLI doesn't have anything beyond the functionality available through running "netlify deploy". It doesn't have support for auto-uploading serverless functions. There's no dev-mode to test the site locally, but for my usecases it gets the job done. With this scope I was also able to get a taste of asynchronous Rust which I was less familiar with at the time and with the Tokio Runtime stabilizing at the end of 2020 with their 1.0 release, it definitely was a good time to do it.
As well, The main location I ran the CLI was within GitHub Actions workflows. Due to some of my sites where I wanted to rebuild very frequently, I would quickly run out of build minutes from Netlify, but their CLI offers the same deployment logic so I could run the build on a separate platform and then give them the final assets. Through 2021 as I sped my builds up for this site, I noticed that the Netlify CLI was becoming a bottleneck as it does a lot of bootstrapping behind the scenes that has come from it being continually built over the course of many years. By moving to a CLI that had a reduced total functionality, the time of running netlify_deploy was reduced to under a second of runtime where previously it took between 10-20 seconds even for small deploys.
Finally, recreating the tool gave a lot of insights into what is going on behind the scenes when a deploy is actually made. I will go into this more in detail in the walkthrough post, but in general, Netlify's API efficiently manages deploys so rather than redeploying every asset every build, it will only upload new / modified assets. Taking a step and looking behind the curtain in this case allowed an appreciation for the work that has been done to make the CLI and a reminder that open source tools provide a way to examine something that for most may be just a black box but doesn't have to be.