My Maps

My Maps is a personal mapping project built to keep track of places worth remembering.

The core idea is simple: create maps, add markers, enrich them with notes, categories, links, and media, and keep a personal memory of places you do not want to forget. I originally built it as a practical tool, but also as a playground to explore product ideas, domain-driven organization, and a clear separation between frontend and backend responsibilities.

This project is no longer maintained.

It is an older codebase, and some technical choices are now outdated. I am open sourcing it anyway because there may still be useful ideas inside: architecture experiments, project organization, testing strategies, or just small implementation details that can help other people learn from it.

Project Status

• Status: archived / not maintained
• Expect outdated dependencies and conventions
• Expect rough edges and historical choices I would probably not make the same way today
• Shared for learning purposes, not as a production-ready foundation

What The Project Does

The application lets users:

• create and browse maps
• add markers to a map
• describe places with text, links, categories, and images
• manage map-related assets in a gallery
• share map access through dedicated routes
• manage cartographers and marker categories through admin screens

Tech Stack

• Frontend: React 18, TypeScript, Material UI, React Router, Mapbox-related libraries
• Backend: PHP 8, Symfony 5.4
• Database: PostgreSQL 11
• Async processing: Symfony Messenger with a dedicated consumer
• Local infrastructure: Docker Compose, Traefik, Mailhog, Adminer, MinIO
• Testing: React Testing Library, PHPUnit ecosystem tools, PhpSpec, Behat, Cypress experiments

Running The Project

The project was designed to run through Docker.

Prerequisites

• Docker
• Docker Compose
• Make

Recommended local start

make app-dev

This target does the following:

• starts the development stack
• installs frontend and backend dependencies
• recreates the database
• restores data from dump.sql
• starts the Symfony message consumer

Available local services

After startup, the main entry points are:

• App: http://localhost
• Mailhog: http://mailer.localhost
• Adminer: http://adminer.localhost
• MinIO console: http://storage.localhost
• Traefik dashboard: http://localhost:8080

Important note about the database

The default make app-dev workflow restores the database from the repository-level dump.sql file.

If you want to start the containers without restoring the database, use:

make up-dev
make dependencies

Then you can decide whether to run:

make db
make db-migration

or:

make db-restore

depending on the setup you want.

Useful Commands

make up-dev         # start the development stack
make down-dev       # stop and remove development containers/volumes
make dependencies   # install frontend and backend dependencies
make db             # recreate the database
make db-migration   # run doctrine migrations
make db-restore     # restore the database from dump.sql
make web-tests      # run frontend lint + unit tests
make api-tests      # run backend lint + specs + behat suites
make critical-use-case  # run Cypress-based end-to-end scenarios

Repository Organization

The repository is split into a few major parts:

• web/: React frontend
• api/: Symfony backend
• docker/: Dockerfiles and infrastructure config
• critical-use-cases/: Cypress-based end-to-end experiments
• dump.sql: database snapshot used by the local bootstrap flow
• Makefile: main developer entry point

How The Code Is Organized

Frontend

The frontend is mostly organized by business capability instead of by technical layer alone.

• web/src/application/: app bootstrap, auth, i18n, shared application-level concerns
• web/src/cartography/: the main product area
• web/src/cartography/map-board/: map browsing, map editing, marker interactions, gallery flows
• web/src/cartography/admin/: admin screens for cartographers and marker categories
• web/src/identity/: login, account creation, password reset flows

This structure reflects a choice I liked at the time: grouping UI, services, tests, and domain concepts close to the feature they belong to.

Backend

The backend follows a more explicit domain/application/infrastructure split.

• api/src/Domain/: business concepts and use cases
• api/src/Infrastructure/: web controllers, persistence, storage, framework integration
• api/config/: Symfony configuration
• api/tests/: specification, integration, and use-case tests
• api/features/: Behat feature files

The cartography domain contains the main business logic around maps, markers, galleries, categories, and cartographers. The identity domain handles account-related flows.

Architectural Choices

A few choices shaped the project:

• Separate frontend and backend applications, each with its own tooling
• Feature-oriented organization on the frontend
• Domain-oriented organization on the backend
• A distinction between command-style write flows and query-style read flows in the API
• Heavy use of Docker so the project could be run with a consistent local environment
• Dedicated test layers to cover UI behavior, domain behavior, and end-to-end scenarios

Some of these choices still make sense to me. Others clearly show the age of the project. That is also part of why I am sharing it: seeing old design decisions in context can still be useful.

Maintenance Notice

I am not planning active maintenance, dependency upgrades, or feature work on this repository.

If you browse this codebase, the best mindset is:

• use it as a reference
• borrow ideas carefully
• validate anything before using it in a modern production project

Why Open Source It?

Because even an old project can still be helpful.

If you are learning how to structure a full-stack app, separate concerns, test business flows, or think about map-based product features, you might still find something interesting here.