Reinventing how the world does work inevitably creates a lot of data. Each year, Slack’s scale has increased and the volume of data ingested and stored has kept pace. To make it possible to understand relationships within our data, we’ve invested heavily in an automated data lineage framework. This facilitates producer/consumer coordination, improves risk mitigation, impact analysis, and better execution of data programs here at Slack.

More than five years ago, we launched the Slack Platform, giving developers an easy way to build apps in Slack and publish them in our App Directory. Today, millions of users bring their work into…

A deep-dive in how we built an eventual consistency data model to predict Slack Connect invites at Slack by smart classification system for email domains.

We use Dagger heavily in the Slack Android app for compile-time dependency injection. It’s powerful, flexible, supports basic Kotlin idioms, and allows for advanced dependency injection patterns with less boilerplate. It’s not without its sharp edges though. It slows down our builds with kapt, has a steep learning curve, and can often be tedious to write out its module+component plumbing.

Anvil augments Dagger’s own boilerplate. Factory generation enables us to remove kapt from much of our project, @ContributesTo and @ContributesBinding allow us to automatically wire dependencies without modules, and @MergeComponent allows us to automatically wire together component interfaces. Factory generation alone recently helped us reduce our incremental build times by as much as 25%!

Anvil’s core features are fantastic, but they are not (nor pretend to be!) turnkey solutions for every use case, though they cover the common ones. Every codebase has its own patterns and nuances, so Anvil 2.3.0 introduced a new compiler-api artifact that allows us to extend Anvil’s own code generation to suit those remaining needs. In this post we’ll detail a little of how it works with our own Activity injection pattern as an example.

Troubleshooting plugin upgrades by going down the rabbit hole of debugging Jenkins.

控制哪些用户能够采取哪些行动并不是一件简单的事情。在Slack中建立这一点，一直是一个有趣的挑战。在大型企业组织中，我们提供给客户的标准角色类型过于宽泛，委托一个通用的管理员角色可能会授予某人过多的权力--如果你只想让一个特定的用户能够管理特定的频道，怎么办？当你让他们成为管理员时，他们能够执行超出预期目的范围的各种行动，并且可以查看仪表盘，看到与管理渠道无关的信息。我们需要建立一个更加灵活并允许细化权限的系统。我们想分享一下我们在角色方面面临的问题，我们实施的解决方案，以及我们对未来的计划。

复杂的系统很难进行大规模的推理；我们往往不能准确地推断系统的行为和性能，所以我们需要根据经验得出这些数据。我们使用负载测试来做到这一点：找到我们系统的极限，并在一个受控环境中大规模地剔除错误。Slack是一个相当复杂的系统--无论你是为成千上万的成员触发一个工作流，还是将一个文件上传到一个线程中，所有的东西都是相互关联的 为我们的用户提供发送消息并使其立即出现在可能是数以百万计的客户端的体验所需的技术，对于大规模构建和测试是非常具有挑战性的。为了充分地测试我们的系统，我们需要建立一个既现实又具有成本效益的工具，以反映实际的用户流量和行为。

分布式跟踪是一种广泛使用的技术，用于了解多服务Web应用程序的延迟，但我们发现它也为了解客户端的性能开辟了一个新的可能性世界。在这篇文章中，我们将解释我们如何将跟踪栈运到我们的iOS、Android和JavaScript客户端，以及我们在这一过程中学到了什么。

Slack如何将百万并发的Websockets迁移到Envoy代理平台。

Slack拥有一个全球性的客户群，在高峰期有数百万的用户同时连接。用户之间的大部分通信涉及到彼此发送大量微小的消息。在Slack的大部分历史中，我们一直使用HAProxy作为所有传入流量的负载平衡器。今天，我们将谈谈我们在使用HAProxy时遇到的问题，我们如何使用Envoy Proxy解决这些问题，迁移过程中的步骤，以及结果如何。

在硅谷，Slack的传奇故事几乎家喻户晓。

From the very beginning of Slack, MySQL was used as the storage engine for all our data. Slack operated MySQL servers in an active-active configuration. This is the story of how we changed our data…

Slack’s desktop application is written in React. We built a React analytics logging library to: 1) increase developer velocity by making it easier to write logging code, 2) reduce log data errors, and 3) create a viewer to get a real-time look at logging. In this first (of two parts) article, we examine how we reached these goals, reviewing key pieces of the library: data sharing, logging impressions, and other events.

“Why is it slow?” is the hardest problem to debug in a complex distributed system like Slack. To diagnose a slow-loading channel with over a hundred thousand users, we’d need to look at client-side…

We recently rolled out a new version of Slack on the desktop, and one of its headlining features is a faster boot time. In this post, we’ll take a look back at our quest to get Slack running quickly,…

我们能从Slack学到什么？