Kaitlin Mahar

Lead Engineer

Rachelle Palmer

Product Lead, Developer Experience

Recently, [Rachelle Palmer](https://www.linkedin.com/in/rachellepalmer/), Senior Product Manager for MongoDB Drivers sat down with [Kaitlin Mahar](https://www.linkedin.com/in/kaitlinmahar/), Lead Engineer for the `Swift` and `Rust` drivers to discuss some of the exciting developments in the `Swift` space. This article details that conversation.

Swift is a well documented, easy to use and convenient language focused on iOS app development. As one of the top ten languages, it's more popular than Ruby, Go, or Rust, but keeps a fairly low profile - it's the underestimated backbone of millions of applications, from Airbnb to LinkedIn. With its simple syntax and strong performance profile, Swift is versatile enough to be used for many use cases and applications, and we've watched with great interest as the number of customers using Swift with MongoDB has grown.

Swift can also be used for more than mobile, and we've seen a growing number of developers worldwide use Swift for backend development - software engineers can easily extend their skills with this concise, open source language. Kaitlin Mahar, and I decided we'd like to share more about MongoDB's commitment and involvement with the Swift community and how that influences some of the initiatives on our Swift driver roadmap.

**Rachelle (RP):** I want to get right to the big announcement! Congratulations on joining the Swift Server Working Group (SSWG). What is the SSWG and what are some of the things that the group is thinking about right now?

**Kaitlin (KM):** The SSWG is a steering team focused on promoting the use of Swift on the server. Joining the SSWG is an honor and a privilege for me personally - through my work on the driver and attendance at conferences like [Serverside.swift](https://www.serversideswift.info/), I've become increasingly involved in the community over the last couple of years and excited about the huge potential I see for Swift on the server, and being a part of the group is a great opportunity to get more deeply involved in this area. There are representatives in the group from Apple, [Vapor](https://vapor.codes/) (a popular Swift web framework), and Amazon. The group right now is primarily focused on guiding the development of a robust ecosystem of libraries and tools for server-side Swift. We run an incubation process for such projects, focused on providing overall technical direction, ensuring compatibility between libraries, and promoting best practices.

To that end, one thing we're thinking about right now is [connection pooling](https://forums.swift.org/t/generic-connection-pool/39161). The ability to pool connections is very important for a number of server-side use cases, and right now developers who need a pool have to implement one from scratch. A generalized library would make it far easier to, for example, write a new database driver in Swift. Many SSWG members as well as the community at large are interested in such a project and I'm very excited to see where it goes.

A number of other foundational libraries and tools are being worked on by the community as well, and we've been spending a lot of time thinking about and discussing those: for example, [standardized APIs to support tracing](https://forums.swift.org/t/current-state-of-swift-tracing/39830), and a new library called [Swift Service Lifecycle](https://swift.org/blog/swift-service-lifecycle/) which helps server applications manage their startup and shutdown sequences.

**RP:** When we talk with customers about using Swift for backend development, asking how they made that choice, it seems like the answers are fairly straightforward: with limited time and limited resources, it was the fastest way to get a web app running with a team of iOS developers. Do you feel like Swift is compelling to learn if you aren't an iOS developer though? Like, as a first language instead of Python?

**KM:** Absolutely! My first language was Python, and I see a lot of things I love about Python in Swift: it's succinct and expressive, and it's easy to quickly pick up on the basics. At the same time, Swift has a really powerful and strict type system similar to what you might have used in compiled languages like Java before, which makes it far harder to introduce bugs in your code, and forces you to address edge cases (for example, null values) up front. People often say that Swift borrows the best parts of a number of other languages, and I agree with that. I think it is a great choice whether it is your first language or fifth language, regardless of if you're interested in iOS development or not.

**RP:** Unquestionably, I think there's a great match here - we have MongoDB which is really easy and quick to get started with, and you have Swift which is a major win for developer productivity.

**RP:** What's one of your favorite Swift features?

**KM:** Enums with associated values are definitely up there for me. We use these in the driver a lot. They provide a very succinct way to express that particular values are present under certain conditions. For example, MongoDB allows users to specify either a string or a document as a "hint" about what index to use when executing a query. Our API clearly communicates these choices to users by defining our `IndexHint` type like this:

``` swift
public enum IndexHint {
   /// Specifies an index to use by its name.
   case indexName(String)
   /// Specifies an index to use by a specification `BSONDocument` containing the index key(s).
   case indexSpec(BSONDocument)
}
```

This requires the user to explicitly specify which version of a hint they want to use, and requires that they provide a value of the correct corresponding type along with it.

**RP:** I'd just like to say that mine is the `MemoryLayout` type. Being able to see the memory footprint of a class that you've defined is really neat. We're also excited to announce that our top priority for the next 6-9 months is rewriting our driver to be purely in Swift. For everyone who is wondering, why wasn't our official Swift driver "all Swift" initially? And why change now?

**KM:** We initially chose to wrap libmongoc as it provided a solid, reliable core and allowed us to deliver a great experience at the API level to the community sooner. The downside of that was of course, for every feature we want to do, the C driver had to implement it first sometimes this slowed down our release cadence. We also feel that writing driver internals in pure Swift will enhance performance, and give better memory safety - for example, we won't have to spend as much time thinking about properly freeing memory when we're done using it.

If you're interested in learning more about Swift, and how to use Swift for your development projects with MongoDB, here are some resources to check out:

-   [Introduction to Server-Side Swift and Building a Command Line Executable](https://www.youtube.com/watch?v=cHB8hzUSCpE)
-   [The Swift driver GitHub](https://github.com/mongodb/mongo-swift-driver)

Kaitlin will also be on an upcoming [MongoDB Podcast episode](https://mongodb.prakticum-team.ru/podcast) to talk more about working with Swift so make sure you subscribe and stay tuned!

If you have questions about the Swift Driver, or just want to interact with other developers using this and other drivers, visit us [in the MongoDB Community](https://mongodb.prakticum-team.ru/proxy/community.mongodb.com) and be sure to introduce yourself and say hello!

Swift is a well-documented, easy-to-use, convenient language focused on iOS app development. Get an update on MongoDB's ongoing commitment to Swift.

An Update on MongoDB's Ongoing Commitment to Swift

 I recently [revealed on Twitter](https://twitter.com/k__mahar/status/1494118397491269636) something that may have come as a surprise to many of my followers from the Swift/iOS community: I had never written an iOS app before! I've been writing Swift for a few years now but have focused entirely on [library development](https://www.youtube.com/watch?v=9-fdbG9jNt4) and [server-side Swift](https://www.swift.org/server/).

A highly compelling feature of Swift is that it allows you to write an iOS app and a corresponding backend – a complete, end-to-end application – all in the same language. This is similar to how using [Node.js](https://nodejs.org/en/) for a web app backend allows you to write Javascript everywhere.

To test this out and learn about iOS development, I decided to build a full-stack application entirely in Swift. I settled on a familiar CRUD app I've created a web version of before, an application that allows the user to manage a list of kittens and information about them.

I chose to build the app using the following components:
* A backend server, written using the popular Swift web framework [Vapor](https://vapor.codes/) and using the [MongoDB Swift driver](https://github.com/mongodb/mongo-swift-driver) via [MongoDBVapor](https://github.com/mongodb/mongodb-vapor) to store data in MongoDB
* An iOS application built with [SwiftUI](https://developer.apple.com/xcode/swiftui/) and using [SwiftBSON](https://github.com/mongodb/swift-bson) to support serializing/deserializing data to/from [extended JSON](https://mongodb.prakticum-team.ru/proxy/docs.mongodb.com/manual/reference/mongodb-extended-json/), a version of JSON with MongoDB-specific extensions to simplify type preservation
* A [SwiftPM](https://www.swift.org/package-manager/) package containing the code I wanted to share between the two above components

I was able to combine all of this into a single code base with a folder structure as follows:
```
FullStackSwiftExample/
├── Models/
│   ├── Package.swift
│   └── Sources/
│       └── Models/
│           └── Models.swift
├── Backend/
│   ├── Package.swift
│   └── Sources/
│       ├── App/
│       │   ├── configure.swift
│       │   └── routes.swift
│       └── Run/
│           └── main.swift
└── iOSApp/
    └── Kittens/
        ├── KittensApp.swift
        ├── Utilities.swift
        ├── ViewModels/
        │   ├── AddKittenViewModel.swift
        │   ├── KittenListViewModel.swift
        │   └── ViewUpdateDeleteKittenViewModel.swift
        └── Views/
            ├── AddKitten.swift
            ├── KittenList.swift
            └── ViewUpdateDeleteKitten.swift
```

Overall, it was a great learning experience for me, and although the app is pretty basic, I'm proud of what I was able to put together! [Here](https://github.com/mongodb/mongo-swift-driver/tree/main/Examples/FullStackSwiftExample) is the finished application, instructions to run it, and documentation on each component.

In the rest of this post, I'll discuss some of my takeaways from this experience.

## 1. Sharing data model types made it straightforward to consistently represent my data throughout the stack.

As I mentioned above, I created a shared SwiftPM package for any code I wanted to use both in the frontend and backend of my application. In that package, I defined `Codable` types modeling the data in my application, for example:

```swift
/**
* Represents a kitten.
* This type conforms to `Codable` to allow us to serialize it to and deserialize it from extended JSON and BSON.
* This type conforms to `Identifiable` so that SwiftUI is able to uniquely identify instances of this type when they
* are used in the iOS interface.
*/
public struct Kitten: Identifiable, Codable {
   /// Unique identifier.
   public let id: BSONObjectID

   /// Name.
   public let name: String

   /// Fur color.
   public let color: String

   /// Favorite food.
   public let favoriteFood: CatFood

   /// Last updated time.
   public let lastUpdateTime: Date

   private enum CodingKeys: String, CodingKey {
       // We store the identifier under the name `id` on the struct to satisfy the requirements of the `Identifiable`
       // protocol, which this type conforms to in order to allow usage with certain SwiftUI features. However,
       // MongoDB uses the name `_id` for unique identifiers, so we need to use `_id` in the extended JSON
       // representation of this type.
       case id = "_id", name, color, favoriteFood, lastUpdateTime
   }
}
```

When you use separate code/programming languages to represent data on the frontend versus backend of an application, it's easy for implementations to get out of sync.  But in this application, since the same exact model type gets used for the frontend **and** backend representations of kittens, there can't be any inconsistency.

Since this type conforms to the `Codable` protocol, we also get a single, consistent definition for a kitten's representation in external data formats. The formats used in this application are:
* [Extended JSON](https://mongodb.prakticum-team.ru/proxy/docs.mongodb.com/manual/reference/mongodb-extended-json/), which the frontend and backend use to communicate via HTTP, and
* [BSON](https://mongodb.prakticum-team.ru/proxy/docs.mongodb.com/manual/reference/bson-types/), which the backend and MongoDB use to communicate

For a concrete example of using a model type throughout the stack, when a user adds a new kitten via the UI, the data flows through the application as follows:
1. The iOS app creates a new `Kitten` instance containing the user-provided data
1. The `Kitten` instance is serialized to extended JSON via `ExtendedJSONEncoder` and sent in a POST request to the backend
1. The Vapor backend deserializes a new instance of `Kitten` from the extended JSON data using `ExtendedJSONDecoder`
1. The `Kitten` is passed to the MongoDB driver method `MongoCollection<Kitten>.insertOne()`
1. The MongoDB driver uses its built-in `BSONEncoder` to serialize the `Kitten` to BSON and send it via the MongoDB [wire protocol](https://mongodb.prakticum-team.ru/proxy/docs.mongodb.com/manual/reference/mongodb-wire-protocol/) to the database

With all these transformations, it can be tricky to ensure that both the frontend and backend remain in sync in terms of how they model, serialize, and deserialize data.  Using Swift everywhere and sharing these `Codable` data types allowed me to avoid those problems altogether in this app.

## 2. Working in a single, familiar language made the development experience seamless.

Despite having never built an iOS app before, I found my existing Swift experience made it surprisingly easy to pick up on the concepts I needed to implement the iOS portion of my application. I suspect it's more common that someone would go in the opposite direction, but I think iOS experience would translate well to writing a Swift backend too!

I used several Swift language features such as [protocols](https://docs.swift.org/swift-book/LanguageGuide/Protocols.html), [trailing closures](https://docs.swift.org/swift-book/LanguageGuide/Closures.html), and [computed properties](https://docs.swift.org/swift-book/LanguageGuide/Properties.html) in both the iOS and backend code. I was also able to take advantage of Swift's new built-in features for [concurrency](https://docs.swift.org/swift-book/LanguageGuide/Concurrency.html) throughout the stack. I used the `async` APIs on [`URLSession`](https://developer.apple.com/documentation/foundation/urlsession) to send HTTP requests from the frontend, and I used Vapor and the MongoDB driver's `async` APIs to handle requests on the backend.  It was much easier to use a consistent model and syntax for concurrent, asynchronous programming throughout the application than to try to keep straight in my head the concurrency models for two different languages at once.

In general, using the same language really made it feel like I was building a single application rather than two distinct ones, and greatly reduced the amount of context-switching I had to do as I alternated between work on the frontend and backend. 

## 3. SwiftUI and iOS development are really cool!

Many of my past experiences trying to cobble together a frontend for school or personal projects using HTML and Javascript were frustrating.  This time around, the combination of using my favorite programming language and an elegant, declarative framework made writing the frontend very enjoyable. More generally, it was great to finally learn a bit about iOS development and what most people writing Swift and that I know from the Swift community do!

---

In conclusion, my first foray into iOS development building this full-stack Swift app was a lot of fun and a great learning experience. It strongly demonstrated to me the benefits of using a single language to build an entire application, and using a language you're already familiar with as you venture into programming in a new domain.

I've included a list of references below, including a link to the example application. Please feel free to get in touch with any questions or suggestions regarding the application or the MongoDB libraries listed below – the best way to get in touch with me and my team is by filing a [GitHub issue](https://github.com/mongodb/mongo-swift-driver/issues/new/choose) or [Jira ticket](http://jira.mongodb.org/browse/SWIFT)!

## References
* [Example app source code](https://github.com/mongodb/mongo-swift-driver/tree/main/Examples/FullStackSwiftExample)
* [MongoDB Swift driver](https://github.com/mongodb/mongo-swift-driver) and [documentation](https://mongodb.github.io/mongo-swift-driver/docs/current/MongoSwift/index.html)
* [MongoDBVapor](https://github.com/mongodb/mongodb-vapor) and [documentation](https://mongodb.github.io/mongodb-vapor/current/index.html)
* [SwiftBSON](https://github.com/mongodb/swift-bson) and [documentation](https://mongodb.github.io/swift-bson/docs/current/SwiftBSON/index.html)
* [Vapor](https://vapor.codes/)
* [SwiftUI](https://developer.apple.com/xcode/swiftui/)

Curious about mobile and server-side swift? Use this tutorial and example code!

Kaitlin Mahar

Content by Kaitlin Mahar

An Update on MongoDB's Ongoing Commitment to Swift

Building a Full Stack application with Swift