​
Introduction

When building apps with Store, one of the key architectural decisions is whether to use a single Store or multiple Stores to manage your data. This guide will help you make that decision based on your specific use case and requirements.

Prerequisites

Before diving in, you should:

​
Real-World Example

Let’s explore this decision through an example from the Trails app. The Trail Detail page displays detailed information about a ski trail and its status. It needs to cimbine data from multiple endpoints:

  • trails/{trailId}: Provides information about the ski trail.
  • resorts/{resortId}/status/trails/{trailId}: Provides the status of the ski trail.
  • weather/{resortId}: Provides weather information for a ski resort.

Data from these endpoints needs to be combined into a single TrailDetail domain model. But should we use a single Store or multiple Stores? Let’s explore the key factors that will help us make that decision.

​
Decision Factors

​
Overview

Deciding between a single Store and multiple Stores depends on several factors:

​
Data Coupling

Question: Are the data sources tightly coupled or independent?
  • Tightly Coupled Data: If the data from all APIs is interdependent and always used together, a single Store might be beneficial.
  • Independent Data: If the data sources can be used separately or have different lifecycles, multiple Stores offers better modularity.
Question: Do you require atomic updates across data sources?
  • Atomic Updates: A single Store can manage atomic updates more effectively if you need to ensure that updates to multiple data sources happen simultaneously.
  • Independent Updates: If updates to different data sources can happen independently, you should consider complexity tradeoffs next.

​
Caching Strategies

Question: Do your data sources require different caching strategies or validation rules?

  • Each Data Source Has Unique Caching or Validation Needs: Use multiple Stores to tailor caching strategies to each data source.
  • Same Caching and Validation Needs: A single Store can simplify caching if both data sources share the same caching or validation needs.

​
Complexity of Data Merging

Question: Is combining data within a single Store less complex? Is combining data in the repository layer feasible?

  • Simple Merging Logic: If combining data in the repository layer is feasible, multiple Stores offers better modularity.
  • Complex Merging Logic: If merging data is complex, encapsulating it within a single Store can reduce complexity, lowering the odds of errors and increasing maintainability.

​
Error Handling

Question: Do the data sources have different error handling requirements?

  • Independent Error Handling: Multiple Stores allow for handling errors separately, promoting a more robust and decoupled system and improved user experience.
  • Unified Error Handling: A single Store can handle errors collectively, which might be more convenient in some cases but could also lead to individual data source issues being masked.

​
Scalability and Extensibility

Question: Will other data sources need to be added in the future?

  • Scalability and Extensibility are Top Priorities: Multiple Stores make it easier to integrate additional APIs without affecting existing ones.
  • Data Sources Will Not Change: If no additional data sources will ever be needed, a single Store can simplify the architecture and reduce maintenance overhead.

​
Making the Decision

Use this flow chart to decide whether to use a single Store or multiple Stores.

How to Use the Flow Chart:

  • Start at the top of the chart.
  • Answer each question with “yes” or “no”.
  • Green paths represent “yes”.
  • Red paths represent “no”.

​
Trails App Decision

For the Trails app, we decided on multiple Stores for the Trail Detail page because:

  • Data sources are independent with different update frequencies.
  • Caching requirements vary significantly.
  • Partial functionality is valuable. For example, showing trail info without weather data.
  • Data merging is straightforward.
  • Future expansion is likely.

​
Implementation Tips

When Using Multiple Stores:

  • Create a repository layer to combine data from different Stores.
  • Use appropriate caching strategies for each Store.
  • Implement clear error handling for each Store.
  • Use Kotlin Flows to combine data streams.

When Using a Single Store:

  • Design a robust domain model that accommodates all data.
  • Implement careful error handling that considers partial data.
  • Use appropriate validation rules for different data types.

​
Conclusion

The decision between single or multiple Stores isn’t always clear-cut. There’s usually no universally right answer. The best choice will depend on your app’s specific requirements and constraints. Focusing on these key decision factors will help you make the best choice for your app.

Overview