Home > Overview > Django Admin vs. wq

Django Admin vs. wq

The wq framework is built on Django, and wq.db’s model registration API is designed to be as easy to use as the Django admin. Given the large overlap in features, it usually makes sense to use wq’s built-in UI rather than enable the Django admin. However, the admin may be more appropriate in certain cases.

Feature Comparison

API

  Django Admin wq Framework
Autodiscover Filename myapp/admin.py myapp/rest.py
Import Path from django.contrib import admin from wq.db import rest
Registration syntax admin.site.register(MyModel) rest.router.register_model(MyModel)
Default form class ModelForm ModelSerializer
Permissions django.contrib.auth django.contrib.auth
UI customization Widgets and HTML templates Input components
Custom actions Django admin actions DRF @action and custom client logic

UI

  | Django Admin | wq Framework –|–|– Default Views | Login, Index, Model List/Edit | Login, Index, Model List/Detail/Edit, Outbox Connectivity | Online only | Online + Offline Ordering & Filtering | Built-in configuration | Some customization required Theme | Django-specific | Material UI

Summary

In most wq-based projects, wq is used for the primary public facing UI, while also supporting admin capabilities. Thus, we recommend using wq (and minimizing use of the the Django admin) for the most streamlined user experience. By surfacing most/all tables (including “domain values” tables) in the generated wq UI, you can allow admin users to quickly make and test changes without needing a full reload. wq enforces permissions automatically, but you may still want to create a custom <Admin/> view component to centralize common admin tasks.

That said, the Django admin should still be used for any tables that do not appear in the public UI at all, such as the Django auth permissions tables. While the admin UX will be different for those tables, they are generally only modified during software deployment and maintenance anyway.