IMO you'd be best off creating a basic RBAC system with users assigned to roles and roles granting permissions. It's not really all that complicated, especially if you do it from the start.
The only time I’ve ever seen a system like that come in handy is when there have been a bunch of complicated permissions that don’t fit neatly into discrete levels and are assigned by users. For everything else, a boolean in the database or an ad hoc system has been perfectly fine. Don’t build things before you need them!
As a DBA with my time constantly split between development and operations, my life (and my team’s) was made so much easier when we started focusing on making our admin tools more usable and thorough. But I’ve often felt that our lack of maturity in this realm is due to our small team size.
Can someone from a larger dev team speak to whether you still find yourself spending time building/improving admin tools like this?
Oooof. Guess I should count my blessings that the lack of bureaucracy in a smaller team means that I can spend time on admin tools when I see fit. Grass isn’t always greener
Not sure how big your team is but IME the larger team only increases the need for admin tools and makes lots of ad hoc bash/SQL console sessions more dangerous.
Even at a small size (a dozen or even fewer devs) I recommend doing what it takes for anything besides true one-offs to go through admin tools.
In general, I find that office staff want to be able to solve their own problems and will appreciate you giving them the tools to do it.
Seriously. For some internal process tools, Django admin with custom models registered gets me 90% of what I need. The remaining 10% usually gets covered in a custom command that I can run from the shell
Django allowed me to fill the back end dev role with 10% of my time for a project that has been wildly successful at my employer (now worth multiples of billions) for five years. We’re only now getting to where the Django admin tools aren’t quite enough.
For small applications I avoid writing admin tools because I don't want to waste too much time. However though, an alternative to actually writing admin tools from day one is using django and then seeing if you need admin tools or not.
Can’t say I agree. You should only build tools if the time saved on the task is greater than the time it takes to build the tool. And in a lot of cases, you don’t actually know in advance what the common and time consuming admin tasks will be. The absolute worst thing is to spend valuable time building an admin tool you don’t end up using. So wait until you see an actual need, and then build your tools.
Admin tools, particularly federating admin actions in a distributed team - will never not happen. Their shape may change, but devoting time to building the first version will give you the harness you need.
Source: I am writing three services at this point that are mostly Middleware to deal with the lack of native federation for certain services we use.
I'm not so sure. Multiply the number of "obligatory XKCD" comments made on Hacker News by the average number of minutes wasted by unfortunate souls reading them, and I think you could probably save an FTE or two.
One thing not in the xkcd is "how much time it takes you to make the script".
Let's say there is some weird service that you sometimes need to manually restart in a very specific order for maintenance. The hard (time intensive) task is figuring out the right incantations and the order to do it. It is however not time intesive at all to store those incantations in a shell script.
So not saving that in a script risks you (or a co-worker) having to go through this again, potentially missing some important aspect and wasting time and energy.
Sure in a sense, but my feeling is that this is often taken too literally.
Sometimes the work is "making the script beautiful and universal" and then you should indeed consult that xkcd.
Sometimes the work is spitting the commands you had to figure out anyways into a shell script in 5 seconds. Then it is a no brainer to do it, because it will safe you time even if you use it only once.
I like this XKCD and I think about it a lot, in a “is it really worth my time to do this?” kind of way.
One thing the time-based framework doesn’t account for is the mental energy you could save.
A small example: I sell a software product, and every now and then someone would ask for an invoice. So I’d have to look up the order, copy an ID and an email, make a PDF, and email it over. Was it hard? No, it took 2 minutes. But I loathed doing it.
So I wrote a little invoice page that looks up their order and let’s them put in whatever info they need, and generates a PDF. It took a day or two. I’m 99% sure this will never ever pay off in terms of time savings, but it gives me great joy to know that I will never have to do that energy-sapping task again.
_Nothing_ takes 2 minutes, though! The context switching from whatever other thing you actually wanted to be focused on probably costs you at least 15-20 minutes. If it took you 16 hours of dev work to automate the process, it's only going to take you something like 50 invoices to recover your lost time when you account it that way. Seems like a great tradeoff to me. And reducing your own misery, is, of course, invaluable!
Admin tools are not just time saved. They are also in itself documentation. If you just echo the one-liner you hammer into the terminal occasionaly into a shell script it could already provide worth just by being a file others (or the admin themselves) can see in the future. And this costs you nothing.
Bonus points if it is something complicated that needs to be repeated occasionally.
If it is something that needs half an hour reasearch and careful treading before getting the desired result and it costs you basically zero to save it in a script, just do it.
For me it breaks when people try to make scripts/tools that are doing too much. Because at some point these break for variety of reasons.
Then wrapping my head around monster script is additional work I need to do on top of understanding system that is changed.
I argue that it might be quicker to understand system on its own and make changes manually than rely on someone else script.
In the end if script works it works time money saved - when it breaks it is more work and now there are 2 things one has to figure out.
That is why I'd rather have smaller scripts that do parts of bigger job instead of someone dropping "just run this and it will do everything for you" type of scripts.
No, your in house scripts are not documentation, because they provide little context or rationale. In many cases they make the system more opaque by masking fundamental admin actions inside poorly commented wrappers.
There is no substitute for well written documentation
at absolute minimum i would say when you have to do an admin task twice through messing with the database or something is when you should probably add an interface for it, guessing what tasks the user (or reality) will screw up is hit and miss at best.
some of these tasks when caused by human error the better idea is to make it more difficult to break the system than just easier to fix it and allowing the user or admin to fix it on their own hides the issues away
At my first job I wanted to automate the way a customer bought a product and got the license key. But the project manager said not to waste time on this, he was going to do all of that by hand. So my obvious response was "What are you going to do when we have a crazy amount of sales and you have to handle all of them by hand?". His response was "I would love to be overloaded with that work! That means we are selling and have money to develop an automated system".
I learned a valuable lesson that day: Build it when you really need it. It's highly likely that you will never need it.
It isn't always clear what that timesaving would be, though. We have to factor in the marginal utility and alternative cost with every- and anything the resources in question thinks about doing (or does.)
Not writing the admin tool might save time in the short term. But as I'm serving you with reports from the database and changes directly in it, I'm not doing other productive work. So you get the reports sooner and the time it takes to give you one is pretty quick.
But that task could have been done by you if you knew SQL. Or a junior programmer. Or by the admin tool.
And I could have spent that time developing customer features (or the admin tool.)
That’s why I’m saying you should wait until you have an idea of how much time a task takes before automating it.
If manually providing reports uses up a lot of your time, you can always build the admin tool. But if you build a tool that no one ends up needing, or if building it takes more time than you save, you can’t exactly un-build it and get your time back.
It's important to keep in mind that automating tasks also improves quality. So even if it looks like time is wasted, preventing just a single mistake administering a customer's account can be worth a huge amount of earlier investment.
Also the time spent building the first tool probably includes a quantity of "overhead" (auth, logging, etc.) which gets quickly amortised on subsequent tools.
I agree if you are only considering whether to automate your own tasks. The value of "admin tools" goes way up when they enable someone else to self-service on tasks that would otherwise require intervention from you or your team. Often in those cases, the value vastly exceeds what you might get out of it yourself in terms of speeding up work that you did manually.
(author). I agree with your sentiment , and try to make this point in the article. This is why I suggest using out of the box admin frameworks and other ways to provide quick admin features. Only spend time adding custom functionality once a need arises. With this approach you already have the frameworks setup, tested, and you have been writing your code with support in mind.
Thanks for writing the article! It definitely helped me crystallize some of my thoughts around this.
I think the point at which we differ is that I actually prefer the "Oh #&@$ Solution". Part of it is to avoid building tools that I never end up using. But even if I do use a tool a lot, I would still rather slow development later rather than sooner.
For example, I'm the only engineer, building an admin tool means product development stops, whereas if I wait until we've hired another engineer it means it only slows down by 50%. Or, if we only have a few months of runway, it's much more valuable for me to work on things that increase revenue or decrease costs in terms of actual dollars than things that make the company more efficient.
Obviously these are contrived examples, but the general theme here is that time now is more valuable than time later. So the further into the future something is expected to pay off, the more suspicious of it you should be.
I loved building tools and did it to get better/ faster at writing scripts and/or for fun eg trying to solve puzzles.
I would try and write tools/ scripts for anything
This helped me to get faster at writing tools - to the point where I automated a large porportion of my job - allowing me to spend more time on working on the stuff I liked - leading to me moving away from Admin
I built a Django extension for that! Lets me poke around with a read-only user and then bookmark the results to share with others: https://django-sql-dashboard.datasette.io
This take is correct IMO - it's only worth building a tool if it saves you more time than it takes to develop. This is why Retool exists - if building/changing an admin tool takes about as much time as assembling a Keynote presentation, then the economics of using custom software to solve small problems start to work out in your favor.
my own name for this rule of thumb. based on the story about the MIT campus where they put in grass but no sidewalks, and then waited to see what kind of natural trails formed from natural walking and biking. then put sidewalks there
Agreed - I picked Django for a side project years ago (I picked it more on a whim than anything else) and the built-in admin probably turned out to be the biggest time-saver.
That can’t possibly be right, at least wait until you have product market fit.
Also there’s going to be something analogous to PMF for the tools themselves. Beyond CRUD, which is already trivial with most backends, you won’t really know what advanced admin tool features are needed until you’re servicing support requests.
On early stage products it’s very possible you’ll switch backends at some point. Most recently I had a POC using Redis (for reasons) and if I’d written any admin tools instead of just using the CLI, it would have been 100% thrown away when I migrated to Cloudflare Workers.
I think the author takes seriously the constant whining noise in the dev team "who did that shit, why dont we have that, why is this still manual, what idiot made this architecture".
In fact, the very existence of this whining is possible because competitors got beaten, clients got their edge cases hacked in, low cost employees rushed the MVC etc... It's part of life and I now learned to enjoy it and complain too, while mad rushing stuff to avoid losing a big client...
I wish money was no object, competitors helped instead of fucking us, client had patience, taxes were low, engineers were cheap. But it isnt so yet.
This is what gives a Django developer super powders. There are comments here suggesting that you should wait for the time needed to develop your admin tools to be less than the time it takes to perform the action manually. With Django that's literally 5 min! To add a "basic" first pass of an admin to a model is literally a 5 min job. And when I say "basic" it's not really that basic, you can achieve a lot very quickly with the admin framework.
If you are using Django and not building out admin tools as you go you are doing it wrong.
The other thing touched on in this post is audit trails. I now tend to create a "{model}Log" model for the "key" models in an application, fairly basic with a JSON column. So for a shop, the products, basket, orders, etc. Then aggressively log to it all and any actions that happen, both internal stuff and external API calls (requests and responses). I make this log visible in the admin on the page for each of the key models. It makes digging into what is happening so much easer for everyone.
If you eventually find you are logging too much, just turn it down.
I do however very much see there bing two layers to admin tools, the first being the visibility, CRUD, audit tools. The second layer of tools for specific actions (e.g. compiling with GDPR removal requests) can make sense to wait until you have experienced doing it manually a few times to understand the problem better. But even then, it's better to build as soon as you have that knowledge.
As much as I hate Ruby, Rails has a similar thing, and ActiveAdmin is just plain wonderful. Django AdminTools and Rails ones are must haves for me anymore.
Django AdminTools has been' updated since 2021. Is there an alternative that you use?
+1 on ActiveAdmin. We recently switched from Rails to Django and AA is something I'm severely missing. The DSL is terrribbblee but once you learn it, omg so fast to do anything.
I really looked into appsmith because of how cool the look, but one key problem I have is we're fintech so auditing objects is critical.
Appsmith has its own logging system and our Django app will also have one through django-simple-history. Reconciling the two will be super annoying. Rollbacks for user edited objects will be effectively impossible w/o a separate system.
You could handle that with an audit log (there's some standard ways to do this in SQL databases). And then expose that in the admin interface via the low code tools (which have SQL-to-UI builders).
Here's an example of an audit log I put together for an in app activity feed (in Postgres):
Thanks i appreciate the help. We'll take a look at it. Realistically it's probably too much lift to do all this directly. Key benefits of django-simple-history are single line add to other tables/models as well as reifying historical items.
The thing that's killing me w/ Django's Admin system is there's no concept of pure Viewing data.
A big part of administering your end users is having staff be able to "see" what is going on w/ the user (i.e. a dashboard for user and all user related objects, like what company they belong to, money, products, purchases etc). But it's weird that the viewing page is also the editing page.
Thanks, but the goal isn't to prevent editing. It's to prevent accidental editing. Staff need to be able to change things but 95% of the time they're simply viewing data to help answer questions, etc.
It's possible to register more than one ModelAdmin for a given model - so you could have a read only one which staff spend most of their time in, but that then links to the writable one when they need to make changes.
You could even register multiple admin sites: /admin/ showing read-only data and /admin-write/ that allows it to be edited.
Django admin is great too in the rare case when you inherit a database only from an old project. You can point Django to the database and it can create an admin model for you, and from that you can start using django normally with migrations, admin panel, etc.
Most of the replies here seems to be restating principles behind "Do things that don't scale." I was of the similar mindset. But slowly, I realized the reality is more nuanced and the essay needs to be taken with a grain of salt. I hate repetitive, manual tasks. It's more likely I will forgot to do them, or I will make an error in doing them, or I will put them off. At the same time, I am pretty comfortable with programming, I love hacking together different tools and APIs to build useful things.
I have found creating mini tools a better use of my time, then just follow a shitty workflow because I need to keep doing things until I have reached a certain threshold. YMMV, of course.
All wrong. Admin tools are not fixing the root cause. Instead they are only making the operations more efficient.
The way to scale is to focus on eliminating the need of manual operations/admin tools by giving the power to the users of your products. Focus on self-service. Sure, not everyone should be able to overwrite an arbitrary value or change an important setting but that is easily solved with granular access rights.
In my team, we never want to create a feature that only devs or support team can use. These exclusive features create the need for us to operate them instead of staying focused on engineering.
Pre-PMF you probably don't need much, just don't make it harder for yourself to add things later.
For us we usually just add a new feature to the admin dashboard whenever it's needed for the first time, usually triggered by a customer support question. The downside is that unusual queries can take a few days to answer, but the upside is that we've never built anything we didn't need.
On the tools: I have gone the route of using the libraries (e.g Kaffy for Phoenix, ActiveAdmin for Rails) and later building a central shared backoffice from scratch that any team can contribute to. In the former you are always wasting time fighting the library to get what you want, in the latter it has the advantage of being language/framework agnostic but it's too costly for smaller teams.
More recently i've used tools such as Retool (there are many alternatives), it has been ideal and allows for non engineers to build there own tools with a little bit of SQL knowledge.
I agree, but only after you have a product that works. Else, you will see yourself drawn into maintaining the admin features, and not the real product. There can be a middle ground: design your API with ACL from the start, and then the CRUD admin features would just work out of the box. Or there's a cool shortcut: Hasura and Appsmith. Hasura connects to my PostgreSQL data and provides authorization, while Appsmith just consumes the REST endpoints created with Hasura.
An alternative may be to use a low code platform like Budibase (I am the cofounder) which is designed to help IT teams build admin panels faster. It ships with its own DB (Couch) which should speed up the process!
You are right, but I never said Mastodon was without authority, it's decentralized and authorative at the same time.
To be able to remove the admin in Mastodon we would need to change laws since nobody would host a server that they cannot delete illegal content from.
Thinking about these things opens doors to understanding the absurdity of our current society.
In the end: to think that you can control anything is an illusion of energy abundance, and since we are running out of coal, oil and gas; my intuition tells me authority is going to dwindle slowly, then fast and finally all at once.
Thus, my conclusion is: don't build admin interfaces. :D
Adding to this the source-available economy that is the last step in our modern stack, needs user generated/hosted/owned content. So I think moderation tools needs to be less energy intense than manual.
My only solution so far is pride/shame, like hn; so you attach a pseudonym to things: after all that is how communities have worked since we started naming people.
For me, building admin tools from day one is more about culture and setting expectations than predicting future workload.
If you have the whole team aware of the basic ground rules for what the admin tools are and what they need to be like moving forward, you can build an ongoing process. i.e. don't merge a feature unless that feature's developer also included a way for the business to configure it to their expectations.
Done correctly, the admin tools should effectively write themselves. It's definitely a lot faster to do this while you are deep in whatever feature.
I'm a big fan of admin tools, they can be very useful in getting data into a database without SQL (in the beginning), providing product people with a handy interface to explore data (if they don't use tableplus[3]), allowing customer support to field customer inquires, potentially allowing QA teams to diagnose issues.
They can indeed be a pain to build if one puts in the same codebase as the product codebase, best to separate their code out into a separate codebase. Business logic is often not applied to admin tools hence better own codebase.
Recently I built a backend using Node-Red[0], being a card-carrying Emacs user, I was surprised how simple it was to design flows to represent an API for my application. But the really great advantage was the admin tool. I just used Node-Reds dashboard[1] to create a simple frontend to interface with my database. It allowed me to play around with my database schema until it felt usable. After that I designed the API.
Just one more plug: pgModeler[2] is terrific for visualling modelling a postgres database. Incredibly useful and much preferred (for me anyway) over codified migrations. Combined with Node-Red, I could focus on getting the business logic done and not fiddle around with database migrations, data format conversions or debugging code.
Problem with such tools is that, if done beforehand, they start nice and clean and then as Support requests more features, it starts to get out of hand. Then someone passes the tool to an external team and suddenly you have dependencies that you are not aware of.
The best approach is to re-use the existing setup e.g. hook into existing observability ecosystem instead of building your own from scratch. If support needs to execute something frequently, question if that can be done via any existing orchestrator like Tidal or Autosys etc. If that is insufficient, maybe a dashboard is more manageable since it is server-side. If you see that you are building such dashboards for each of the services, they maybe there is need for a general Support dashboard (even that is not a panacea because that too starts nice and clean and then as Support requests more features, it starts to get out of hand and becomes a dumping ground for random requests). Push back on what is not essential, drive towards fixing the root cause of something that is symptomatic of a deeper issue; on the other hand, if it is a genuine need, add the feature - as with most things, balance is the key.
This is where Event Driven Architecture can make a huge difference. Having some topics you can subscribe and publish to means you can add new features and entire apps.
We're working on Interval to make doing exactly this easier. We focus on code first, well-typedness, and abstract away UIs for these tools so you can write the business logic using your own existing functions and tools and then get back to working on your actual app.
I'm really impressed so far, it can either act as the only backend, or as an admin tool over an existing DB. It also has built-in support for "flows" to automate support tasks.
105 comments
[ 3.0 ms ] story [ 166 ms ] threadSo to define a admin you just add a GROUP_NAME node called "ADMIN" to a user, pretty simple but not very fun when you need to find all admins.
It's the first and last admin interface I will ever do, since then I just hot deploy my hardcoded changes or edit the raw data instead.
Can someone from a larger dev team speak to whether you still find yourself spending time building/improving admin tools like this?
Even at a small size (a dozen or even fewer devs) I recommend doing what it takes for anything besides true one-offs to go through admin tools.
In general, I find that office staff want to be able to solve their own problems and will appreciate you giving them the tools to do it.
Source: I am writing three services at this point that are mostly Middleware to deal with the lack of native federation for certain services we use.
https://xkcd.com/1205/
Let's say there is some weird service that you sometimes need to manually restart in a very specific order for maintenance. The hard (time intensive) task is figuring out the right incantations and the order to do it. It is however not time intesive at all to store those incantations in a shell script.
So not saving that in a script risks you (or a co-worker) having to go through this again, potentially missing some important aspect and wasting time and energy.
Sometimes the work is "making the script beautiful and universal" and then you should indeed consult that xkcd.
Sometimes the work is spitting the commands you had to figure out anyways into a shell script in 5 seconds. Then it is a no brainer to do it, because it will safe you time even if you use it only once.
One thing the time-based framework doesn’t account for is the mental energy you could save.
A small example: I sell a software product, and every now and then someone would ask for an invoice. So I’d have to look up the order, copy an ID and an email, make a PDF, and email it over. Was it hard? No, it took 2 minutes. But I loathed doing it.
So I wrote a little invoice page that looks up their order and let’s them put in whatever info they need, and generates a PDF. It took a day or two. I’m 99% sure this will never ever pay off in terms of time savings, but it gives me great joy to know that I will never have to do that energy-sapping task again.
Bonus points if it is something complicated that needs to be repeated occasionally.
If it is something that needs half an hour reasearch and careful treading before getting the desired result and it costs you basically zero to save it in a script, just do it.
Then wrapping my head around monster script is additional work I need to do on top of understanding system that is changed.
I argue that it might be quicker to understand system on its own and make changes manually than rely on someone else script.
In the end if script works it works time money saved - when it breaks it is more work and now there are 2 things one has to figure out.
That is why I'd rather have smaller scripts that do parts of bigger job instead of someone dropping "just run this and it will do everything for you" type of scripts.
No, your in house scripts are not documentation, because they provide little context or rationale. In many cases they make the system more opaque by masking fundamental admin actions inside poorly commented wrappers.
There is no substitute for well written documentation
some of these tasks when caused by human error the better idea is to make it more difficult to break the system than just easier to fix it and allowing the user or admin to fix it on their own hides the issues away
I learned a valuable lesson that day: Build it when you really need it. It's highly likely that you will never need it.
Not writing the admin tool might save time in the short term. But as I'm serving you with reports from the database and changes directly in it, I'm not doing other productive work. So you get the reports sooner and the time it takes to give you one is pretty quick.
But that task could have been done by you if you knew SQL. Or a junior programmer. Or by the admin tool.
And I could have spent that time developing customer features (or the admin tool.)
If manually providing reports uses up a lot of your time, you can always build the admin tool. But if you build a tool that no one ends up needing, or if building it takes more time than you save, you can’t exactly un-build it and get your time back.
Also the time spent building the first tool probably includes a quantity of "overhead" (auth, logging, etc.) which gets quickly amortised on subsequent tools.
I think the point at which we differ is that I actually prefer the "Oh #&@$ Solution". Part of it is to avoid building tools that I never end up using. But even if I do use a tool a lot, I would still rather slow development later rather than sooner.
For example, I'm the only engineer, building an admin tool means product development stops, whereas if I wait until we've hired another engineer it means it only slows down by 50%. Or, if we only have a few months of runway, it's much more valuable for me to work on things that increase revenue or decrease costs in terms of actual dollars than things that make the company more efficient.
Obviously these are contrived examples, but the general theme here is that time now is more valuable than time later. So the further into the future something is expected to pay off, the more suspicious of it you should be.
I loved building tools and did it to get better/ faster at writing scripts and/or for fun eg trying to solve puzzles.
I would try and write tools/ scripts for anything
This helped me to get faster at writing tools - to the point where I automated a large porportion of my job - allowing me to spend more time on working on the stuff I liked - leading to me moving away from Admin
Building an authenticated admin UI for something is a lot of work.
Adding a "see most recent orders" page to an existing admin UI can take just a few minutes, once that framework is in place.
That said — if I’m just looking at data, it usually takes me a pretty long time to outgrow poking around the database with a read-only user.
This take is correct IMO - it's only worth building a tool if it saves you more time than it takes to develop. This is why Retool exists - if building/changing an admin tool takes about as much time as assembling a Keynote presentation, then the economics of using custom software to solve small problems start to work out in your favor.
my own name for this rule of thumb. based on the story about the MIT campus where they put in grass but no sidewalks, and then waited to see what kind of natural trails formed from natural walking and biking. then put sidewalks there
Also there’s going to be something analogous to PMF for the tools themselves. Beyond CRUD, which is already trivial with most backends, you won’t really know what advanced admin tool features are needed until you’re servicing support requests.
On early stage products it’s very possible you’ll switch backends at some point. Most recently I had a POC using Redis (for reasons) and if I’d written any admin tools instead of just using the CLI, it would have been 100% thrown away when I migrated to Cloudflare Workers.
In fact, the very existence of this whining is possible because competitors got beaten, clients got their edge cases hacked in, low cost employees rushed the MVC etc... It's part of life and I now learned to enjoy it and complain too, while mad rushing stuff to avoid losing a big client...
I wish money was no object, competitors helped instead of fucking us, client had patience, taxes were low, engineers were cheap. But it isnt so yet.
If you are using Django and not building out admin tools as you go you are doing it wrong.
The other thing touched on in this post is audit trails. I now tend to create a "{model}Log" model for the "key" models in an application, fairly basic with a JSON column. So for a shop, the products, basket, orders, etc. Then aggressively log to it all and any actions that happen, both internal stuff and external API calls (requests and responses). I make this log visible in the admin on the page for each of the key models. It makes digging into what is happening so much easer for everyone.
If you eventually find you are logging too much, just turn it down.
I do however very much see there bing two layers to admin tools, the first being the visibility, CRUD, audit tools. The second layer of tools for specific actions (e.g. compiling with GDPR removal requests) can make sense to wait until you have experienced doing it manually a few times to understand the problem better. But even then, it's better to build as soon as you have that knowledge.
+1 on ActiveAdmin. We recently switched from Rails to Django and AA is something I'm severely missing. The DSL is terrribbblee but once you learn it, omg so fast to do anything.
edit: the default provided admin tools. I didn't know if it was called AdminTools or whatever.
Appsmith has its own logging system and our Django app will also have one through django-simple-history. Reconciling the two will be super annoying. Rollbacks for user edited objects will be effectively impossible w/o a separate system.
Here's an example of an audit log I put together for an in app activity feed (in Postgres):
https://gist.github.com/cpursley/a2ae79423bee9274e3639839967...
A big part of administering your end users is having staff be able to "see" what is going on w/ the user (i.e. a dashboard for user and all user related objects, like what company they belong to, money, products, purchases etc). But it's weird that the viewing page is also the editing page.
The trick is to implement these methods on your ModelAdmin subclass: https://docs.djangoproject.com/en/4.1/ref/contrib/admin/#dja...
You can make has_add_permission(), has_change_permission() and has_delete_permission() all return False, while has_view_permission() returns True.
The readonly_fields and related get_readonly_fields() method are very useful too.
I wrote up another related trick in this TIL: https://til.simonwillison.net/django/extra-read-only-admin-i...
It's possible to register more than one ModelAdmin for a given model - so you could have a read only one which staff spend most of their time in, but that then links to the writable one when they need to make changes.
You could even register multiple admin sites: /admin/ showing read-only data and /admin-write/ that allows it to be edited.
I have found creating mini tools a better use of my time, then just follow a shitty workflow because I need to keep doing things until I have reached a certain threshold. YMMV, of course.
The way to scale is to focus on eliminating the need of manual operations/admin tools by giving the power to the users of your products. Focus on self-service. Sure, not everyone should be able to overwrite an arbitrary value or change an important setting but that is easily solved with granular access rights.
In my team, we never want to create a feature that only devs or support team can use. These exclusive features create the need for us to operate them instead of staying focused on engineering.
What would have been a script becomes a feature in the tool with just a slight more effort.
If you don't write it until everything is on fire all the time, it becomes a much bigger task. Plus all the time wasted when you didn't have it.
But perhaps from day one is too early, but it's a very high priority task.
For us we usually just add a new feature to the admin dashboard whenever it's needed for the first time, usually triggered by a customer support question. The downside is that unusual queries can take a few days to answer, but the upside is that we've never built anything we didn't need.
More recently i've used tools such as Retool (there are many alternatives), it has been ideal and allows for non engineers to build there own tools with a little bit of SQL knowledge.
https://github.com/hasura/ra-data-hasura
it's open source too!
https://github.com/Budibase/budibase
Sone invariants are easily expressed in the schema, but others (e.g. anything involving a join) are not.
This is incredibly hard to do, and nearly impossible to scale, but we need to go there.
In the short term one can look at Mastodon, which decentralizes the authority. It's messy but it sort of works.
To be able to remove the admin in Mastodon we would need to change laws since nobody would host a server that they cannot delete illegal content from.
Thinking about these things opens doors to understanding the absurdity of our current society.
In the end: to think that you can control anything is an illusion of energy abundance, and since we are running out of coal, oil and gas; my intuition tells me authority is going to dwindle slowly, then fast and finally all at once.
Thus, my conclusion is: don't build admin interfaces. :D
Adding to this the source-available economy that is the last step in our modern stack, needs user generated/hosted/owned content. So I think moderation tools needs to be less energy intense than manual.
My only solution so far is pride/shame, like hn; so you attach a pseudonym to things: after all that is how communities have worked since we started naming people.
If you have the whole team aware of the basic ground rules for what the admin tools are and what they need to be like moving forward, you can build an ongoing process. i.e. don't merge a feature unless that feature's developer also included a way for the business to configure it to their expectations.
Done correctly, the admin tools should effectively write themselves. It's definitely a lot faster to do this while you are deep in whatever feature.
They can indeed be a pain to build if one puts in the same codebase as the product codebase, best to separate their code out into a separate codebase. Business logic is often not applied to admin tools hence better own codebase.
Recently I built a backend using Node-Red[0], being a card-carrying Emacs user, I was surprised how simple it was to design flows to represent an API for my application. But the really great advantage was the admin tool. I just used Node-Reds dashboard[1] to create a simple frontend to interface with my database. It allowed me to play around with my database schema until it felt usable. After that I designed the API.
Just one more plug: pgModeler[2] is terrific for visualling modelling a postgres database. Incredibly useful and much preferred (for me anyway) over codified migrations. Combined with Node-Red, I could focus on getting the business logic done and not fiddle around with database migrations, data format conversions or debugging code.
[0]=https://nodered.org [1]=https://github.com/node-red/node-red-dashboard [2]=https://pgmodeler.io/ [3]=https://tableplus.com/
The best approach is to re-use the existing setup e.g. hook into existing observability ecosystem instead of building your own from scratch. If support needs to execute something frequently, question if that can be done via any existing orchestrator like Tidal or Autosys etc. If that is insufficient, maybe a dashboard is more manageable since it is server-side. If you see that you are building such dashboards for each of the services, they maybe there is need for a general Support dashboard (even that is not a panacea because that too starts nice and clean and then as Support requests more features, it starts to get out of hand and becomes a dumping ground for random requests). Push back on what is not essential, drive towards fixing the root cause of something that is symptomatic of a deeper issue; on the other hand, if it is a genuine need, add the feature - as with most things, balance is the key.
[1]: https://interval.com
I'm really impressed so far, it can either act as the only backend, or as an admin tool over an existing DB. It also has built-in support for "flows" to automate support tasks.
https://avohq.io
*I am the author of Avo
But still can't find a generic Admin generator/Crud tool for standard REST APIs or GraphQL
Even Retool/Budibase force you to build countless connectors/queries for each resource.
I'd pay $$$ for something that could parse my Graphql API SDL and generate an admin UI for me!