Elegant Firestore Management in Swift: A Generic Service Approach

🔔 Disclaimer: This article reflects my personal approach to using Firestore in Swift. It’s born out of my experiences and preferences, and while I’ve found it beneficial, it’s important to note that there’s no one-size-fits-all solution in software development. This isn’t a claim that it’s the “best” or “only” way to use Firestore. I encourage readers to explore, adapt, and find what works best for their unique needs. Constructive feedback is always welcome!

Before diving into the article, if you’re eager to explore the repository directly, you can jump to the link below.

GitHub - yasuntimure/FirestoreService: A Swift package providing an abstracted service layer for…

In the world of modern iOS development, Firebase’s Firestore has become a popular choice for many developers when it comes to real-time databases. Firestore offers a flexible and scalable database for mobile, web, and server applications. However, as with any tool or service, the way you integrate and use it in your app can make a significant difference in maintainability and clarity.

One common challenge developers face is repetitive Firestore code scattered throughout the app. Each CRUD operation — be it fetching a document, saving data, or deleting an entry — often comes with boilerplate code. While Firestore’s SDK is versatile, a more structured and maintainable approach is to wrap it in a service layer, abstracting away some of the repetitive tasks.

In this article, we’ll delve into creating a Swift Package that acts as a generic service for Firestore interactions. This package aims to provide a clean API and minimize boilerplate, making your Firestore interactions more maintainable and type-safe.

Why a Generic Firestore Service?

When integrating Firestore into your Swift application, it’s quite common to see repeated patterns. These patterns, while necessary, can clutter your codebase, making it harder to maintain and apply changes consistently across your app.

Opting for a generic service offers several advantages:

1. Ensure Consistency: Each Firestore operation will follow the same pattern, reducing the chance of errors and making the behavior predictable.
2. Improve Maintainability: With a centralized service, updates or modifications can be made in one place. It’s easier to apply bug fixes, enhancements, or adaptations without sifting through numerous scattered Firestore calls.
3. Enhance Type Safety: Swift’s type system is robust. By designing our service to take advantage of this, we can catch potential issues at compile time, minimizing runtime crashes and errors.
4. Reusability Across Apps: Once you have a generic service in place, it can easily be used in multiple applications. This reuse can significantly speed up the development process for new projects or when expanding your portfolio of apps.

By encapsulating Firestore interactions within a generic service, we position ourselves for cleaner, more maintainable, and more scalable app architectures.

Potential Limitations

While the generic Firestore service we’ve discussed offers several advantages, it’s essential to be aware of its potential limitations:

Specific Firestore Configurations: If your application relies heavily on advanced Firestore features, like compound queries, complex transactions, or specific security and data validation rules, the generic nature of this service may limit its effectiveness. It’s designed to handle common use cases, but very bespoke configurations might necessitate a more tailored approach.

Remember, the aim of any service or tool is to simplify and streamline development without unduly restricting flexibility. It’s crucial to evaluate if this generic service aligns well with the complexity and specific requirements of your application.

Breaking Down the Firestore Generic Service

If you glance at the package provided at the beginning of the article, you’ll notice several components. Let’s dissect them one by one.

1. FirestoreEndpoint Protocol

This protocol provides a standardized way to specify the details of a Firestore request.

public protocol FirestoreEndpoint {
    var path: FirestoreReference { get }
    var method: FirestoreMethod { get }
    var firestore: Firestore { get }
}

public extension FirestoreEndpoint {
    var firestore: Firestore {
        Firestore.firestore()
    }
}

• path: The Firestore reference, which can either be a DocumentReference or a CollectionReference.
• method: The type of CRUD operation we want to perform, defined by the FirestoreMethod enum.
• firestore: A computed property returning the default Firestore instance.

2. FirestoreMethod Enum

Instead of using separate functions for each CRUD operation, we’ve defined an enum that specifies what kind of operation we intend to perform. This approach offers a clear overview and allows us to handle different operations uniquely based on their type.

public enum FirestoreMethod {
    case get
    case post(any FirestoreIdentifiable)
    case put(any FirestoreIdentifiable)
    case delete
}

3. FirestoreReference and FirestoreIdentifiable Protocols

FirestoreReference acts as a bridge between our service and Firestore's native types. On the other hand, FirestoreIdentifiable ensures that our data models are compatible with Firestore operations.

public protocol FirestoreReference { }

extension DocumentReference: FirestoreReference { }
extension CollectionReference: FirestoreReference { }

public protocol FirestoreIdentifiable: Hashable, Codable, Identifiable {
    var id: String { get set }
}

4. FirestoreService

This is where the magic happens. The FirestoreService class provides three primary static functions with different return types. As their names suggest, they handle interactions for return types respectively.

