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.PrerequisitesBefore diving in, you should:
- Complete the Quickstart.
- Have an understanding of the core Store concepts.
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.
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: Whether the data sources are closely related and often used or updated together, or if they are independent or loosely coupled.
- Caching Strategies: Whether the data sources have different caching needs.
- Error Handling: Whether the data sources have different error handling requirements.
- Complexity of Data Merging: Whether a single Store simplifies working with your data.
- Scalability and Extensibility: Whether other data sources need to be added in the future.
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.