Skip to main content

​
Overview

Stringboot is built on three core principles: offline-first architecture, smart caching, and efficient synchronization. Understanding these concepts will help you build better localized applications.

​
Three-Layer Cache Architecture

Stringboot uses a sophisticated three-layer caching system for optimal performance:
1

Layer 1: In-Memory Cache

LRU, 1000 entries by default Access: <1ms Cache miss
2

Layer 2: Local Database

IndexedDB / Room / CoreData Not Found
3

Layer 3: Network Sync

String-Sync v2 with ETag Access: 100-500ms
Fastest access - Strings are cached in memory for instant retrievalLRU Eviction - Least recently used strings are removed when cache is fullFrequency-based priority - Frequently accessed strings stay in cache longerPlatform-specific size: Configurable (default: 1000 entries)
Persistent storage - Survives app restarts and device rebootsFull offline capability - All synced strings available without networkTechnology: IndexedDB (Web), Room (Android), Core Data (iOS)Soft deletes - Removed strings are marked, not immediately deleted
String-Sync v2 Protocol - Efficient delta sync for changed strings onlyETag-based caching - Prevents unnecessary downloadsAutomatic retries - Failed requests retry with exponential backoffBackground sync - Non-blocking network operations

​
String-Sync v2 Protocol

Stringboot uses a custom delta synchronization protocol to minimize bandwidth and ensure fast updates.

​
How Delta Sync Works

1

Metadata Check

Client sends stored ETag to server
GET /strings/meta
If-None-Match: "etag123abc"
2

Server Response

Case 1: No changes (304 Not Modified)
HTTP/1.1 304 Not Modified
Result: No download needed, cache is currentCase 2: Updates available (200 OK)
{
  "etag": "etag456def",
  "changedKeys": ["welcome_message", "app_title"]
}
3

Download Delta

Client downloads only changed strings
GET /strings/delta?keys=welcome_message,app_title&lang=en
4

Update Cache

SDK updates memory cache and local database with new strings

​
Bandwidth Savings

Traditional Approach

Every sync: Download full catalog (~100-500KB)Monthly bandwidth: ~3-15MB per user

String-Sync v2

Metadata check: ~2KBDelta download: Only changed stringsMonthly bandwidth: ~50-200KB per user

​
Offline-First Architecture

Stringboot is designed to work perfectly offline after the initial synchronization.

​
Offline Behavior

  • With Network
  • Without Network
  1. SDK checks memory cache first
  2. Falls back to local database
  3. Syncs with server in background
  4. Updates cache with latest strings

​
Offline Capabilities

✓ All previously synced strings available
✓ Language switching works with cached languages
✓ No error messages or failed requests
✓ Zero latency - instant string retrieval
New or updated strings require network connectivity

​
Smart Memory Management

Stringboot automatically manages cache based on access patterns and memory pressure.

​
LRU Cache with Frequency Tracking

The SDK uses a Least Recently Used (LRU) cache enhanced with access frequency tracking: 
// High-frequency strings stay in cache
"welcome_message" -> accessed 150 times -> stays in memory
"rare_error_msg" -> accessed 2 times -> evicted when cache full

​
Platform-Specific Optimizations

  • Web
  • Android
  • iOS
  • Memory cache: 1000 entries
  • IndexedDB: Unlimited storage (quota-based)
  • Automatic cleanup on storage pressure

​
Language Management

​
Language Preloading

For instant language switching, preload languages into memory cache: 
// Preload Spanish for instant access
await StringBoot.preloadLanguage('es', maxStrings = 500);

// Now language change is instant
await StringBoot.changeLanguage('es'); // <100ms

​
Available Languages

Get list of languages with content: 
const languages = await StringBoot.getActiveLanguages();
// [{ code: 'en', name: 'English' }, { code: 'es', name: 'Spanish' }]

​
Error Handling & Fallbacks

Stringboot provides multiple fallback mechanisms to ensure your app always has content:

​
Fallback Hierarchy

1. Requested string from network/cache
   ↓ (not found)
2. String from local app bundle (Localizable.strings / strings.xml)
   ↓ (not found)
3. Key wrapped in markers: "??missing_key??"

​
Network Error Handling

Error TypeSDK Behavior
Network timeoutUse cached data, retry in background
401/403 UnauthorizedLog error, use cache, disable sync
404 Not FoundLanguage doesn’t exist, use fallback
429 Rate LimitedExponential backoff, max 3 retries
500+ Server ErrorRetry with backoff, use cache

​
Performance Characteristics

​
Lookup Times

SourceTypical LatencyUse Case
Memory cache<1msFrequently accessed strings
Local database5-20msPreviously synced strings
Network (cached)50-100msETag check, no download
Network (delta)100-300msDownload changed strings
Network (full)200-500msFirst sync or force refresh

​
Best Practices

Do: Preload on Start

Preload common strings synchronously during app initialization

Don't: Force Refresh Often

Avoid bypassing ETag checks - wastes bandwidth

Do: Use Watchers/Hooks

Use reactive APIs for automatic UI updates

Don't: Poll for Updates

SDK handles sync automatically - no need to poll

​
Next Steps

Web SDK

Implement these concepts in web apps

Android SDK

Apply concepts to Android development

iOS SDK

Use concepts in iOS applications

Best Practices

Production-ready patterns