SeforimTracker

Most mainstream reading trackers assume a Western publishing model: single-language metadata, stable titles, and edition-based organization. Classical Jewish texts operate differently. Canonical works persist across many editions, are cited by internal division schemas rather than publication year, and circulate under multiple transliterations in both Hebrew and Latin characters.

There is currently no dedicated application that allows Jewish learners to track their reading or ownership of core Jewish texts in a way that reflects these realities. I set out to design a system that models rabbinic literature as it actually functions.

Project Goals

Functional Goals

• User authentication
• Personal reading library
• Reading status management
• Per-item notes
• Bilingual metadata support
• Search across multiple fields

Architectural Goals

• Separate canonical works from user data
• Design for future alias support
• Use strict TypeScript
• Deploy a production-ready backend with controlled CORS

Constraints

• Solo developer
• Bootcamp timeline
• No external canonical data source
• MVP scope (no admin UI, no public profiles)

Architecture & Data Modeling

A core architectural decision was to separate canonical works from user-specific reading data.

The seforim table represents the work itself.
The library_items table links a user to a work and stores reading status and notes.

This normalized structure prevents duplication of canonical data, allows multiple users to reference the same work, and supports future extensibility (such as alias handling and tagging). It mirrors the domain distinction between shared cultural texts and individual reading activity.

The frontend uses Redux Toolkit with async thunks to centralize API interactions and maintain predictable state transitions. While local state would have been sufficient for a small application, Redux provides a scalable pattern as the domain model grows more complex.

Authentication Architecture

SeforimTracker uses JSON Web Tokens (JWT) for stateless authentication.

After login, the backend issues a signed token containing the user’s identifier. The client includes this token in the Authorization header for subsequent requests. Protected routes are secured via middleware that verifies the token and attaches the authenticated user to the request context.

Because the API is stateless, the server does not maintain session memory. Each request contains its own authentication data, simplifying deployment and scalability.

Technical Challenges

Bilingual Search

Search combines Hebrew and English titles, author names, and user notes into a unified experience. The MVP uses client-side filtering; future iterations will move search server-side with indexed database queries for performance.

Strict TypeScript

Enabling strict compiler settings surfaced edge cases around optional fields and request validation, improving API clarity and reducing ambiguity.

CORS Configuration

Production deployment required explicit origin validation. Allowed origins are read from environment variables, preventing unintended cross-origin access.

Design Philosophy

This project reflects my interest in domain-aware software. Bibliographic systems encode assumptions about how knowledge is structured. By modeling canonical Jewish texts separately from user interaction, the system respects the internal logic of the tradition it serves.

Features Roadmap

Planned enhancements focus on canonical modeling and performance:

• Move search logic server-side with database indexing
• Add role-based admin tools for canonical management
• Implement pagination and performance optimization
• Enable public profiles and shared reading lists
• Add an “owned” property for personal library record-keeping