How jjannat04/dhaka-threads-backend works
1. What this repo is
- A Django REST Framework backend for the Dhaka Threads e-commerce platform.
- It exposes a JSON API to a separate frontend client; this repo is not the UI itself.
2. Top-level runtime boundary
- manage.py is the Django command entry point.
- cloth_store/ is the project configuration package: settings.py, urls.py, asgi.py, and wsgi.py.
- cloth_store/urls.py is the central request router that likely mounts the API app and the Django admin.
3. Main application boundary
- The functional backend lives in the single Django app store/.
- That app contains the domain model, API views, serializers, URL routes, admin integration, and migrations.
- This is the main place to diagram business logic and persistence.
4. Domain/data layer
- store/models.py defines the e-commerce entities and relationships.
- The migration history shows evolving models for things like orders, wishlists, and order status, indicating a relational schema managed through Django ORM.
- Data is stored in a relational database, with support for PostgreSQL or SQLite per the README.
5. API/service layer
- store/api_views.py is the request-handling layer for the REST API.
- store/serializers.py converts ORM objects to/from JSON and is the main validation/shape boundary between HTTP payloads and database records.
- store/urls.py maps API endpoints to those views.
6. Authentication and user-scoped resources
- The backend uses JWT authentication via djangorestframework-simplejwt.
- Protected flows include login/refresh/logout and user-specific resources such as cart, wishlist, reviews, and profile updates.
- The key architectural boundary here is that many endpoints are scoped to the authenticated user and should not expose other users’ data.
7. E-commerce feature partitioning
- The API is organized around product catalog management, cart/wishlist operations, review/rating actions, and user profile handling.
- Product data is read/write through the API; user-owned collections like cart and wishlist are persisted server-side.
- Reviews are tied to authenticated users and products, which makes product detail data a combined read path from multiple domain tables.
8. Admin and operational back office
- store/admin.py integrates models with the Django admin for manual management.
- This gives the project a second interface to the same database, separate from the public API.
9. Infrastructure and deployment
- Dependencies show the backend is production-ready with Gunicorn and Whitenoise for serving Django in deployment.
- python-decouple indicates environment-driven configuration, and psycopg2-binary supports PostgreSQL.
- The README says deployment is on Render; vercel.json and build_files.sh are present as deployment/build artifacts, but the core runtime is the Django API service.
10. Static/media handling
- static/ exists for collected/static assets; Pillow in dependencies suggests image handling for products or related media.
- There is no large frontend codebase here; static files are infrastructure support, not the primary application surface.
11. End-to-end data flow
- Frontend client sends HTTP requests with JWTs.
- Django routes the request to store/api_views.py.
- Views query/update Django ORM models, using serializers for validation and JSON formatting.
- Responses go back to the client; writes are persisted in the database and enforced through auth and model relationships.
12. Useful diagram framing
- Draw this as a three-tier backend: HTTP/API layer → DRF view/serializer layer → ORM/database layer.
- Surround it with two important external boundaries: JWT auth and the separate frontend client that consumes the API.
Main entry points: models.py Models · urls.py Root routes · api_views.py API views · manage.py manage.py
Components 15
Django runtime
Process entrypoints and project configuration
- manage.py · Command-line entry into the Django project
manage.py - Settings · Environment-driven Django configuration
cloth_store/settings.py - Root routes · Top-level URL dispatcher for API and admin
cloth_store/urls.py - ASGI/WSGI · Django application interfaces for deployment
cloth_store/asgi.py
Store app
Core e-commerce API, domain, and admin
- API routes · Maps store endpoints to view handlers
store/urls.py - API views · Request handling for catalog, cart, wishlist, reviews, and profile flows
store/api_views.py - Serializers · Validates and shapes JSON for ORM objects
store/serializers.py - Models · E-commerce entities and relationships managed through the ORM
store/models.py - Admin · Django admin integration for manual management
store/admin.py - Migrations · Versioned database evolution for store models
store/migrations/0001_initial.py
External boundaries
Client, auth, database, and deployment surfaces
- Frontend client · Separate UI that consumes the JSON API
- JWT auth · Token-based authentication and protected user-scoped endpoints
- Relational DB · PostgreSQL or SQLite backing store for domain data
- Render deploy · Production deployment target for the Django API
- Static assets · Collected static files and deployment assets
static/placeholder.txt
Connections 17
- Frontend client → Root routes: HTTP API calls · Frontend sends requests to the Django API
- Root routes → API routes: mounts · Root router delegates API paths to the store app
- Root routes → Admin: admin path · Root routing exposes Django admin separately
- API routes → API views: routes to · Endpoint definitions dispatch to REST handlers
- API views → Serializers: validates via · Views serialize requests and responses through DRF serializers
- API views → Models: reads/writes · API handlers query and persist domain objects
- Serializers → Models: maps · Serializers bridge JSON payloads and ORM entities
- Models → Relational DB: persists to · ORM stores product, order, wishlist, and related data
- Migrations → Models: evolves · Migration files capture schema changes over time
- Admin → Models: manages · Admin interface operates on the same domain models
- Frontend client → JWT auth: presents token · Client includes JWTs for protected requests
- JWT auth → API views: protects · Authenticated endpoints enforce user-scoped access
- manage.py → Settings: loads · Django command entry uses project settings
- manage.py → Root routes: boots · Management entrypoint starts the configured application
- ASGI/WSGI → Settings: configures · Runtime interfaces use the same Django settings
- Render deploy → ASGI/WSGI: hosts · Deployment runtime serves the Django app
- Render deploy → Static assets: serves · Deployment includes static asset handling