How neoastra303/socialmedia-app works
1. Overall shape
This is a monolithic Django 5.1 application organized into feature apps rather than separate services. The main runtime is Django served over ASGI, with Daphne/Channels handling both normal HTTP traffic and WebSocket traffic.
2. Request entry points
socialmediaproject/urls.py is the main HTTP router, while socialmediaproject/routing.py wires WebSocket routes for chat and notifications. asgi.py is the async entrypoint; wsgi.py exists for traditional deployment, but the presence of Channels makes ASGI the important boundary.
3. Core domain apps
The business logic is split across posts, users, direct_messages, notifications, reports, and two search-related apps: search and searchapp. Each app owns its own models, views, forms, URLs, tests, and in several cases migrations, which makes the architecture modular but still tightly coupled through shared Django models and auth.
4. User and identity subsystem
users is the identity hub: registration, email-based authentication, profiles, privacy, blocking, follow requests, and settings live here. It also contains a custom authentication backend (users/backends/email_auth.py), signals, and background tasks, so this app is not just UI—it governs login behavior and account lifecycle.
5. Content subsystem
posts is the largest domain area and appears to own feeds, post CRUD, comments, reactions, bookmarks, hashtags, stories, and media upload handling. It also includes a DRF serializer layer, a custom template tag for linkifying content, and a management command (cleanup_stories) for expiring time-limited story records.
6. Messaging and notifications
direct_messages and notifications are the real-time interaction layer. Both have WebSocket consumers, which means server events can be pushed instantly to connected clients; notifications also have a classic database-backed list view/template for persisted notifications.
7. Moderation and safety
reports handles abuse/content reporting and moderation workflows. Cross-cutting safety concerns are reinforced by middleware for exception handling and rate limiting, plus a shared file validation utility in utils/file_validation.py for upload constraints.
8. Search
The search functionality is split into a backend-facing search app and a UI-facing searchapp app with templates for advanced search and results pages. This suggests search logic and presentation are deliberately separated, even though they are still within the same Django project.
9. Presentation layer
Server-rendered templates are the main UI mechanism. Shared layout lives in templates/base.html, while app-specific templates exist for posts, users, messages, notifications, reports, and search. Static assets are simple CSS/JS files, with built outputs mirrored under staticfiles/ for deployment.
10. Data and persistence
The system relies on Django ORM models and migrations in each app, with PostgreSQL as the intended production database and SQLite as a fallback for simpler environments. Redis is used for cache and Channels infrastructure when available, but the README indicates graceful fallback to database cache and in-memory channels when Redis is absent.
11. Async and background processing
Real-time communication is handled through Channels consumers, while background work is handled by django-background-tasks through users/tasks.py and scheduled maintenance commands like story cleanup. This separates immediate request/response behavior from deferred or periodic work.
12. Platform and deployment boundary
The repo is container-ready with Dockerfile, docker-compose.yml, and GitHub Actions tests workflow, so deployment is treated as part of the architecture. The project also includes internationalization, secure headers, and environment-driven configuration in settings.py, which makes runtime behavior depend heavily on deployment environment rather than hardcoded defaults.
Main entry points: urls.py Main router · templates Shared templates · users Users · posts Posts
Components 16
Project core
Django project configuration, routing, and runtime entrypoints.
- ASGI entry · Async application entrypoint for Django/Channels.
socialmediaproject/asgi.py - Main router · HTTP URL configuration for the whole project.
socialmediaproject/urls.py - WS router · WebSocket route wiring for Channels consumers.
socialmediaproject/routing.py - Settings · Central Django configuration and environment-driven runtime settings.
socialmediaproject/settings.py
Feature apps
Domain apps that implement the main product capabilities.
- Users · Authentication, profiles, privacy, blocking, follows, settings, and account lifecycle.
users - Posts · Feeds, posts, comments, reactions, bookmarks, stories, media, and serializers.
posts - Messages · Direct messaging views, forms, models, and WebSocket consumers.
direct_messages - Notifications · Persisted notifications plus live push consumers and list views.
notifications - Reports · Abuse reporting and moderation workflows.
reports - Search · Backend search logic and data access.
search - Search UI · Search presentation layer and search result templates.
searchapp - Background work · Deferred tasks and scheduled cleanup jobs.
users/tasks.py
Platform
Shared middleware, utilities, templates, and deployment assets.
- Middleware · Exception handling and rate limiting for request processing.
middleware - Shared templates · Global base layout and shared server-rendered templates.
templates - Static assets · CSS and JavaScript served by the project.
static - File utils · Reusable upload and file validation helpers.
utils/file_validation.py
Connections 30
- ASGI entry → Settings: loads · ASGI runtime uses project configuration.
- ASGI entry → WS router: serves WS · Channels connects ASGI to websocket routes.
- ASGI entry → Main router: serves HTTP · ASGI exposes the main request router.
- Main router → Users: routes · Main HTTP router includes account and profile URLs.
- Main router → Posts: routes · Main HTTP router includes content URLs.
- Main router → Messages: routes · Main HTTP router includes messaging URLs.
- Main router → Notifications: routes · Main HTTP router includes notification URLs.
- Main router → Reports: routes · Main HTTP router includes moderation URLs.
- Main router → Search UI: routes · Main HTTP router includes search UI URLs.
- WS router → Messages: ws consumers · WebSocket routes connect to direct message consumers.
- WS router → Notifications: ws consumers · WebSocket routes connect to notification consumers.
- Posts → Users: authored by · Posts depend on user identity and ownership.
- Posts → File utils: validates media · Content uploads reuse shared file validation.
- Notifications → Users: targets users · Notifications are associated with user accounts.
- Messages → Users: between users · Messaging is anchored in user accounts.
- Reports → Posts: reports content · Moderation workflows act on content objects.
- Reports → Users: reports users · Moderation workflows also cover account abuse.
- Search → Posts: indexes · Search backend queries content data.
- Search → Users: indexes · Search backend queries people and profiles.
- Search UI → Search: presents · Search UI renders backend search results.
- Shared templates → Users: renders · Shared templates include account pages.
- Shared templates → Posts: renders · Shared templates include post views.
- Shared templates → Messages: renders · Shared templates include message views.
- Shared templates → Notifications: renders · Shared templates include notification views.
- Shared templates → Reports: renders · Shared templates include moderation pages.
- Shared templates → Search UI: renders · Shared templates include search pages.
- Static assets → Shared templates: supports UI · Static CSS and JS back the server-rendered templates.
- Middleware → Settings: configured by · Middleware behavior is defined by project settings.
- Background work → Users: scheduled by · Background tasks support account lifecycle work.
- Posts → Background work: cleanup job · Story expiration is handled by scheduled maintenance.