19 ms·

Write admin tools from day one (2022)

199 points by gnutrino 4y ago

gnutrino 4y ago
Don’t wait until support requests become overwhelming, write administrative tools for your software from day one.
- aviatorpro 4y ago
  [flagged]
jalino23 4y ago
I have isAdmin boolean flag on my users table but I feel like I should create an adminUsers table for admin users
- dpkirchner 4y ago
  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.
  - jrumbut 4y ago
    Seconding this, having this flexibility allows your organization to be flexible in the real world.
  - jakelazaroff 4y ago
    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!
- erik_seaberg 4y ago
  The weirdest I’ve seen was using the ecommerce tables. Admin privilege was a thing you bought, like a sheriff’s badge.
- bullen 4y ago
  In my CMS: http://github.com/tinspin/sprout http://github.com/tinspin/sprout I use node based structure on top of a relational db: MySQL, Postgres or Oracle. So 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.
escapedmoose 4y ago
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?
- whynotminot 4y ago
  Yes, but generally only win the "do we have enough time for this" battle after a serious outage shines a light on the need for better tooling.
  - escapedmoose 4y ago
    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
- jrumbut 4y ago
  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.
felixmeziere 4y ago
Use Django :-)
- wombatpm 4y ago
  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
  - Waterluvian 4y ago
    And you can heavily modify and extend the Django Admin views and behaviour.
- Waterluvian 4y ago
  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.
- eurasiantiger 4y ago
  Use Drupal :——)
- avelis 4y ago
  Came here to say the same thing. Django gives you admin tools on day one.
nigamanth 4y ago
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.
jakelazaroff 4y ago
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.
- subradios 4y ago
  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.
- aargh_aargh 4y ago
  Obligatory: https://xkcd.com/1205/ https://xkcd.com/1205/
  - klodolph 4y ago
    I wonder if there's an admin tool someone can make that pattern-matches reposts of XKCD and deletes them.
    - vntok 4y ago
      From the linked xkcd, that seems like a tremendous waste of time..
      - klodolph 4y ago
        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.
    - 4y ago
haney 4y ago
Built in admin is the killer feature that keeps me coming back to Django over and over.
- jamesfinlayson 4y ago
  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.
aranchelk 4y ago
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.
- xwolfi 4y ago
  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.
samwillis 4y ago
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.
- t-writescode 4y ago
  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.
  - irjustin 4y ago
    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.
    - t-writescode 4y ago
      I haven't used Django in around 3 years, but I recall seeing very verbose tooling when I was learning it edit: the default provided admin tools. I didn't know if it was called AdminTools or whatever.
shubhamjain 4y ago
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.
akincel 4y ago
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.
aviatorpro 4y ago
[flagged]
ranting-moth 4y ago
If you write a very simple admin tool very early on, you just have to maintain it and add features to it. 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.
robbie-c 4y ago
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.
afhammad 4y ago
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.
majestic5762 4y ago
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.
- cpursley 4y ago
  There’s also the react-admin hasura connector if you need more control: https://github.com/hasura/ra-data-hasura https://github.com/hasura/ra-data-hasura
foxbee 4y ago
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! it's open source too! https://github.com/Budibase/budibase https://github.com/Budibase/budibase
- stepbeek 4y ago
  My only gripe with tools like this is that I go through a bunch of effort to enforce invariants in code which don’t transfer over. Sone invariants are easily expressed in the schema, but others (e.g. anything involving a join) are not.
bullen 4y ago
If you need admin tools, you need authority. The best way to design products is if they are not centralized or distributed but instead decentralized. 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.
- simiones 4y ago
  Mastodon still needs (and offers) admin tools, for each server. Decentralization does nothing to remove the need for admin tools.
  - bullen 4y ago
    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.
bob1029 4y ago
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.
fluxinflex 4y ago
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. [0]=https://nodered.org https://nodered.org [1]=https://github.com/node-red/node-red-dashboard https://github.com/node-red/node-red-dashboard [2]=https://pgmodeler.io/ https://pgmodeler.io/ [3]=https://tableplus.com/ https://tableplus.com/
noisy_boy 4y ago
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.
- lloydatkinson 4y ago
  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.
