How cyber-hen/portfolio-django works
Purpose and Entry Points
This is a Django 4.2 portfolio-content backend exposing Django Admin and Django REST Framework APIs for projects, blog content, contact messages, skills, and social links. Runtime entry points are manage.py for management/development and config/wsgi.py for WSGI deployment. Root routing is centralized in config/urls.py; settings and installed infrastructure are in config/settings.py.
Application Composition
The domain is split into four Django apps, each following model → serializer → view → URL boundaries:
• Portfolio projects and related presentation data: apps/portfolio/models.py, apps/portfolio/serializers.py, apps/portfolio/views.py.
• Blog posts, categories, and tags: apps/blog/models.py, apps/blog/serializers.py, apps/blog/views.py.
• Contact-message intake and management: apps/contact/models.py, apps/contact/serializers.py, apps/contact/views.py.
• Shared profile-style content such as skills and social links: apps/core/models.py, apps/core/serializers.py, apps/core/views.py.
HTTP Routing and API Boundary
config/urls.py composes the global URL space, including Django Admin and app-specific API prefixes. Each domain owns its route declarations in apps/portfolio/urls.py, apps/blog/urls.py, apps/contact/urls.py, and apps/core/urls.py. Requests enter Django, resolve through the root router, then reach domain views; serializers form the API contract between HTTP payloads and ORM-backed models.
Persistence and Content Administration
Django ORM models are the authoritative persistence layer, backed by PostgreSQL as described by the repository. Models are registered for staff-operated content administration through apps/portfolio/admin.py, apps/blog/admin.py, apps/contact/admin.py, and apps/core/admin.py. This creates two content-management surfaces over the same data: the REST API for frontend integration and Django Admin for privileged editors.
Authentication, Media, and Notifications
The API is intended to support JWT authentication, with security and environment-driven configuration expected in config/settings.py and .env.example. Portfolio and blog features include image-oriented content, with Pillow providing image processing and Django media handling configured at the application boundary. Contact messages are designed to trigger email notifications; this couples the contact workflow to Django’s configured email service rather than to a separate messaging subsystem.
Deployment Topology
The containerized deployment has an application image at Dockerfile, reverse-proxy configuration/image at nginx/nginx.conf and nginx/Dockerfile, and multi-service orchestration in compose.yaml. Nginx is the public HTTP boundary in front of the WSGI Django service; PostgreSQL is the persistent external datastore. CI/CD image build/deployment automation is defined in .github/workflows/docker-image-ci-cd.yml.
Components 19
Django runtime
- Settings & auth config · Environment-driven security, JWT, media, database, and email settings.
config/settings.py - WSGI application
config/wsgi.py - Root URL router · Composes admin and domain API prefixes.
config/urls.py - Django Admin · Privileged editors manage all ORM-backed content.
- Media handling · Processes and serves portfolio and blog images.
Content domains
- Portfolio API
apps/portfolio/views.py - Portfolio models · Projects and presentation data.
apps/portfolio/models.py - Blog API
apps/blog/views.py - Blog models · Posts, categories, and tags.
apps/blog/models.py - Contact API
apps/contact/views.py - Contact messages
apps/contact/models.py - Profile content API
apps/core/views.py - Profile content models · Skills and social links.
apps/core/models.py
Deployment
- Nginx reverse proxy
nginx/nginx.conf - Django application image
Dockerfile - Service orchestration
compose.yaml - Image CI/CD
.github/workflows/docker-image-ci-cd.yml
Other components
- PostgreSQL
- Email service · Receives contact-message notifications.
Connections 27
- Nginx reverse proxy → WSGI application: proxies HTTP to
- WSGI application → Settings & auth config: loads
- WSGI application → Root URL router: dispatches requests through
- Root URL router → Django Admin: routes staff traffic to
- Root URL router → Portfolio API: includes portfolio routes
- Root URL router → Blog API: includes blog routes
- Root URL router → Contact API: includes contact routes
- Root URL router → Profile content API: includes core routes
- Portfolio API → Portfolio models: serializes ORM data
- Blog API → Blog models: serializes ORM data
- Contact API → Contact messages: persists messages
- Profile content API → Profile content models: serializes ORM data
- Portfolio models → PostgreSQL: persists via ORM
- Blog models → PostgreSQL: persists via ORM
- Contact messages → PostgreSQL: persists via ORM
- Profile content models → PostgreSQL: persists via ORM
- Django Admin → Portfolio models: manages
- Django Admin → Blog models: manages
- Django Admin → Contact messages: manages
- Django Admin → Profile content models: manages
- Portfolio models → Media handling: image content
- Blog models → Media handling: image content
- Contact API → Email service: sends notifications
- Service orchestration → Nginx reverse proxy: orchestrates
- Service orchestration → Django application image: runs
- Django application image → WSGI application: serves
- Image CI/CD → Django application image: builds and deploys