Лучшие практики для отслеживания прочитанных статей в Firestore, оставаясь в пределах лимитов бесплатного тарифа – SwiftUI/iOS [закрыто]

Вопрос или проблема

struct Article {
    let id: String
    let title: String
    let content: String
    let isRead: Bool
    let timestamp: Date
}

func markAsRead(articleId: String) async throws {
    let ref = db.collection("articles").document(articleId)
    try await ref.updateData([
        "isRead": true,
        "readTimestamp": Date()
    ])
}

// Структура в Firestore
users/{userId}/reading/{deviceId} {
    lastReadTimestamp: timestamp
}

// Обновить метку времени, когда пользователь читает статьи
func updateLastRead(userId: String, deviceId: String) async throws {
    let ref = db.collection("users").document(userId)
        .collection("reading").document(deviceId)

    try await ref.setData([
        "lastReadTimestamp": FieldValue.serverTimestamp()
    ])
}

// Запросить непрочитанные статьи
func getUnreadArticles(userId: String, deviceId: String) async throws -> [Article] {
    let readingDoc = try await db.collection("users")
        .document(userId)
        .collection("reading")
        .document(deviceId)
        .getDocument()

    let lastRead = readingDoc.data()?["lastReadTimestamp"] as? Timestamp ?? Timestamp(date: Date(timeIntervalSince1970: 0))

    let snapshot = try await db.collection("articles")
        .whereField("timestamp", isGreaterThan: lastRead)
        .getDocuments()

    return snapshot.documents.map { /* логика отображения */ }
}

Ответ или решение

Конечно! Давайте рассмотрим, как эффективно отслеживать прочитанные статьи в Firestore, придерживаясь пределов бесплатного тарифа, с точки зрения разработки iOS-приложения с использованием SwiftUI.

Полезные практики для отслеживания прочитанных статей в Firestore

1. Эффективное отслеживание прочитанных статей

Ваш текущий подход к записи статуса прочтения статьи может привести к избыточным записям в базе данных, что нецелесообразно, особенно если вы планируете, что охват пользователей будет увеличиваться. Вместо того чтобы обновлять каждую статью по мере её прочтения, разумнее использовать стратегию, которая требует минимального количества операций записи.

2. Хранение статуса в отдельной коллекции

Создание отдельной коллекции для статуса чтения может оказаться излишним и усложнить структуру вашей базы данных. Вместо этого будет более оптимально организовать данные на уровне пользователя и устройства.

Новая структура данных:

users/{userId}/reading/{deviceId} {
    lastReadTimestamp: timestamp
}

3. Использование одного таймстампа

Ваше обновление, основанное на хранении одного таймстампа lastReadTimestamp, представляет собой перспективный подход. Преимущества такого решения следующие:

• Снижение операций записи: Вам нужно будет записывать только одну операцию на устройство за сессию чтения, что значительно уменьшит риск превышения лимитов.
• Простота в обновлении данных: Запись таймстампа более интуитивно понятна, чем обновление отдельных статусов статей.
• Гибкость в запросах: Вы сможете легко извлекать все статьи, которые были добавлены после последнего обновления времени чтения.

4. Запросы на получение непрочитанных статей

Ваш метод для получения непрочитанных статей основан на сравнении timestamp, что является эффективным и быстрым способом. JSON-запрос к Firestore выглядит оптимально:

func getUnreadArticles(userId: String, deviceId: String) async throws -> [Article] {
    let readingDoc = try await db.collection("users")
        .document(userId)
        .collection("reading")
        .document(deviceId)
        .getDocument()

    let lastRead = readingDoc.data()?["lastReadTimestamp"] as? Timestamp ?? Timestamp(date: Date(timeIntervalSince1970: 0))

    let snapshot = try await db.collection("articles")
        .whereField("timestamp", isGreaterThan: lastRead)
        .getDocuments()

    return snapshot.documents.map { /* логика маппинга */ }
}

5. Условия и недостатки

Несмотря на очевидные преимущества, следует рассмотреть некоторые недостатки:

• Потеря индивидуального статуса прочтения: Ваша текущая реализация не позволяет отслеживать статус прочтения для каждой статьи в отдельности. Это может стать проблемой, если в будущем вы захотите добавить какую-то функциональность, основанную на этом статусе.
• Ограничение на количество устройств: Ваш метод предполагает, что одно устройство будет обеспечивать только одно значение lastReadTimestamp. Если пользователь читает статьи на нескольких устройствах, может потребоваться возможность хранения отдельных таймстампов для каждого устройства.

Заключение

Оптимизация отслеживания прочитанных статей в Firestore через хранение единого таймстампа — это разумное решение, которое поможет вам оставаться в пределах бесплатных лимитов и упрощать управление данными. Несмотря на некоторые недостатки, предложенный вами способ является функциональным и эффективным для вашего текущего проекта. В будущем вы всегда сможете адаптировать его по мере роста количества пользователей и изменяющихся требований.