jacobmischka 4y ago
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. [1]: https://interval.com https://interval.com
DavidPP 4y ago
I've been playing around with https://directus.io/ https://directus.io/ the last few weeks. 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.
adrianthedev 4y ago
Laravel has Nova, Django has Django Admin, and now, Rails has Avo. https://avohq.io https://avohq.io *I am the author of Avo
- synu 4y ago
  Avo is great, we are using it at my company Synura. Awesome job, it just works with very little configuration.
madarco 4y ago
Always loved Admin tools provided by modern frameworks, like Sonata-Admin for Symfony or Django-admin. 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!
- foxbee 4y ago
  FWIW in Budibase you can generate all the connectors if you have an openAPI spec
Scubabear68 4y ago
I have come to really like Nocodb pointed at your database as a catch-all first approximation of an admin layer. It takes very little to setup and gives you an Airtable like interface to your system. The obvious downside is in the wrong hands you can wreak utter havoc with it…
dmarlow 4y ago
I would argue that engineers should look to build some of those capabilities into the app itself. So many users want the ability to solve their own problems themselves. Obviously don't allow them to reboot servers, etc. But if it's gathering certain types of logs, clearing certain things from the cache, first see if that's something the user could/should want to do themselves. You may end up not just with a good admin tool, but also better user experience and fewer support calls too.
telecuda 4y ago
This has been our approach as we scaled from customer one to acquisition by bigco a decade later, and I'd still point to it as being a key driver of our success: - Set a monthly meeting with a co-worker from each functional area (e.g. finance, support, sales). The meeting should be run by whomever has the best horizontal view of needs across the business, along with whoever is running point on development to clarify things. - Go around the room and ask the question, "What's one thing (report/tool/insight/data/etc) that would make your job easier?" - Track those requests on a shared document or board, giving stakeholders an opportunity to reprioritize their list (should never be more than a "top 3") each meeting - PUNCHLINE: Commit to addressing one item from each department's top 3 every quarter. We did this starting early with engineer #2, but if you can't devote a FTE, divide and conquer among your current team. 10+ years later we have dozens of internal tools that have automated so much of what I see bigco still addressing by throwing people at it. It's never too late to start and it's a great way to build a love affair between your non-technical departments and developers!
- mxuribe 4y ago
  This is such an awesome approach! Kudos for putting this into action at your org. So many orgs that i've worked for/with might have similar ideas (at least for a couple of the noted items), but almost never implement any such thing due to distractions with other aspects of running the business.
  - telecuda 4y ago
    Thanks! If you're looking for an easy place to start, look to tabular reports. Ask a stakeholder (e.g. contract renewals team) to create an ideal report with maybe 5 rows of sample data in Google Sheets / Excel. A good example may be a list of customers, when their next renewal date is, who their sales rep is, etc. Ask a developer to turn it into a real-time (or nightly updated) internal web page, then once again, each quarter see if it needs to be made better. Sure, Salesforce and the like should have a lot of this data, but odds are you need a hybrid of info that leverages your own DB (e.g. usage, # of users). If a new vanilla Salesforce report comes out of that monthly meeting instead, hey, still good stuff. We call this team "Ops" for short and more formally the "SaaS Operations" team since they satisfy all the internal bits that get help us run an efficient SaaS business. For reference, while we have a small team, it's 20% of our headcount (and a great place for interns/co-ops). Happy staff with the right tools stick around longer, are better at serving customers, and have more free time to work on more important goals.
rman666 4y ago
Hey, Andy! Representing the MKE! Word! Lol.
- gnutrino 4y ago
  Woot! Thanks for reading!
pajuc 4y ago
Thinking of a project where 1 person knows how to admin something with quite a bunch of Postman setups on their own computer. At least provide CLIs.
hkon 4y ago
Maybe not admin tools, but at least functionality so that users can unf*k themselves. I've worked on projects where adding information was the feature, but updating or deleting it was "nice to have". After a couple of months, constant requests coming in to developers for changing or delete users information, but still no prioritization of such features. Directly in db ofc, since no tooling.

