Django Flashcards

Question

❓ **Q: What is CSRF middleware in Django?**

Answer 1

✅ **Answer:** It **protects your website** from fake form submissions (attacks from other websites) by **checking for a secret token** 🔒 --- 🔐 **How it works (simple steps)** 1. Django gives your form a **hidden token** like this: ```html ``` 2. When the form is submitted (POST), Django checks: * “Is this token valid?” * “Did it come from our site?” 3. If the token is **missing or fake** → Django **blocks** the request ❌ --- 🤖 **Why it matters** Without this, a hacker could trick your users into submitting forms **without their knowledge**. --- 🎙️ **Interview-Friendly Casual Explanation (Diễn giải để nói trôi chảy):** ***Yeah, so CSRF protection in Django is basically a security layer that prevents other websites from submitting forms on your behalf.*** * When you render a form, Django adds a hidden token to it — and then, when the form is submitted, it checks that the token is still there and valid. * That way, only forms from **your** site can be submitted successfully. * If someone tries to fake a request from another site without the token, Django blocks it. *This stops attacks where a user might be tricked into submitting something dangerous — like changing a password without realizing it.* --- 🔑 **Câu nên nhớ (Highlight để học thuộc):** * “CSRF protection checks for a **valid hidden token** in POST forms.” * “It blocks **fake or cross-site submissions**.” * “Only forms from **your domain** will pass the check.”

Answer 2

🎙️ **Interview-Friendly Casual Explanation (Diễn giải để nói trôi chảy):** ***Yeah, Django’s auth system is a built-in way to handle user authentication — things like login, logout, and session tracking.*** * When a user logs in, Django saves their info in a session, and from then on you can just use `request.user` to access that user in any view. * The middleware (`AuthenticationMiddleware`) runs on every request to attach the logged-in user to it. * Django also gives you ready-made views like `login`, `logout`, and `password_change`, but you can override them if you want to customize the flow. * And if you need to integrate with something like Google, LDAP, or SSO, you can plug in your own backend too. *It’s flexible, secure, and saves a ton of dev time since most of the hard parts are already done for you.* --- 🔑 **Câu nên nhớ (Highlight để học thuộc):** * “Django auth handles **login/logout/session** management out of the box.” * “`request.user` gives access to the current logged-in user.” * “`AuthenticationMiddleware` links the session to the request.” * “You can customize the **user model, views**, or **auth backends**.”

Answer 3

🎙️ **Interview-Friendly Casual Explanation (Diễn giải để nói trôi chảy):** ***Yeah, so authentication is about verifying **who** the user is — like when they log in with a username and password. Once that's done, Django sets `request.user`, and you know who's using the app.*** *Then comes authorization — that’s about checking if that user is **allowed** to do something, like access a view or perform an action.* * You can use decorators like `@login_required` to make sure the user is logged in, or `@permission_required` if you want to check for specific permissions. *So the flow is: first we check **who you are** (authentication), then we check **what you can do** (authorization).* --- 🔑 **Câu nên nhớ (Highlight để học thuộc):** * “**Authentication**: confirms identity → `authenticate()` + `login()`.” * “**Authorization**: checks access → `@login_required`, permissions.” * “You must be **authenticated before authorized**.” * “`request.user` holds the logged-in user after authentication.”

Answer 4

🎙️ **Interview-Friendly Casual Explanation (Diễn giải để nói trôi chảy):** ***Yeah, if you want to customize the user model in Django — like adding extra fields or changing how users log in — you usually subclass `AbstractUser` or `AbstractBaseUser`.*** * `AbstractUser` is easier because it gives you all the default fields and behavior (username, email, etc.), and you just add to it. * `AbstractBaseUser` is more flexible — you build the whole user model from scratch, including fields and manager logic — but it's more work. *Either way, you define your custom user early (before migrations) and set it using `AUTH_USER_MODEL` in `settings.py`.* --- 🔑 **Câu nên nhớ (Highlight để học thuộc):** * “Use `AbstractUser` to extend the default user model easily.” * “Use `AbstractBaseUser` for full customization (email login, etc.).” * “Set `AUTH_USER_MODEL` in settings before migrating.”

Answer 5

