Me llama la atención que comenzaron a prototipar en Typescript por motivos lógicos pero en cuanto empezaron a tener problemas de rendimiento se pasaron a Go.
The backend is mostly in Typescript, as is the frontend and mobile apps. This allows software engineers to work across the stack without switching languages. This choice is similar to Linear’s to use Typescript between the back and front ends.
Why pick this language? Daniel Holmgren gives several reasons:
De facto language of the web. “Javascript and therefore Typescript is probably as close as we have to a ‘lingua franca’ for the web. We felt it was a natural choice to communicate the core ideas in the reference implementation of the protocol.”
Shared front and back end language. “Having a shared implementation across the client and backend makes for a nice development experience, especially knowing that both sides have a shared understanding of the schema system.”
Fits the AT protocol’s dynamic data approach. “Being a dynamic language, Typescript has been great for working with the dynamic data you find in the ATproto ecosystem.”
A great fit for code generation. “Typescript has a really great ecosystem for code generation. I think it's that the actual official TypeScript implementation just ships the tooling for parsing into an AST and then manipulating it and outputting code. Not many people were needing that, but I was really happy it was there.”
Great for prototyping with a small team. “Typescript is a great language for quick building. The runtime is quite powerful and lets you not worry (much) about things like memory management and concurrency. The type system is very ergonomic and provides the structure you need, while seldom getting in the way. With such a small early team, it made sense to choose a language that enabled us to prototype quickly.”
The Typescript code on the backend uses the Node.js runtime. One worry the team had was how it would scale, as Node.js app runs in a single thread, without creating a new thread for every request. This means a server running Node.js can handle fewer parallel requests than frameworks that support multi-threading more efficiently.
However, the team found it's very easy to scale the service horizontally (adding more machines,) but only by building the application to be stateless. They did this, and Daniel recalls they proved a point:
“At one point, we had around 192 node processes running behind HAProxy. All these processes were super ‘bored,’ at around 1% CPU utilization. But the point is that it’s very easy to scale a stateless Node service out horizontally – so that's what we did!”
The backend started out as Typescript, but over time, Go was introduced. But why bring in another language when Typescript works well enough? Performance, says Daniel:
“Some of more infra-y services such as the Relay and our internal ‘Dataplane’ are very performance-based. They often involve a lot of crypto operations and low-level bit twiddling. These are things that Go excels at. In particular, Go has a shard-aware driver for Scylla (a database we use) which made it a natural choice for interfacing with it.”
The team has rewritten services from Typescript to Go when performance improvements warrant it. Services in Go, today:
Search services like Palomar.
The “firehose” called Relay. This service does a lot of low-level fiddling and crypto operations.
Dataplane. This service is called the “BigSky service,” and is one of few closed-sourced services. This service manages data, talking to ScyllaDB, as well as some other data stores like Redis, and their own handwritten cache stores.
