SessionStorage interface defines the contract that all session storage implementations must follow. This ensures consistent behavior across different database adapters.
Interface Definition
From the source code atpackages/apps/session-storage/shopify-app-session-storage/src/types.ts:
Methods
storeSession
Creates or updates a session in storage.The session object to store. Contains all authentication and user data.
Returns
true if the session was successfully stored, false otherwise.- If a session with the same
idexists, it will be updated - If no session exists with that
id, a new one will be created - This implements an “upsert” pattern (update or insert)
loadSession
Retrieves a session from storage by its ID.The unique identifier of the session to load.
Returns the
Session object if found, or undefined if no session exists with that ID.- Offline sessions:
offline_{shop} - Online sessions:
{shop}_{userId}
deleteSession
Deletes a single session from storage.The unique identifier of the session to delete.
Returns
true if the session was successfully deleted, false otherwise.- Attempting to delete a non-existent session typically returns
true - This method is idempotent (safe to call multiple times)
deleteSessions
Deletes multiple sessions in a single operation.Array of session IDs to delete.
Returns
true if all sessions were successfully deleted, false otherwise.- Cleaning up all sessions for a shop when app is uninstalled
- Batch deletion of expired sessions
- Removing all online sessions for a shop
findSessionsByShop
Finds all sessions associated with a specific shop.The shop domain (e.g., ‘example.myshopify.com’).
Returns an array of
Session objects. Returns an empty array if no sessions are found.- Both online and offline sessions for the shop
- Active and expired sessions (check
expiresfield) - Sessions for all users who have accessed the app from that shop
Implementation Guidelines
If you’re implementing a custom session storage adapter, follow these guidelines:Thread Safety
Implementations should be safe for concurrent access. Multiple requests may attempt to read/write sessions simultaneously.
Error Handling
Implementations should:- Catch database errors and log them appropriately
- Return
falseon storage/deletion failures rather than throwing - Return
undefinedfromloadSessionon errors, not throw
Performance Considerations
- Index the
shopcolumn for efficientfindSessionsByShopqueries - Use upsert operations in
storeSessionto avoid race conditions - Implement connection pooling for database adapters
- Consider caching for frequently accessed sessions
Data Serialization
Different storage backends require different serialization:- Relational (SQL)
- Document (MongoDB)
- Key-Value (Redis, KV)
Store each session property as a separate column:
Deserialization
When loading sessions, reconstruct theSession object:
Testing Your Implementation
The SDK provides testing utilities:The
batteryOfTests function runs a comprehensive test suite that verifies your implementation correctly handles all SessionStorage methods.Additional Interfaces
RdbmsSessionStorageOptions
Configuration for relational database adapters:Name of the table to store sessions.
Configuration for the migration system.
SessionStorageMigrator
Handles database migrations for session storage:Most users don’t need to interact with the migrator directly. It runs automatically when initializing RDBMS-based storage adapters.
Related Resources
Database Adapters
Setup guides for each official adapter
Session Storage Overview
Learn about session storage concepts