199 points by gnutrino 4y ago

gnutrino 4y ago

Don’t wait until support requests become overwhelming, write administrative tools for your software from day one.

aviatorpro 4y ago
[flagged]

jalino23 4y ago

I have isAdmin boolean flag on my users table but I feel like I should create an adminUsers table for admin users

dpkirchner 4y ago
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.
- jrumbut 4y ago
  Seconding this, having this flexibility allows your organization to be flexible in the real world.
- jakelazaroff 4y ago
  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!
erik_seaberg 4y ago
The weirdest I’ve seen was using the ecommerce tables. Admin privilege was a thing you bought, like a sheriff’s badge.
bullen 4y ago
In my CMS: http://github.com/tinspin/sprout http://github.com/tinspin/sprout I use node based structure on top of a relational db: MySQL, Postgres or Oracle. So 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.

escapedmoose 4y ago

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?

whynotminot 4y ago
Yes, but generally only win the "do we have enough time for this" battle after a serious outage shines a light on the need for better tooling.
- escapedmoose 4y ago
  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
jrumbut 4y ago
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.

felixmeziere 4y ago

Use Django :-)

wombatpm 4y ago
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
- Waterluvian 4y ago
  And you can heavily modify and extend the Django Admin views and behaviour.
Waterluvian 4y ago
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.
eurasiantiger 4y ago
Use Drupal :——)
avelis 4y ago
Came here to say the same thing. Django gives you admin tools on day one.

nigamanth 4y ago

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.

jakelazaroff 4y ago

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.

subradios 4y ago
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.
aargh_aargh 4y ago
Obligatory: https://xkcd.com/1205/ https://xkcd.com/1205/
- klodolph 4y ago
  I wonder if there's an admin tool someone can make that pattern-matches reposts of XKCD and deletes them.
  - vntok 4y ago
    From the linked xkcd, that seems like a tremendous waste of time..
    - klodolph 4y ago
      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.
  - 4y ago

haney 4y ago

Built in admin is the killer feature that keeps me coming back to Django over and over.

jamesfinlayson 4y ago
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.

aranchelk 4y ago

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.

xwolfi 4y ago
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.

samwillis 4y ago

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.

t-writescode 4y ago
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.
- irjustin 4y ago
  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.
  - t-writescode 4y ago
    I haven't used Django in around 3 years, but I recall seeing very verbose tooling when I was learning it edit: the default provided admin tools. I didn't know if it was called AdminTools or whatever.

shubhamjain 4y ago

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.

akincel 4y ago

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.

aviatorpro 4y ago

[flagged]

ranting-moth 4y ago

If you write a very simple admin tool very early on, you just have to maintain it and add features to it. 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.

robbie-c 4y ago

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.

afhammad 4y ago

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.

majestic5762 4y ago

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.

cpursley 4y ago
There’s also the react-admin hasura connector if you need more control: https://github.com/hasura/ra-data-hasura https://github.com/hasura/ra-data-hasura

foxbee 4y ago

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! it's open source too! https://github.com/Budibase/budibase https://github.com/Budibase/budibase

stepbeek 4y ago
My only gripe with tools like this is that I go through a bunch of effort to enforce invariants in code which don’t transfer over. Sone invariants are easily expressed in the schema, but others (e.g. anything involving a join) are not.

bullen 4y ago

If you need admin tools, you need authority. The best way to design products is if they are not centralized or distributed but instead decentralized. 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.

simiones 4y ago
Mastodon still needs (and offers) admin tools, for each server. Decentralization does nothing to remove the need for admin tools.
- bullen 4y ago
  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.

bob1029 4y ago

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.

fluxinflex 4y ago

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. [0]=https://nodered.org https://nodered.org [1]=https://github.com/node-red/node-red-dashboard https://github.com/node-red/node-red-dashboard [2]=https://pgmodeler.io/ https://pgmodeler.io/ [3]=https://tableplus.com/ https://tableplus.com/

noisy_boy 4y ago

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.

