MyChronicle

Why I Built This

As someone who consumes many different types of media, I found it difficult to track everything across multiple tracker sites—especially since none of them support all media types in one place. I also enjoy leaving reviews and personal notes on the media I consume. Because of this, I decided to build MyChronicle.com to solve that problem.

What It Does

MyChronicle pulls data from third-party APIs and allows users to search across all media types in one place. Users can maintain personal lists, leave quick notes, and track all their media consumption seamlessly, regardless of the media type.

How It Works

• FastAPI backend handles data requests from multiple third-party APIs
• MongoDB stores user data, authentication, and reviews
• React frontend provides responsive interface

Third-Party APIs

I used Pydantic for data modeling and asynchronous requests to efficiently fetch metadata from third-party APIs.

Backend

• • I used Pydantic for data modeling due to its seamless compatibility with FastAPI.
• • The backend is built with FastAPI, handling API requests and CORS configuration.
• • Since the final data schema was not fully defined upfront, I chose MongoDB for its flexibility, scalability, and ease of evolving data models.
• • JWT-based authentication is implemented to ensure secure user access.
• • Structured logging is implemented using structlog.
• • I leveraged FastAPI's dependency injection system to manage shared dependencies cleanly and efficiently.

Frontend

• • The frontend is built using React + Vite for a modern and fast development experience.
• • I used TanStack Query to manage server state and prevent unnecessary or repetitive network requests.
• • Styling is implemented using Tailwind CSS for its strong synergy with React and utility-first workflow.

Deployment

• • The backend is Dockerized and deployed on a Google Cloud Compute Engine (e2 machine).
• • The frontend is deployed on Cloudflare.

Backend

Frontend

DevOps

Architecture

Avoiding rate limits from third-party APIs

To prevent hitting rate limits, data is fetched using pagination and bulk requests for the featured media page.

Handling multiple metadata schemas

Supporting different media types required extra care, as each type has unique fields and response structures. This was addressed by defining separate response models and handling variations in metadata consistently.

Richer Media Detail Pages

Expand the media detail pages with more in-depth information such as extended metadata, trailers, screenshots, related content, and user activity history.

Support for Additional Media Types

Add new media types including Games, Books, and Comics to broaden platform coverage and provide a truly unified media tracking experience.