TodoPet

TodoPet is a study full-stack app for learning product development end to end. It is a training project, not a production-ready service.

Live preview: https://todopet.netlify.app/login

What it is

TodoPet is a task manager where you can:

• create and organize tasks in folders
• complete and restore tasks
• manage sorting/reordering
• view a global Completed page with filters
• use auth flows (sign in, sign up, logout)

The core goal is learning through iteration: build, break, test, refactor.

Tech Stack

Frontend:

• Vue 3 + TypeScript
• Vite
• Apollo Client (GraphQL)
• Vitest + Playwright

Backend:

• Ruby on Rails
• GraphQL
• PostgreSQL (for production setup)
• RSpec (request/graphql coverage), plus legacy Rails test folder still present

Repository Structure

• /frontend — Vue client app
• /server — Rails + GraphQL API

Local Run

Prerequisites:

• Node.js 20+
• Ruby/Bundler (project Ruby from /server/.ruby-version)
• PostgreSQL

1. Backend setup

cd server
bundle install
bin/rails db:prepare
bin/rails s

2. Frontend setup

cd frontend
npm install
npm run dev

3. Open app

• Frontend: http://127.0.0.1:5173 (or Vite printed URL)
• Backend GraphQL: http://127.0.0.1:3001/graphql (depending on your Rails port config)

Tests

Frontend:

cd frontend
npm run test:unit
npm run test:e2e

Backend:

cd server
bundle exec rspec

Notes and Disclaimer

• This project is built for learning and portfolio/interview demonstration.
• No warranty, no SLA, and no responsibility for production use.
• Some workflows/configs may evolve while experiments are in progress.

Feedback

If you find a bug, have questions, or want to review architecture decisions, open an issue or contact me through the repository profile.

Screenshots

Architecture Decisions

1. GraphQL as the single API layer
   Frontend and backend communicate through typed GraphQL contracts, which keeps feature work focused and predictable.

2. Resolver-level filtering for todos
   Todo filtering is handled in backend resolvers, so business rules are centralized and consistent across views.

3. Explicit Inbox semantics
   Inbox is treated as “unassigned tasks only” (folder_id = null) instead of “all active tasks”.

4. Reusable Apollo cache utilities
   Cache list operations are abstracted into shared helpers to reduce mutation-specific boilerplate.

5. Type-first frontend code
   The UI layer is written with TypeScript-first assumptions to reduce runtime bugs and improve maintainability.

6. Split test strategy
   Unit tests (Vitest) cover component/composable behavior, request specs cover GraphQL mutation contracts, and Playwright is used for smoke e2e flows.