Drop #113 (2022-10-04): Ameliorating Rust Withdrawal
Rustpad; D3 Graph Theory; CO2.js
Far too many days have passed since we've had some Rust-fueled topics, but we'll limit it to just one, this time.
Real-time editors have a surprising history, dating "all the way" back to 1968. There were many desktop and fledgling "cloud" offerings back in the early 2000's, many of which went on to inspire collaborative creation services we now take as commonplace. They all operate with some "operational transformation" idiom of some kind, and many readers likely use some form of collaborative editor every day.
Everything is better with a little Rust inside, and Rustpad [GH] is no exception. I'll let the developers 'splain it:
Rustpad is an efficient and minimal open-source collaborative text
editor based on the operational transformation algorithm. It lets users
collaborate in real time while writing code in their browser. Rustpad is
completely self-hosted and fits in a tiny Docker image, no database required.
The server is written in Rust using the warp web server framework and the operational-transform library. We use wasm-bindgen to compile text operation logic to WebAssembly code, which runs in the browser. The frontend is written in TypeScript using React and interfaces with Monaco, the text editor that powers VS Code.
Architecturally, client-side code communicates via WebSocket with a central server that stores in-memory data structures. This makes the editor very fast, allows us to avoid provisioning a database, and makes testing much easier. The tradeoff is that documents are transient and lost between server restarts, or after 24 hours of inactivity.
Despite the "no database required" posit, there is support for a persistence layer if you tweak some environment variables when deploying Rustpad.
The Docker image is minuscule (~5MB) and, if you're learning Rust or want to become more Rust proficient, the codebase is definitely worth your time to peruse.
There's a great interview with Rustpad's creator, Eric Zhang (@ekzhang1), over at Console (which is another newsletter you should consider subscribing to):
D3 Graph Theory
If you're game to learn/brush up your graph theory skills, or dig into some very practical D3 code, D3 Graph Theory [GH] should be added to your bookmark catalog and TODO list.
This resource is a "front-end project aimed at anyone who wants to learn graph theory. It provides a quick and interactive introduction to the subject," and covers the following topics:
Vertices and Edges
Order and Size of a Graph
Degree of a Vertex
Degree Sequence of a Graph
Complete Bipartite Graph
Open vs Closed Walks
Spanning Tree of a Graph
In other words, you'll get a thorough introduction to foundational graph theory concepts through visually captivating, interactive examples, and have scads of working, clean D3 code to riff from in your projects.
Sporadically, the internet isn't such a bad place after all.
You are, right now, using electricity to read this edition of the newsletter. First, the ⚡️ that powers your glowing rectangle, then the ⚡️ that powers whatever network devices that connect your glowing rectangle to the internet, then the ⚡️ all the intermediary network devices consume to move your request/response pairs to the server(s) that shove the bits back your way. Said servers have similar ⚡️ idioms on their end. According to some research, the data transfer layer accounts for ~14% of the web's total energy consumption.
We're, generally, oblivious to this as we go about our very useful meme postings and twitter rants, but we don't have to be. If the likes of Google, Microsoft, and Amazon can help enable carbon transparency at an infrastructure level, we certainly can do so for apps.
It's fairly easy to set up in a frontend project, and can do more than just estimate the carbon impact of data transfer on the internet. There are functions that use The Green Web Foundation’s greencheck API to determine if a website or domain is hosted on a green web host.
The library uses something called the Sustainable Web Design model which "segments the system (the internet) into four parts – data centres, networks, end-user devices, and device production. Based on the bytes passed to it, the Sustainable Web Design model calculates the energy used by each part of the system."
The docs are straightforward to follow, and offer many ways to report/communicate the impacts each visit has on carbon emissions.
I used the Website Carbon Calculator (link goes to full report) to generate the banner image for my blog site, which uses the same algorithms the JS library does.
This could be a fun way to differentiate your site from others, and may also be something you can use to make better technology/hosting decisions.
The death toll from Ian is now at or over 100. Hit up FEMA’s Ian site if you or folks you know in the region have been impacted. ☮