You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
title: How Swift's Server Support powers Things Cloud
6
6
author: [vrylko, wjainek]
7
7
---
8
8
9
-
At Cultured Code, we’ve recently completed a major transition: our Things Cloud service now runs entirely on Swift. After a year in production, Swift on Server has proven to be reliable, performant, and remarkably well-suited to our needs.
10
-
11
-
*Note: This article is an adaptation of [our recent talk](https://youtu.be/oJArLZIQF8w?si=hLr6g5MmYH3-5K1c) at the Server-Side Swift Conference.*
9
+
You might be familiar with [Things](https://culturedcode.com/things/), a powerful personal task manager that has won multiple Apple Design Awards and is available across Apple devices including iPhone, iPad, Mac, Apple Watch, and Apple Vision Pro. At Cultured Code, the team behind Things, we care about a great user experience across every aspect of the product. This extends to our server back end, and after a rewrite our Things Cloud service has transitioned entirely to Swift. Over the past year in production, Swift has consistently proven to be reliable, performant, and remarkably well-suited for our server-side need.
12
10
13
11
<img
14
12
alt="Things logo"
@@ -17,9 +15,7 @@ At Cultured Code, we’ve recently completed a major transition: our Things Clou
[Things](https://culturedcode.com/things/) is our delightful personal task manager, available on all Apple platforms, with two Apple Design Awards to its name. At Cultured Code, we deeply care about a great user experience in every part of the product.
21
-
22
-
This commitment extends to our backend. [Things Cloud](https://culturedcode.com/things/cloud/) silently synchronizes to-dos across devices, serving as the backbone of the app’s seamless experience. The system’s correctness is ensured by a rigorous theoretical foundation, which is inspired by operational transformations and Git’s internals. After twelve years in production, Things Cloud has proven to be reliable and robust, and has earned our users’ trust. Yet, even as the conceptual foundations held strong, the technology stack fell behind.
18
+
[Things Cloud](https://culturedcode.com/things/cloud/) serves as the backbone of the app’s experience, silently synchronizing to-dos across devices. The robustness of this work is ensured by a rigorous theoretical foundation, inspired by operational transformations and Git’s internals. After twelve years in production, Things Cloud has earned our users’ trust in its reliability. But despite the enduring strength of the architecture itself, the technology stack lagged behind.
23
19
24
20
<divstyle="margin: 2emauto;">
25
21
<img
@@ -28,87 +24,90 @@ This commitment extends to our backend. [Things Cloud](https://culturedcode.com/
<divstyle="text-align: center; font-style: italic; margin-top: 1em;">Things Cloud synchronizes to-dos across different devices.</div>
27
+
<divstyle="text-align: center; font-size: smaller; margin-top: 1em;">Things Cloud synchronizes to-dos across different devices.</div>
32
28
</div>
33
29
30
+
## Switching to Swift
34
31
35
-
## Why we switched to Swift
36
-
37
-
Our legacy Things Cloud was built on Python 2 and Google App Engine. While stable, the backend suffered from a growing list of limitations. Slow response times impacted the user experience, high memory usage drove up infrastructure costs, and Python’s lack of static typing made every change risky. For our push notification system to be fast, we even had to develop a custom C-based service. As these issues accumulated and several deprecations loomed, we decided to take action.
32
+
Our legacy Things Cloud service was built on Python 2 and Google App Engine. While it was stable, it suffered from a growing list of limitations. In particular, slow response times impacted the user experience, high memory usage drove up infrastructure costs, and Python’s lack of static typing made every change risky. For our push notification system to be fast, we even had to develop a custom C-based service. As these issues accumulated and several deprecations loomed, we realized we needed a change.
38
33
39
-
Rewrites are usually a last resort, but in our case it was the only path forward. We explored a range of options like Java, Python 3, Go, and even C++. But Swift, already integral for our client apps, had great potential and a unique set of benefits: it promised excellent performance, predictable memory management through ARC, an expressive type system for reliability and maintainability, and seamless interoperability with C and C++.
34
+
Rewrites are usually a last resort, but in our case, they were the only viable path for Things Cloud. We explored various programming languages including Java, Python 3, Go, and even C++. However, Swift – which was already a core part of our client apps – stood out for its potential and unique benefits. Swift promised excellent performance, predictable memory management through [ARC](https://docs.swift.org/swift-book/documentation/the-swift-programming-language/automaticreferencecounting/), an expressive type system for reliability and maintainability, and seamless interoperability with C and C++.
40
35
41
-
While we had concerns that Swift on Server wasn’t as mature as other ecosystems, both Apple and the open-source community had shown strong commitment to its evolution. Swift had reliably compiled on Linux for a long time, the Swift Server Workgroup had coordinated the server efforts since 2016, the SwiftNIO library gave us confidence in the foundational capabilities, and Vapor provided all the tools to get us up and running quickly.
36
+
While we initially had concerns that Swift's server support wasn’t as mature as that found in other ecosystems, both Apple and the open-source community had shown strong commitment to its evolution. Swift had reliably compiled on Linux for a long time; the Swift Server workgroup had coordinated server efforts since 2016; the [SwiftNIO library](https://github.com/apple/swift-nio) gave us confidence in the foundational capabilities, and [Vapor](https://vapor.codes) provided all the tools to get us up and running quickly.
42
37
43
-
Convinced by these benefits, and the prospect that it could work out well, we embarked on the rewrite. It took us three years to completely rebuild Things Cloud. We’ve been using it internally for the past two years, and it has now been live in production for almost a year.
38
+
Convinced by these benefits and the opportunity to use the same language for client and server development, we embarked on a three-year journey to rewrite Things Cloud. We’ve been using it internally for the past two years, and it has now been live in production for almost a year.
44
39
40
+
## The new Swift server architecture
45
41
46
-
## What the new backend looks like
47
-
48
-
We’ll outline the core components of our new backend, highlighting the Swift packages we use. We’ve found that these components work well together, resulting in a reliable and stable system. We hope this serves as a valuable reference point for anyone considering a similar transition to Swift.
42
+
We’ll outline the core components of our new service architecture, highlighting the Swift packages we use. We’ve found that these components work well together to provide reliability and stability, and we believe this serves as a valuable reference point for others considering a similar transition to Swift.
<divstyle="text-align: center; font-style: italic; margin-top: 1em;">Overview of our new Swift-based backend.</div>
51
+
<divstyle="text-align: center; font-size: smaller; margin-top: 1em;">Overview of our new Swift-based service architecture.</div>
58
52
</div>
59
53
60
-
Code
61
-
- Our **Swift 5.10** codebase has around 30k lines of code. It produces a binary of 60 MB, and builds in ten minutes.
54
+
### Code
55
+
56
+
- Our **Swift** server codebase has around 30,000 lines of code. It produces a binary of 60 MB, and builds in ten minutes.
62
57
- It uses **Vapor** as an HTTP web framework, which uses **SwiftNIO** as its underlying network application framework.
63
58
- We compile a single “monolith” binary from our Swift source code, but use it to run multiple services, each configured by passing different parameters at runtime.
64
59
- We use **Xcode** for its robust suite of tools for development, debugging, and testing. It provides us with a familiar and consistent experience across both server and client environments.
65
60
66
-
Deployment
61
+
### Deployment
62
+
67
63
-**AWS** hosts our entire platform, and is entirely managed by **Terraform**, an infrastructure as code tool.
68
64
- We use a continuous integration pipeline to automate tests and build our Swift code into a **Docker** image. This is then deployed in a **Kubernetes** cluster alongside other components.
69
65
- The **HAProxy** load balancer is used to route client traffic to the appropriate Swift service in the cluster.
70
66
71
-
Storage
67
+
### Storage
68
+
72
69
- Persistent data is stored in **Amazon Aurora MySQL**, a relational database, which we connect to with **MySQLKit**.
73
70
- To keep the database small, we’re offloading less-used data to **S3**, which we access via the **Soto** package.
74
71
- More ephemeral data, such as push notifications and caches, is stored in **Redis**, an in-memory key-value database, which we access via **RediStack**.
75
72
76
-
Other Services
73
+
### Other Services
74
+
77
75
- The **APNSwift** package is used to communicate with the Apple Push Notification service.
78
76
-**AWS Lambda**, a serverless compute service, powers our **Mail to Things** feature. This process is written in Python 3 due to its mature libraries for the processing of incoming emails. The results are passed to Swift using **Amazon Simple Queue Service**.
79
77
80
-
Monitoring
78
+
### Monitoring
79
+
81
80
- We take the resilience of Things Cloud seriously and go to great lengths to ensure it.
82
81
- In Swift, we generate JSON logs using our own logger. To produce metrics, we’re using the **Swift Prometheus**.
83
82
- We use **Amazon CloudWatch** to store and analyze logs and metrics. It triggers Incidents, which reach the responsible engineer via **PagerDuty**.
84
-
- To test how well our backend can recover from transient errors, we employ **chaos testing**. Each day, our self-written chaos agent performs random disruptive actions such as terminating a Swift service or restarting the database. We then verify that the system recovers as expected.
85
-
83
+
- To test how well our service can recover from transient errors, we employ **chaos testing**. Each day, our self-written chaos agent performs random disruptive actions such as terminating a Swift service or restarting the database. We then verify that the system recovers as expected.
86
84
87
-
## How the new backend performs
85
+
## Results
88
86
89
-
We aimed to confirm the performance and stability of the new backend well before it reached users. So during development, we deployed the new system alongside the legacy one. While the legacy system continued to handle all requests, they were also copied over to the new system, allowing it to fully process them with its own logic and database.
87
+
We wanted to thoroughly test the performance and stability of the new Swift service architecture before it was deployed in production. So during the development phase, we deployed the new system alongside the existing legacy system. While the legacy system continued to be the operational service for all requests, the new system also processed them independently using its own logic and database.
90
88
91
-
This approach allowed us to develop the new system under real-world conditions without risking the user experience. Gradually gaining confidence in its robustness and reliability, we were able to deploy a hardened system from day one.
89
+
This approach enabled us to develop and test the new system under real-world conditions without any risk to the user experience. Thanks to the confidence we built in the new system's robustness and reliability through evaluating it with production workloads, we were able to deploy a hardened system from the very beginning.
92
90
93
-
Today, after a full year in production, Swift on Server has delivered on its promise. It’s fast and memory-efficient. Our Kubernetes cluster consists of four instances (each with two virtual CPUs and 8 GB of memory), and handles traffic peaking at around 500 requests per second. Compared to the legacy system, this setup has led to a more than threefold reduction in compute costs, while response times have shortened dramatically.
91
+
Now, with over a full year in production, we're pleased to report that Swift has fulfilled its promise for server-side development. It’s fast and memory-efficient. Our Kubernetes cluster comprises four instances, each with two virtual CPUs and 8 GB of memory, and has handled traffic peaks of up to 500 requests per second. Compared to the legacy system, this setup has led to a more than threefold reduction in compute costs, while response times have shortened dramatically.
94
92
95
93
<divstyle="margin: 2emauto;">
96
94
<img
97
-
alt="Comparison between our legacy backend and new Swift-based one."
95
+
alt="Comparison between our legacy back end and new Swift-based one."
<divstyle="text-align: center; font-style: italic; margin-top: 1em;">Comparison between our legacy backend and new Swift-based one.</div>
100
+
<divstyle="text-align: center; font-size: smaller; margin-top: 1em;">Comparison between our legacy back end and new Swift-based one.</div>
103
101
</div>
104
102
105
-
Swift’s performance also allowed us to replace our legacy C-based push notification service with one implemented in Swift, significantly simplifying our code base and operations.
103
+
And one extra win: Swift’s performance was powerful enough that we were also able to replace the custom C-based push notification service we'd built with a Swift-based one; this significantly simplified our codebase and operations.
106
104
105
+
## Conclusions
107
106
108
-
## Where we’ll go
107
+
Swift turned out to be a great choice for server usage. It delivered on everything we had hoped for: We’re now using a modern and expressive programming language, the code runs and performs well, and the Swift ecosystem provides all the integrations we need. With a year of production use, we haven’t encountered a single operational issue.
109
108
110
-
Swift on Server turned out to be a great choice for us. It delivered on everything we had hoped for: We’re now using a modern and expressive programming language, the code runs and performs well, and the Swift ecosystem provides all the integrations we need. With a year of production use, we haven’t encountered a single operational issue.
109
+
For more information on our journey and experiences, you might enjoy [our recent talk](https://youtu.be/oJArLZIQF8w?si=hLr6g5MmYH3-5K1c) at the [ServerSide.Swift](https://www.serversideswift.info) conference.
111
110
112
-
We encourage other teams to evaluate Swift on Server for their projects. We opted for a full rewrite, but the gradual adoption of Swift is also an interesting option, even more so with the recently announced effort around Java interoperability.
111
+
We encourage other teams to consider using Swift for server-oriented projects. While we chose to undergo a complete rewrite, the gradual adoption of Swift is also an intriguing option, especially considering the recently announced initiative aimed at [enhancing Java interoperability](https://github.com/swiftlang/swift-java).
113
112
114
-
As for us, we consider our backend to be in the best shape it’s ever been and we’re excited about the new features we can build on this solid foundation.
113
+
As for us, we believe our server architecture is in its best shape ever, and we’re thrilled about the new features we can build upon this solid foundation.
0 commit comments