🎙️ **Interview-Friendly Casual Explanation (Diễn giải để nói trôi chảy):** ***Yeah, so a session in Django is basically how the server keeps track of a user's state between requests — like whether they’re logged in or what’s in their cart.*** * Behind the scenes, Django stores a session ID in the user’s browser via a cookie, and maps that to session data on the server — usually in the database. * You can store stuff in `request.session` just like a Python dictionary, and it sticks around until the user logs out or the session expires. * You can even choose where to store session data — database, cache, or files — by changing `SESSION_ENGINE`. --- 🔑 **Câu nên nhớ (Highlight để học thuộc):** * “Session stores user-specific data **between requests**.” * “Django saves session data on the server, and links it with a cookie on the client.” * “You interact with it using `request.session['key'] = value`.” * “Storage and expiry are customizable via settings.”

Answer 6

💡 **Answer:** User groups and permissions help manage access control in Django. You can assign permissions to individual users or groups. Groups let you apply the same permissions to many users at once. There are two main types: * **Boolean permissions** like `can_add`, `can_change`, `can_delete`, `can_view` * **Custom permissions** defined in the model’s `Meta` class Permissions can be: * **User-Centric:** Assigned directly to users * **Group-Centric:** Inherited from the user’s groups --- 🎙️ **Interview-Friendly Casual Explanation (Diễn giải để nói trôi chảy):** **Groups and permissions in Django are like a built-in system to control who can do what.** * You can assign permissions directly to users, but when you have a team (say, all editors), it’s better to put them in a group and assign permissions to that group. It makes management way easier. * For example, a user might have `can_view` and `can_change` on an article model — that controls whether they can see and edit content. * You can also define your own custom permissions if your app needs something more specific, like `can_publish`. --- 🔑 **Câu nên nhớ (Highlight để học thuộc):** * “Groups are for reusing permissions across many users” * “Use built-in permissions or define custom ones in the model” * “Direct = user-based, Reusable = group-based”

Answer 7

💡 **Answer:** Unit tests in Django check individual components (like models, views, or forms) in isolation. They're fast and useful during development to catch bugs early. Integration tests verify how different parts of the system work together, like templates, views, and database connections. They simulate full workflows to ensure everything integrates correctly. Django provides `unittest` for both types and `LiveServerTestCase` for full-stack integration testing with a live server.

Answer 8

💡 **Answer:** A **fixture** in **Pytest** is a **reusable function** that provides setup (and optional teardown) code for your tests. Fixtures help prepare test dependencies such as database connections, test data, mock objects, or configs — **automatically injected** into test functions by name. 🔁 Fixture Scope: * `function` (default): runs before each test. * `class`: runs once per class. * `module`: runs once per module. * `session`: runs once per testing session. ✅ **Pytest fixtures** improve **code reuse**, **separation of concerns**, and **readability** in test suites. --- 🎙️ **Interview-Friendly Casual Explanation (Diễn giải để nói trôi chảy):** **Pytest fixtures are like smart helpers that set up what your test needs — before the test even runs.** * For example, if a test needs a database connection or some mock data, you can create a fixture that sets that up. Pytest will automatically pass it into your test function — just by matching the name. * The cool part? You don’t have to call the fixture — Pytest sees the parameter and injects it for you. * You can also control how often a fixture runs: once per test (`function`), or only once for the whole session (`session`) if it’s expensive to set up. --- 🔑 **Câu nên nhớ (Highlight để học thuộc):** * “Fixtures = reusable setup code, injected by name” * “Improves test **clarity**, **reuse**, and **modularity**” * “Fixture scope controls **how often** it runs: function, class, module, session”

Answer 9

💡 **Answer:** The **Django Debug Toolbar** is a powerful development tool that helps developers **inspect, debug, and optimize** their Django applications during development. --- 🔍 Key Features: * **Request/Response Inspection**: See request headers, response content, and redirection data. * **SQL Queries**: View executed SQL queries, time taken, and duplicate queries. * **Template Rendering**: Check which templates were used and how long they took. * **Cache Usage**: Monitor cache hits/misses. * **Logging**: Track custom log output from your app. * **Signals**: See what Django signals were triggered and in what order. --- ✅ **Usage**: Install it with `pip install django-debug-toolbar`, add `'debug_toolbar'` to `INSTALLED_APPS`, configure middleware, and include its URL in `urls.py` (only in `DEBUG=True` mode).

Answer 10

