You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Refactor Value class and backends to use unified path-based approach
- Remove storage_type from Value class
- Update ValueBackend interface to use path and environment
- Add SimpleValueBackend for non-sensitive values
- Update test cases and documentation
- Add ADR for unified backend approach
# ADR-005: Unified Backend Approach for Value Storage
2
+
3
+
## Status
4
+
Proposed
5
+
6
+
## Context
7
+
Currently, the Value class handles two distinct storage types: local and remote. This creates a split in logic within the Value class, requiring different code paths and validation rules based on the storage type. This complexity makes the code harder to maintain and test.
8
+
9
+
## Decision
10
+
We will remove the storage_type distinction from the Value class and implement a SimpleValueBackend for non-sensitive data (previously handled as "local" storage). This means:
11
+
12
+
1. Value class will:
13
+
- Only interact with backends through a unified interface
14
+
- Not need to know about storage types
15
+
- Have simpler logic and better separation of concerns
16
+
17
+
2. Storage backends will:
18
+
- Include a new SimpleValueBackend for non-sensitive data
19
+
- All implement the same ValueBackend interface
20
+
- Be responsible for their specific storage mechanisms
21
+
22
+
3. Configuration will:
23
+
- Use SimpleValueBackend internally for non-sensitive values
24
+
- Use secure backends (AWS/Azure) for sensitive values
25
+
- Backend selection handled by the system based on value sensitivity
26
+
27
+
## Consequences
28
+
29
+
### Positive
30
+
1.**Cleaner Value Class**
31
+
- Removes storage type logic
32
+
- Single consistent interface for all operations
33
+
- Better separation of concerns
34
+
35
+
2.**Unified Testing**
36
+
- All storage types tested through the same interface
37
+
- No need for separate local/remote test cases
38
+
- Easier to mock and verify behavior
39
+
40
+
3.**More Flexible**
41
+
- Easy to add new backend types
42
+
- Consistent interface for all storage types
43
+
- Clear extension points
44
+
45
+
4.**Better Security Model**
46
+
- Storage backend choice driven by data sensitivity
47
+
- Clear separation between sensitive and non-sensitive data
48
+
- Explicit in configuration
49
+
50
+
### Negative
51
+
1.**Slight Performance Impact**
52
+
- Additional method calls for simple value operations
0 commit comments