Что использовать, если нужно три разных запроса мапить между собой

При реализации задачи маппинга данных из трёх разных запросов в Android-приложении выбор конкретного подхода зависит от архитектуры приложения, типа данных и источников запросов.

Основные архитектурные подходы

1. Реактивный подход с Kotlin Flow/Coroutines (рекомендуется)

Современный подход, который лучше всего подходит для асинхронных операций.

suspend fun combineThreeQueries(): Result<CombinedData> {
    return try {
        // Параллельное выполнение запросов
        val deferredResult1 = async { repository.fetchData1() }
        val deferredResult2 = async { repository.fetchData2() }
        val deferredResult3 = async { repository.fetchData3() }
        
        // Ожидание результатов
        val result1 = deferredResult1.await()
        val result2 = deferredResult2.await()
        val result3 = deferredResult3.await()
        
        // Маппинг и комбинирование
        val combinedData = CombinedData(
            data1 = result1.mapToDomain(),
            data2 = result2.mapToDomain(),
            data3 = result3.mapToDomain()
        )
        
        Result.success(combinedData)
    } catch (e: Exception) {
        Result.failure(e)
    }
}

2. Использование Kotlin Flow с операторами комбинирования

Идеально подходит для непрерывных потоков данных:

fun observeCombinedData(): Flow<CombinedData> {
    return combine(
        repository.observeData1(),
        repository.observeData2(),
        repository.observeData3()
    ) { data1, data2, data3 ->
        CombinedData(
            data1 = data1.toDomain(),
            data2 = data2.toDomain(),
            data3 = data3.toDomain()
        )
    }
    .catch { e -> 
        // Обработка ошибок
        emit(CombinedData.error(e.message))
    }
}

3. Подход с использованием RxJava

Если проект уже использует RxJava:

Observable.zip(
    repository.getData1().map(this::mapToDomain1),
    repository.getData2().map(this::mapToDomain2),
    repository.getData3().map(this::mapToDomain3),
    (data1, data2, data3) -> new CombinedData(data1, data2, data3)
)
.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.subscribe(
    combinedData -> { /* обработка */ },
    error -> { /* обработка ошибки */ }
);

Ключевые аспекты реализации

Обработка зависимостей между запросами

• Параллельное выполнение: Когда запросы независимы
• Последовательное выполнение: Когда один запрос зависит от результата другого
• Смешанный подход: Часть запросов параллельно, часть последовательно

// Последовательные зависимые запросы
suspend fun fetchDependentData(): Result<CombinedData> {
    val userData = repository.fetchUserData() // Первый запрос
    val userId = userData.id
    
    val userDetails = repository.fetchUserDetails(userId) // Второй запрос
    val userSettings = repository.fetchUserSettings(userId) // Третий запрос
    
    return Result.success(combineData(userData, userDetails, userSettings))
}

Обработка ошибок

Необходимо предусмотреть разные стратегии:

• Fail-fast: Прекращение при первой ошибке
• Частичный успех: Продолжение при частичных ошибках
• Ретри логика: Повторные попытки для неудачных запросов

// Обработка с частичными результатами
suspend fun fetchWithFallback(): CombinedData {
    val result1 = runCatching { repository.fetchData1() }.getOrNull()
    val result2 = runCatching { repository.fetchData2() }.getOrNull()
    val result3 = runCatching { repository.fetchData3() }.getOrNull()
    
    return CombinedData(
        data1 = result1?.toDomain() ?: DomainData.empty(),
        data2 = result2?.toDomain() ?: DomainData.empty(),
        data3 = result3?.toDomain() ?: DomainData.empty()
    )
}

Рекомендации по выбору подхода

Когда использовать Kotlin Flow/Coroutines:

• Новые проекты на Kotlin
• Нужна интеграция с Jetpack Compose
• Требуется сложная обработка асинхронных операций
• Важна читаемость и поддержка кода

Когда использовать RxJava:

• Легаси проекты с уже внедрённой RxJava
• Сложные трансформации потоков данных
• Необходимость backpressure handling

Архитектурные паттерны:

• Repository Pattern: Централизация логики маппинга
• Use Cases/Interactors: Инкапсуляция бизнес-логики
• Mapper Classes: Отдельные классы для преобразования данных

Заключение

Для современных Android-приложений рекомендуется использовать Kotlin Flow и корутины благодаря:

• Нативной поддержке в экосистеме Android/Kotlin
• Упрощённому управлению жизненным циклом с viewModelScope/lifecycleScope
• Лучшей интеграции с Jetpack компонентами
• Более читаемому коду без callback hell

Ключевой принцип — разделение ответственности: логика маппинга должна быть вынесена в отдельные мапперы или extension-функции, оставляя UseCase/ViewModel чистыми от деталей преобразования данных.