💡 **Answer:** In Django, you handle exceptions at three levels: **middleware**, **views**, and **form fields**. --- 🛡️ **Middleware** * Use `ExceptionMiddleware` and the `process_exception(request, exception)` method to catch all exceptions **before** they reach views. --- 🧠 **Views** **Function-Based Views:** Use decorators like: ``` @require_http_methods(["GET", "POST"]) ``` **Class-Based Views:** Override HTTP methods (`get`, `post`, etc.): ``` def get(self, request): return HttpResponse(status=400) # e.g., bad request ``` --- 📝 **Form Validations** Use `clean()` and raise `ValidationError`: ``` if age < 18: raise ValidationError("Age should be 18 or above") ``` --- ⚠️ **Built-in HTTP Error Responses** * `HttpResponseBadRequest(status=400)` * `HttpResponseServerError(status=500)` * `HttpResponseNotFound(status=404)` * `HttpResponseForbidden(status=403)` * `HttpResponseNotAllowed(status=405)` Django also includes `Http404` and `PermissionDenied` for clearer semantics. --- 🎙️ **Interview-Friendly Casual Explanation (Diễn giải để nói trôi chảy):** **In Django, exception handling is flexible — you can catch errors globally or handle them where they happen.** * If you want to catch *everything* app-wide, use middleware. It’s like a safety net that can log or transform exceptions before they hit your views. * In views, you can return custom error responses — like returning a 400 or 403 if something’s off in the request. * And in forms, validations are super clean — you just raise a `ValidationError` inside the `clean()` method. * Django even gives you shortcuts like `Http404` or `PermissionDenied` so your code stays expressive and readable. --- 🔑 **Câu nên nhớ (Highlight để học thuộc):** * “3 levels: middleware → views → forms” * “Use middleware for global handling, views for logic-based responses” * “Raise `ValidationError`, `Http404`, or use built-in `HttpResponse...` types”

Answer 11

💡 **Answer:** Both `DEBUG` and `ALLOWED_HOSTS` are critical for Django’s **security** and **deployment**. --- 🐞 **`DEBUG`** * Enables detailed error pages and auto-reload in **development** mode. * Set in `settings.py`: ``` DEBUG = True ``` * ❗ **Never set `DEBUG = True` in production**, as it may expose sensitive info. --- 🌐 **`ALLOWED_HOSTS`** * Defines a list of allowed domain names/IPs that your Django app can serve. * Protects against: * **Host header attacks** * **Cache poisoning** * **Clickjacking** Example: ``` ALLOWED_HOSTS = ['example.com'] ``` * In **production**, always set `DEBUG = False` and configure `ALLOWED_HOSTS` properly. --- 🎙️ **Interview-Friendly Casual Explanation (Diễn giải để nói trôi chảy):** **`DEBUG` and `ALLOWED_HOSTS` are two small settings in Django — but they have huge security implications.** * `DEBUG = True` is great while developing — it shows you full error tracebacks, auto-reloads the server, and gives a lot of feedback. But in production, it’s dangerous because it might leak sensitive data. * On the other hand, `ALLOWED_HOSTS` is like a security filter. Django will only serve requests from the domains you list there. If someone tries to spoof the Host header, Django will block it. * So in production, it’s a must to turn off `DEBUG` and define your `ALLOWED_HOSTS` properly — they go hand-in-hand for keeping your app secure. --- 🔑 **Câu nên nhớ (Highlight để học thuộc):** * “`DEBUG = True` shows error details — great for dev, risky in prod” * “`ALLOWED_HOSTS` whitelists domains — protects against spoofing” * “In production: `DEBUG = False` + proper `ALLOWED_HOSTS`”

Answer 12

💡 **Answer:** Deploying a Django application involves several steps to ensure stability, scalability, and security: --- ✅ Deployment Checklist 1. **Set up Virtual Environment** Use `venv` or `virtualenv` to isolate dependencies. 2. **Use Version Control** Manage code with Git to allow rollback and collaboration. 3. **Choose a Production Web Server** Use Nginx, Apache, or Gunicorn instead of Django's dev server. 4. **Configure Production Settings** * `DEBUG = False` * Set `ALLOWED_HOSTS` * Add secure headers 5. **Connect to a Production-Grade Database** Configure PostgreSQL or MySQL in `settings.py`. 6. **Automate with Fabric or Ansible** Automate deployment, server config, and backups. 7. **Use a WSGI Server** Serve Django via Gunicorn or uWSGI for better performance. 8. **CDN for Static/Media Files** Offload static files to S3, Cloudflare, etc. 9. **Add SSL (HTTPS)** Install certificates (e.g., Let’s Encrypt) and force HTTPS. 10. **Enable Error Logging** Configure Django `LOGGING` and web server logs. 11. **Harden Security** * Enable security middleware * Use `SECURE_*` settings * Follow OWASP guidelines 12. **Add Monitoring** Use tools like Sentry, Prometheus, or uptime monitors.

