rebecca-roussel/ecoride

1. Overall shape

EcoRide is a Symfony 7 application built as a classic server-rendered stack: HTTP requests enter through Nginx, are handled by PHP-FPM, routed to Symfony controllers, and rendered mainly with Twig templates.

2. Request flow

The main runtime path is: browser → Nginx → public/index.php → controller → service layer → PostgreSQL/MongoDB/email/geocoding as needed → Twig view → HTML response. The architecture is centered on synchronous server-side rendering rather than an API-first front end.

3. Presentation layer

The UI lives in templates/ and public/. Twig handles page composition, fragments, and email templates; public/css and public/js contain page-specific assets for features like login, geocoding suggestions, results, profiles, roles, and dashboards. Static files are served directly by Nginx.

4. Controller layer

src/Controller/ is organized by business journey: public pages (Accueil, Contact, MentionsLegales, Credits), identity flows (Connexion, Inscription, MotDePasseOublie, ReinitialiserMotDePasse), ride flows (Recherche, Resultats, Details, PublierCovoiturage, ParticiperCovoiturage), account/vehicle management (Profil, TableauDeBord, GererVehicules, Historique), and back-office areas (EspaceEmploye, EspaceAdmin, GererRoles). ApiGeocodageController is the main HTTP endpoint for autocomplete/geocoding behavior.

5. Service layer

src/Service/ contains the actual business and persistence logic. The code deliberately avoids an ORM: services use PDO-based PostgreSQL access and keep SQL explicit. The service set is split by concern: connection handling, user session state, emailing, address geocoding, event logging, and per-domain persistence services.

6. Primary data store: PostgreSQL

PostgreSQL holds the structured business data: users, vehicles, rides, participations, credits, history, password reset state, and admin/employe-related records. The README indicates that important invariants are enforced in the database itself with constraints, functions, and triggers, so some business rules live below the application layer.

7. Secondary data store: MongoDB

MongoDB is used as an operational event journal rather than the main business database. It records chronological events such as logins, participations, incidents, moderation actions, and suspensions. This makes the architecture split between transactional business data in PostgreSQL and trace/audit data in MongoDB.

8. Mail and external integrations

EnvoiCourriels supports email-based workflows such as password reset and ride validation/cancellation. In local development the app uses MailHog, so email delivery is observable without sending real mail. GeocodageAdresse powers address lookup/suggestions for ride publication and search.

9. Security and session boundary

Authentication/session state is handled explicitly through SessionUtilisateur. The app uses password hashing, CSRF protection in forms, reset tokens with limited lifetime, and a set of HTTP security headers configured at the web server level. Environment secrets are kept in .env variants rather than in code.

10. Runtime and deployment

The repo is container-first. Docker Compose orchestrates Nginx, PHP-FPM, PostgreSQL, MongoDB, and MailHog in development; a production compose file and Nginx production config provide the deployment boundary. Code is mounted read-only into Nginx in production, and DBs are kept off the public network.

11. Build, test, and release support

GitHub Actions workflows support continuous integration and deployment. Tests live under tests/ and include application-level checks plus database connectivity tests. The docs/sql/ scripts initialize the schema and demo data, and the docker/sauvegardes/ scripts handle backup/restore of PostgreSQL and MongoDB.

12. Documentation as part of the architecture

The repository is unusually documentation-heavy: generated code docs, UML, data-model diagrams, UI mockups, deployment notes, and user manuals all exist alongside the code. For architecture diagramming, this indicates the project was designed with explicit separation between business workflows, data model, and operational deployment.