public protocol FirestoreServiceProtocol {
    static func request<T>(_ endpoint: FirestoreEndpoint) async throws -> T where T: FirestoreIdentifiable
    static func request<T>(_ endpoint: FirestoreEndpoint) async throws -> [T] where T: FirestoreIdentifiable
    static func request(_ endpoint: FirestoreEndpoint) async throws -> Void
}

public final class FirestoreService: FirestoreServiceProtocol {

    private init() {}

    public static func request<T>(_ endpoint: FirestoreEndpoint) async throws -> T where T: FirestoreIdentifiable {
        guard let ref = endpoint.path as? DocumentReference else {
            throw FirestoreServiceError.documentNotFound
        }
        switch endpoint.method {
        case .get:
            guard let documentSnapshot = try? await ref.getDocument() else {
                throw FirestoreServiceError.invalidPath
            }

            guard let documentData = documentSnapshot.data() else {
                throw FirestoreServiceError.parseError
            }

            let singleResponse = try FirestoreParser.parse(documentData, type: T.self)
            return singleResponse
        default:
            throw FirestoreServiceError.invalidRequest
        }

    }

    public static func request<T>(_ endpoint: FirestoreEndpoint) async throws -> [T] where T: FirestoreIdentifiable {
        guard let ref = endpoint.path as? CollectionReference else {
            throw FirestoreServiceError.collectionNotFound
        }
        switch endpoint.method {
        case .get:
            let querySnapshot = try await ref.getDocuments()
            var response: [T] = []
            for document in querySnapshot.documents {
                let data = try FirestoreParser.parse(document.data(), type: T.self)
                response.append(data)
            }
            return response
        case .post, .put, .delete:
            throw FirestoreServiceError.operationNotSupported
        }
    }

    public static func request(_ endpoint: FirestoreEndpoint) async throws -> Void {
        guard let ref = endpoint.path as? DocumentReference else {
            throw FirestoreServiceError.documentNotFound
        }
        switch endpoint.method {
        case .get:
            throw FirestoreServiceError.invalidRequest
        case .post(var model):
            model.id = ref.documentID
            try await ref.setData(model.asDictionary())
        case .put(let model):
            try await ref.setData(model.asDictionary())
        case .delete:
            try await ref.delete()
        }
    }
}

For my current usage I didn’t need any post put delete operation for collections. I might implement them for further features.

Usage of the FirestoreService

Integrating the Firestore Service into your app is straightforward. Here’s a step-by-step guide to help you harness its power after you’ve imported the package:

1. Define Your Endpoint

First and foremost, you’ll need to define your custom endpoints that dictate how and where you want to interact with Firestore.

import FirestoreService

public enum TestEndpoint: FirestoreEndpoint {
    
    case getItems
    case postItem(dto: TestDTO)

    public var path: FirestoreReference {
        switch self {
        case .getItems:
            return firestore.collection("items")
        case .postItem(let dto):
            return firestore.collection("items").document(dto.id)
        }
    }

    public var method: FirestoreMethod {
        switch self {
        case .getItems:
            return .get
        case .postItem(let dto):
            return .post(dto)
        }
    }
}

In the above code, we’ve defined an enum TestEndpoint that conforms to the FirestoreEndpoint protocol. The path provides the reference to where the data is stored in Firestore, while the method determines the type of CRUD operation.

2. Make a Request

With your endpoint set up, you can now make requests to Firestore. Here’s an example of fetching a collection:

Task {
    do {
        let endpoint = TestEndpoint.getItems
        self.items = try await FirestoreService.request(endpoint)
    } catch {
        print("Error: ", error.localizedDescription)
    }
}

In this snippet, we utilize the TestEndpoint.getItems case to fetch all items from the "items" collection in Firestore. The returned data is then assigned to the items array.

Conclusion

Building a generic service layer on top of Firestore’s SDK in Swift offers several benefits in terms of maintainability, consistency, and type safety. With the Firestore Generic Service Swift Package, you can quickly and efficiently integrate Firestore into your Swift applications, ensuring a clean and structured approach.

However, it’s important to note that this package represents my personal usage and approach. While I’ve found it beneficial in many scenarios, there are countless ways to interact with and structure Firestore interactions in Swift.

I wholeheartedly welcome discussions, critiques, and suggestions. If you find areas of improvement or wish to add features that could benefit the broader community, please feel free to submit a PR. Additionally, should the package not align perfectly with your project’s requirements, you’re encouraged to fork it and customize it as you see fit. After all, the essence of open-source and community-driven projects is collaboration and adaptation.

Remember, the best solutions often arise from diverse perspectives and collective input.

Happy coding!

GitHub - yasuntimure/FirestoreService: A Swift package providing an abstracted service layer for…