Answer 13

Dưới đây là phần 🎙️ **Interview-Friendly Casual Explanation** cho chủ đề **WSGI in Django**, đúng format bạn yêu cầu: --- 💡 **Answer:** WSGI is a specification that allows web servers (like Nginx or Gunicorn) to communicate with Python web applications, including Django. --- 🔧 **How It Works** * The **web server** receives an HTTP request and passes it to Django via WSGI. * Django processes the request and returns an HTTP response. * The **WSGI server** (e.g., Gunicorn) acts as the bridge between them. --- 🧠 **Core Concepts** * **WSGI Server**: Handles the server-side communication and runs Django apps. * **Django’s `wsgi.py`**: Exposes the `application` object used by WSGI servers. ```python # wsgi.py import os from django.core.wsgi import get_wsgi_application os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'myproject.settings') application = get_wsgi_application() ``` --- ✅ **Why WSGI Matters** * **Portability**: Run your Django app on any WSGI-compliant server. * **Compatibility**: Works across multiple web servers and deployment tools. * **Concurrency**: Supports multiple threads or processes for scalability. --- 🎙️ **Interview-Friendly Casual Explanation (Diễn giải để nói trôi chảy):** **Think of WSGI as the translator between your Django app and the outside world.** * When a user makes a request, the web server (like Nginx) doesn’t talk to Django directly — it passes the request to a WSGI server like Gunicorn. * Gunicorn knows how to speak both HTTP and Python. It takes the request, hands it off to Django (through the `wsgi.py` entry point), and then sends Django’s response back to the user. * This standard interface makes your Django app portable — it can run on any server that understands WSGI. --- 🔑 **Câu nên nhớ (Highlight để học thuộc):** * “WSGI = bridge between web server and Django app” * “Gunicorn handles HTTP → Django via `wsgi.py`” * “WSGI makes Django apps portable, scalable, and server-friendly”

Answer 14

💡 **Answer:** In production, Django doesn't serve static files by default. Instead, you use dedicated tools or configurations to serve them efficiently and securely. --- 🧰 **Common Approaches** 1. **WhiteNoise** * Lightweight, works well with WSGI servers (like Gunicorn). * Handles compression, caching, and cache-busting. * Great for simple deployments (e.g., Heroku). 2. **ManifestStaticFilesStorage** * Renames files with content hashes (e.g., `style.abcd1234.css`). * Prevents browsers from using stale versions. * Good when you want long-term caching. 3. **Web Servers (NGINX or Apache)** * Serve static files directly — super fast and efficient. * Frees Django from that job. * Ideal for production or high-traffic setups. --- 📦 **Don’t forget to run:** ``` python manage.py collectstatic ``` * This command gathers all static files into one folder (`STATIC_ROOT`) for serving. --- 🎙️ **Interview-Friendly Casual Explanation (Diễn giải để nói trôi chảy):** **In production, Django steps aside when it comes to static files — it lets other tools handle that more efficiently.** * You can use **WhiteNoise** if you want a quick, straightforward solution that works well with Gunicorn — perfect for small projects or platforms like Heroku. * For better caching, Django offers **ManifestStaticFilesStorage**, which renames files with unique hashes so browsers always get the right version. * But the best performance comes from using a real web server like **NGINX** — it can serve static files way faster than Django ever could. And don’t forget — before deploying, you have to run `collectstatic` so Django knows where to gather and serve everything from. --- 🔑 **Câu nên nhớ (Highlight để học thuộc):** * “Django **doesn’t serve static files** in production — use WhiteNoise or NGINX” * “Run `collectstatic` to gather all static assets” * “Use **ManifestStaticFilesStorage** for cache-friendly filenames”

Answer 15

