Show HN: Django Control Room – All Your Tools Inside the Django Admin
Over the past year I’ve been building a set of operational panels for Django:- Redis inspection - cache visibility - Celery task introspection - URL discovery and testingAll of these tools have been built inside the Django admin.Instead of jumping between tools like Flower, redis-cli, Swagger, or external services, I wanted something that sits where I’m already working.I’ve grouped these under a single umbrella: Django Control Room.The idea is pretty simple: the Django admin already gives you authentication, permissions, and a familiar interface. It can also act as an operational layer for your app.Each panel is just a small Django app with a simple interface, so it’s easy to build your own and plug it in.I’m working on more panels (signals, errors, etc.) and also thinking about how far this pattern can go.Curious how others think about this. Does it make sense to consolidate this kind of tooling inside the admin, or do you prefer keeping it separate?
92 points by yassi_dev - 45 comments
I think that explains some of the value for this project a bit better
I like the idea it can help for initial inspection and smell detection
README and site were definitely optimized for speed over perfection. The panels themselves got a bit more attention.
Curious what you’d want to see improved on the docs/site side.
sort of a tangent, but quarkus also has a concept of "dev services" that are monitorable via the dev UI. It uses Testcontainers to start and autowire runtime deps (postgres, redis, keycloak, etc.). Pretty pleasant experience to get the whole stack spun up and observable alongside the dev server.
I like the spirit of this, and could see Django heavy shops wanting to add bits and pieces that display tooling / services they care about in Django admin.
I think its good advice to avoid the admin for customer facing use cases. But for internal facing tools It seems pretty wasteful to not use the built in admin - it has all the bells as whistles to build upon (auth, permissions, etc.)
I used to have flower at myapp.com/flower using an auth redirect in nginx to a simple view in django that made sure it was an admin user. I think if you can make that setup easier to leverage existing tools that would be nicer than rebuilding everything.
What I'm aiming for here is slightly different - keeping everything inside Django so there are no extra services to run or configure or proxy. As long as you surface the admin somewhere, then that is the place to find your tooling (including celery monitoring)
There will always be room for both approaches. A lightweight proxy/redirect could be something to explore in the future.
1. Build X with pure <language of choice>. Why? LLMs will have less context needed, and onboarding engineers would be easier since there’ll be less overhead and opinionated frameworks knowledge required
2. Build X using well establish frameworks. Painful in the beginning since you’ll not only need language knowledge, but framework knowledge. The upshot, is scaling and maintainability
I love that this ecosystem will heavily pressure teams to consider (2) more and more — solving the very real “AI slop” problem
In my view. Building things with AI creates the need for common patterns and guardrails (i.e. frameworks) Then as these new apps become productionalized - tooling that fits your framework starts to become more important.
In that sense, AI increases the need for good patterns around observability. This project aims to make this a little easier to do for Django right from inside the framework as opposed to an external service.
I think even if AI handles more of the CRUD side, you still need to understand what’s happening in the system once it’s running - this is where this project fits in.
To your point about framework use because of AI: As more applications are being built because of lowering barriers, I think it makes sense for full stack monolithic frameworks to be used more frequently.
Why? I believe full stack frameworks solved a problem for human coders, not AI coders. In fact they are only a limitation for AI going between programming language and runtime.
Does browsing this website not qualify?
Just like rolling your shitty homebrew framework is a bad idea because only you understand it, the same is probably true with LLMs. Sure they’ll scan the bejesus out of your codebase every time they need to make a change and probably figure it out eventually… but that is just a poor use of limited context. With something mainstream, the LLM already has a lot about the universe in its training. Not to mention an ecosystem of plugins, skills, mcp servers, wizbango-hashers, and claberdashers. All there for the LLM to use instead of wasting tons of time, tokens and money perpetually relearning your oddball, one-off, rat infested homebrew framework.
Nothing has changed really…
But LLM will figure it out so why not take free speed?
BTW, also if we're getting rid of a web framework and letting the LLM write specialized code for the various CRUD operations, why not also get rid of Postgres/MySQL/Redis and let LLM also write specialized code for reading, writing, and querying the various business objects?