Looks great -- always wished the admin panel came with more configurable bells and whistles. I've been exploring Quarkus recently (https://quarkus.io/), and it has a Dev UI with a similar extensible "panels" pattern. It's a bit different than Django since it's not for running in prod, but nonetheless it's pretty helpful.
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.
blorenz 7 minutes ago [-]
I love the sentiment and ambition in this! The Django admin is a core reason why I still choose Django over other solutions. I tell my team that the Django admin CRUD is our backstop when we encounter issues in our frontend UI. Thank you for tooling it out more!
giancarlostoro 22 minutes ago [-]
Django Admin definitely needs extensions like this. I hope someday they make it a stronger more capable Admin UI. Their own docs if I remember correctly tell you to build your own UI if you're hitting limits with the admin UI itself, which is fine, but there's so much OOTB that works nicely for the admin UI.
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 that explains some of the value for this project a bit better
malux85 4 hours ago [-]
Great project, Django admin totally needs some love! You rock!
yassi_dev 4 hours ago [-]
Thank you. I wholeheartedly agree; The Django admin a great surface to stand up tooling
ramon156 3 hours ago [-]
A vibe-coded website built on a vibe-coded README, can't get any better than this
parham 3 hours ago [-]
It’s the initial starting point, calm down.
I like the idea it can help for initial inspection and smell detection
yassi_dev 3 hours ago [-]
Fair.
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.
seyz 3 hours ago [-]
toxic.
Eldt 2 hours ago [-]
Not all negativity is toxic. My sense of hunger is unpleasant but it keeps me healthy.
cruffle_duffle 2 hours ago [-]
I mean docs are largely written for an LLM-in-a-harness. That’s how it goes! If the LLM bootstraps with the right understanding of the universe and knows how to quickly build specific context flavors… life is good.
simonw 1 hours ago [-]
I like the way each panel is its own separate package on PyPI and the system picks them up via setuptools entry points. It's a neat implementation of a plugin pattern.
yassi_dev 56 minutes ago [-]
Thanks. Part of the reason this exists is simply wanting to toy around with the entrypoints system
jnpnj 32 minutes ago [-]
Lovely. I wonder how many people did similar things in their own django instances because the lack of embedded monitor is often a source of friction.
drchaim 2 hours ago [-]
Good idea. If you add a kind of skill/prompt you’ll get a lot of other components from the community ;)
butterlettuce 51 minutes ago [-]
Tell your parents i said thank you for making you exist.
dec0dedab0de 4 hours ago [-]
i like it, but I think i would rather have a proxy, or atleast an auth redirect to those different tools.
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.
yassi_dev 3 hours ago [-]
Totally understand - I am a long time flower user for example, and I am familiar with having to harden that installation a bit.
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.
dec0dedab0de 7 minutes ago [-]
That definitely makes sense. But as it stands it's more of a multi-tool than a toolbox. I'm definitely going to check it out though.
izzie1234 2 hours ago [-]
I love this idea. I see the AI era having 2 competing views when building something new:
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
yassi_dev 2 hours ago [-]
Thats an interesting way to frame it.
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.
dzonga 2 hours ago [-]
this is pretty dope
yassi_dev 2 hours ago [-]
Thanks. I hope you find it useful
raphaelmolly8 2 hours ago [-]
[dead]
raphaelmolly8 2 hours ago [-]
[dead]
genie3io 4 hours ago [-]
[dead]
FEELmyAGI 2 hours ago [-]
[flagged]
yassi_dev 2 hours ago [-]
I get your point
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.
FEELmyAGI 29 minutes ago [-]
>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.
jefurii 2 hours ago [-]
Go do something ueful.
FEELmyAGI 1 hours ago [-]
> Go do something [r]ueful.
Does browsing this website not qualify?
cruffle_duffle 2 hours ago [-]
I mean for one thing your garden variety LLM had been substantially trained to handle Django. That is less context for it to bootstrap every time you summon it.
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…
FEELmyAGI 2 hours ago [-]
There is much more engineering and testing (and probably AI training) in python and a web browser than there is in django. same with EG bash and linux vs ansible. that is what I mean by 2010s era frameworks - JSON/YAML easy wrappers with opinionated defaults and consistent interfaces.
AI has no problem going from programming language -> runtime without human-convenient middleware. So I am NOT implying to create your own django on the way to creating your CRUD app. I think you can make a CRUD app based by listing all the features you want. Including, if you really want an in-band administration feature like phpmyadmin or django admin, you could have AI generate something that pipes any system command to the web app.
cuu508 1 hours ago [-]
Python is inherently slow, why not go straight to C?
FEELmyAGI 42 minutes ago [-]
Suit yourself really. maybe there's more training data for CRUD apps in python than C, but I don't think it's too hard to implement the fundamentals of a web app in any language if you're also using a web server.
Most webapps aren't that popular therefore don't use that much computation anyways, so theres a point of diminishing returns on making your CRUD as efficient as scientifically possible. some prefer a managed runtime so that a bug causes EG python to crash instead of the consequences of a bug in native code, but that can be mitigated easily enough as well.
Rendered at 19:04:07 GMT+0000 (Coordinated Universal Time) with Vercel.
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 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.
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…