💡 **Answer:** Django caching improves performance by storing frequently accessed data, avoiding repeated computation or DB access. It works at multiple levels and supports different backends like Memcached, Redis, or filesystem. --- 🔧 **Core Components** * **Cache Backends**: Memory (`locmem`), DB, file system, Memcached, Redis. * **Cache Decorators**: Cache entire views or function outputs easily. * **Cache API**: Manually `cache.set()`, `cache.get()` data as needed in code. --- 🧱 **Caching Layers** 1. **Query Caching** – Cache ORM results to reduce DB hits. 2. **Template Fragment Caching** – Cache parts of a template (e.g., sidebar, navbar). 3. **View Caching** – Cache entire views using `@cache_page`. 4. **Low-Level API** – Direct access to the cache (`cache.set()`, `cache.get()`). 5. **HTTP Caching** – Use headers like `Cache-Control`, `ETag` for browser/proxy-level caching. --- 🎙️ **Interview-Friendly Casual Explanation (Diễn giải để nói trôi chảy):** **Caching in Django is like putting frequently used results into a “shortcut memory” so your app doesn't have to redo the same work.** * For example, if you have a view that fetches data from the database and formats a big page — you can use `@cache_page` so Django just stores the final result and skips recomputing it next time. * You can also cache just part of a template — like a sidebar or expensive query block — using **template fragment caching**. * And behind the scenes, Django can use **Redis**, **Memcached**, or even simple file-based caches to store that data. * If you need more control, Django gives you low-level APIs like `cache.get()` and `cache.set()` to manage data manually. --- 🔑 **Câu nên nhớ (Highlight để học thuộc):** * “Django cache = speed boost by avoiding redundant work” * “Use `@cache_page` for full views, fragment cache for templates” * “Backends like Redis/Memcached handle the storage” * “Don’t forget: you can also use headers for HTTP-level caching”

Answer 16

💡 **Answer:** Load balancing distributes incoming traffic across multiple Django servers to improve scalability, fault tolerance, and performance. --- ⚙️ **Benefits** * **Scalability**: Add more servers to handle increased traffic. * **Fault Tolerance**: If one server fails, others take over. * **Performance**: Requests are spread out, reducing latency. --- 🔁 **Common Algorithms** * **Round Robin** – Sends each request to the next server in a loop. * **Least Connections** – Picks the server with the fewest active connections. * **IP Hash** – Keeps requests from the same client going to the same server (sticky sessions). --- 🧱 **Typical Setup** 1. **Deploy multiple Django servers** behind a load balancer. 2. Use **NGINX** or **Apache** as a **reverse proxy**. 3. Use **HAProxy** or **NGINX** to distribute traffic. 4. Ensure all servers are on the **same network** and serve the same app. --- 🎙️ **Interview-Friendly Casual Explanation (Diễn giải để nói trôi chảy):** **Load balancing is like putting a traffic officer in front of your Django servers — making sure no one server gets overwhelmed.** * Imagine your app gets a ton of traffic. Instead of having one Django server handle everything (and possibly crash), you can spin up multiple servers. * Then you put a tool like **NGINX** or **HAProxy** in front, and it decides where each request goes — spreading them out evenly. * This setup boosts performance and keeps things running smoothly even if one server has issues. * Plus, depending on the algorithm (like Round Robin or Least Connections), the load balancer can decide how to distribute traffic smartly. --- 🔑 **Câu nên nhớ (Highlight để học thuộc):** * “Load balancing = distributing requests across multiple servers” * “Improves **scalability**, **fault tolerance**, and **performance**” * “NGINX or HAProxy = common tools used as load balancers” * “Algorithms: Round Robin, Least Connections, IP Hash (sticky sessions)”

Answer 17

