This is quite a resource coming from a team whose API has always impressed me.

If APIs are designed well, developers will love them, and can become the most creative innovators using your APIs. They will invest heavily, and sometimes even become evangelists for your APIs. We also value a developer’s time and the resource they risk by building on our platform. Bad API design leads to a bare minimum adoption, and even frustration. Bad APIs become a liability for a company.

They share their six design principles as well as the process they follow through to implementation. A must-read for anyone who designs and builds APIs for fun and profit.

Jonathan Chang and Michael Deng share all the details of the systems required to deploy at Slack.

Deploys require a careful balance of speed and reliability. At Slack, we value quick iteration, fast feedback loops, and responsiveness to customer feedback. We also have hundreds of engineers who are trying to be as productive as possible. Keeping to these values while growing as a company means continual refinement of our deployment system.

Following up on designing delightful dark themes, I wanted to share this post from Kyle Stetz on the frontend engineering strategy for building Slack’s dark mode on desktop.

As is usually the case with large codebases, finding an implementation that works is only half the battle; gracefully changing infrastructural code and educating engineers on how to use new tools accounts for much of what we do when working on new capabilities of the product. Working in a large engineering organization — especially within a rapidly growing company — means that every change needs to consider the momentum and roadmaps of many other teams. The overarching question for this project was: how can we build sustainable and maintainable support for themes?

The Ship of Theseus is a thought experiment that considers whether an object that has had each of its pieces replaced one-by-one over time is still the same object when all is said and done. If every piece of wood in a ship has been replaced, is it the same ship? If every piece of JavaScript in an app has been replaced, is it the same app? We sure hoped so, because this seemed like the best course of action.

Fascinating look behind the scenes at both the process of rewriting a massively used application and the particular architectural choices made along the way. The approach used was at once incremental and all-encompassing, rewriting a piece at a time into a gradually growing “modern” section of the application that utilized React and Redux. And the results? 50% reduction of memory use and 33% improvement in load time… not too shabby.

Slack chose webpack as their build tool, but it wasn’t fast enough.

Our build took minutes, not seconds: a far cry from the sub-second concatenation we were used to. Slack’s web teams deploy up to 100 times on any given work day, so we felt this increase acutely.

Let’s just say they went to work and came up with several techniques to speed up the build process.

webpack is a fantastic, versatile, tool that does not need to cost the earth. These techniques have helped us reduce our median build time from 170 to 17 seconds and, while they have done much to improve the deployment experience for our engineers, they are by no means a complete work.

You’ll definitely want to read this if you’d like to know how Slack handles their job queue.

Robustly handling billions of tasks in milliseconds using Kafka and Redis.

On our busiest days, the system processes over 1.4 billion jobs at a peak rate of 33,000 per second. Job execution times range from a few milliseconds to (in some cases) several minutes.

Also, check out The Changelog #278 — we talked about blockchains and databases at OSCON, including a conversation with Tague Griffith on Redis.