lloydatkinson 4y ago
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.

jacobmischka 4y ago

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. [1]: https://interval.com https://interval.com

DavidPP 4y ago

I've been playing around with https://directus.io/ https://directus.io/ the last few weeks. 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.

adrianthedev 4y ago

Laravel has Nova, Django has Django Admin, and now, Rails has Avo. https://avohq.io https://avohq.io *I am the author of Avo

synu 4y ago
Avo is great, we are using it at my company Synura. Awesome job, it just works with very little configuration.

madarco 4y ago

Always loved Admin tools provided by modern frameworks, like Sonata-Admin for Symfony or Django-admin. 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!

foxbee 4y ago
FWIW in Budibase you can generate all the connectors if you have an openAPI spec

Scubabear68 4y ago

I have come to really like Nocodb pointed at your database as a catch-all first approximation of an admin layer. It takes very little to setup and gives you an Airtable like interface to your system. The obvious downside is in the wrong hands you can wreak utter havoc with it…

dmarlow 4y ago

I would argue that engineers should look to build some of those capabilities into the app itself. So many users want the ability to solve their own problems themselves. Obviously don't allow them to reboot servers, etc. But if it's gathering certain types of logs, clearing certain things from the cache, first see if that's something the user could/should want to do themselves. You may end up not just with a good admin tool, but also better user experience and fewer support calls too.

telecuda 4y ago

This has been our approach as we scaled from customer one to acquisition by bigco a decade later, and I'd still point to it as being a key driver of our success: - Set a monthly meeting with a co-worker from each functional area (e.g. finance, support, sales). The meeting should be run by whomever has the best horizontal view of needs across the business, along with whoever is running point on development to clarify things. - Go around the room and ask the question, "What's one thing (report/tool/insight/data/etc) that would make your job easier?" - Track those requests on a shared document or board, giving stakeholders an opportunity to reprioritize their list (should never be more than a "top 3") each meeting - PUNCHLINE: Commit to addressing one item from each department's top 3 every quarter. We did this starting early with engineer #2, but if you can't devote a FTE, divide and conquer among your current team. 10+ years later we have dozens of internal tools that have automated so much of what I see bigco still addressing by throwing people at it. It's never too late to start and it's a great way to build a love affair between your non-technical departments and developers!

mxuribe 4y ago
This is such an awesome approach! Kudos for putting this into action at your org. So many orgs that i've worked for/with might have similar ideas (at least for a couple of the noted items), but almost never implement any such thing due to distractions with other aspects of running the business.
- telecuda 4y ago
  Thanks! If you're looking for an easy place to start, look to tabular reports. Ask a stakeholder (e.g. contract renewals team) to create an ideal report with maybe 5 rows of sample data in Google Sheets / Excel. A good example may be a list of customers, when their next renewal date is, who their sales rep is, etc. Ask a developer to turn it into a real-time (or nightly updated) internal web page, then once again, each quarter see if it needs to be made better. Sure, Salesforce and the like should have a lot of this data, but odds are you need a hybrid of info that leverages your own DB (e.g. usage, # of users). If a new vanilla Salesforce report comes out of that monthly meeting instead, hey, still good stuff. We call this team "Ops" for short and more formally the "SaaS Operations" team since they satisfy all the internal bits that get help us run an efficient SaaS business. For reference, while we have a small team, it's 20% of our headcount (and a great place for interns/co-ops). Happy staff with the right tools stick around longer, are better at serving customers, and have more free time to work on more important goals.

rman666 4y ago

Hey, Andy! Representing the MKE! Word! Lol.

gnutrino 4y ago
Woot! Thanks for reading!

pajuc 4y ago

Thinking of a project where 1 person knows how to admin something with quite a bunch of Postman setups on their own computer. At least provide CLIs.

hkon 4y ago

Maybe not admin tools, but at least functionality so that users can unf*k themselves. I've worked on projects where adding information was the feature, but updating or deleting it was "nice to have". After a couple of months, constant requests coming in to developers for changing or delete users information, but still no prioritization of such features. Directly in db ofc, since no tooling.