💡 **Answer:** Database connection pooling is a technique that boosts performance by reusing existing database connections instead of creating a new one for every request. This reduces overhead and improves resource management. --- ⚙️ **How It Works** 1. **Reuses Connections** – Already-open connections are recycled instead of reopened. 2. **Handles Concurrency** – Each request gets a managed connection, even under high load. --- 🚀 **Benefits** * **Speed**: Faster than opening new connections each time. * **Efficiency**: Reduces load on web and database servers. * **Scalability**: Better suited for high-traffic environments. --- 🎙️ **Interview-Friendly Casual Explanation (Diễn giải để nói trôi chảy):** **Connection pooling is like keeping a pool of open database connections ready to go — instead of making a fresh one every time a user visits your site.** * Without pooling, Django opens and closes a database connection for every single request — that’s expensive and slow. * With pooling, once a connection is created, it goes back into the “pool” and can be reused by the next request. * This means faster response times and less pressure on both your Django app and the database. * It’s especially useful in high-traffic environments where performance matters. In Django, you can enable pooling by using external libraries like **`pgbouncer`** (PostgreSQL) or **connection pooling backends** such as `django-db-geventpool` or `SQLAlchemy` with custom setup. --- 🔑 **Câu nên nhớ (Highlight để học thuộc):** * “Connection pooling = reuse existing DB connections for performance” * “Faster, more efficient, and scalable under load” * “Tools like **pgbouncer** or **django-db-geventpool** can enable it”

Answer 18

💡 **Answer:** To optimize Django database queries, use smart query methods like `select_related()`, `prefetch_related()`, `defer()`, and `only()` to reduce unnecessary database hits and load only the needed data. --- 🔁 `select_related()` (for ForeignKey, One-to-One) * Joins related objects in the **same query** (SQL JOIN). ```python books = Book.objects.select_related('author') ``` --- 📥 `prefetch_related()` (for Many-to-Many, reverse FK) * Runs a **separate query**, joins in **Python memory**. ```python blog = Blog.objects.prefetch_related('tags').get(id=1) tags = blog.tags.all() ``` --- ✂️ `defer()` – exclude heavy fields (e.g., large text) ```python books = Book.objects.defer('description') ``` --- 🎯 `only()` – load only selected fields ```python books = Book.objects.only('title', 'author') ``` --- ✅ These techniques reduce query count, cut down I/O, and boost performance especially under load. --- 🎙️ **Interview-Friendly Casual Explanation (Diễn giải để nói trôi chảy):** **Optimizing database queries in Django is like asking only for the info you really need, instead of grabbing the whole database every time.** * Let’s say each book has an author, and you want to show the book list with authors’ names. If you don’t optimize, Django might do a separate query for each book’s author — that’s the N+1 problem. * Using `select_related()`, you tell Django: “Hey, grab the book and its author in one go.” * For reverse or many-to-many relationships, use `prefetch_related()`, which makes two queries but joins them smartly in Python. * If you have large fields you don’t need (like a long description), use `defer()` to skip them. Or use `only()` to load just the fields you care about. These techniques make your app faster and your server happier — especially when traffic grows. --- 🔑 **Câu nên nhớ (Highlight để học thuộc):** * “Avoid N+1 with `select_related()` and `prefetch_related()`” * “Use `defer()` to skip heavy fields, `only()` to pick specific ones” * “Optimized queries = fewer DB hits + better performance”

Answer 19

💡 **Answer:** A reverse proxy server sits in front of Django app servers to improve performance, security, and scalability. It handles tasks like: * **Load Balancing** – Distributes incoming traffic across servers. * **Caching** – Speeds up responses by serving cached data. * **SSL Termination** – Manages HTTPS, offloading encryption from Django. * **Security** – Hides backend details and filters harmful requests. Common tools: **Nginx**, **Apache**, **HAProxy**, **Varnish** ✅ Reverse proxies improve: * **Performance** (less latency) * **Scalability** (handles more users) * **Security** (hides internals, filters traffic) * **Flexibility** (acts as a control layer) --- 🎙️ **Interview-Friendly Casual Explanation (Diễn giải để nói trôi chảy):** **A reverse proxy is like a smart receptionist that handles all incoming traffic before it hits your Django app.** * It can decide which server handles which request — that’s **load balancing**. *For stuff that doesn’t change often, it can just hand out a cached copy without hitting Django again — faster and more efficient. * It also takes care of **SSL (HTTPS)** so Django doesn’t need to handle encryption. * And importantly, it **hides** your backend setup — attackers won’t know if you’re using Django, Flask, or anything else. Most people use **Nginx** or **Apache** for this, and they sit in front of your Gunicorn or uWSGI Django server. --- 🔑 **Câu nên nhớ (Highlight để học thuộc):** * “Reverse proxy = smart middleman between users and Django app” * “Handles SSL, load balancing, caching, and security” * “Nginx is the most common reverse proxy in Django setups”

Django Flashcards

(43 cards)