Refresh the admin UI and developer workspaces

[burggraf]

Executive summary

This refresh turns TrailBase's admin UI into a cohesive, data-dense developer workspace without changing routes, APIs, permissions, storage keys, or backend behavior.

The largest UX improvements are:

• A consistent application shell with responsive navigation, independent workspace sidebars, light/dark themes, and compact information hierarchy.
• Purpose-built data workflows for Tables, SQL Editor, and ERD rather than generic page layouts.
• Operational clarity across Accounts, WASM, Logs, OpenAPI, and Settings through semantic tables, explicit actions, actionable empty/error states, and safer async behavior.
• Responsive administration at desktop and mobile sizes, including focused navigation, overflow handling, keyboard support, dialogs, and sticky save/reset actions.

Tables workspace

A searchable resource explorer keeps Data, Structure, and API workflows close to the selected table while preserving room for dense records and filters.

ERD workspace

The ERD is now a searchable canvas with table/view filters, neighbor focus, fit/reset controls, and clearer relationship scanning.

Settings workspace

Settings now uses stable category navigation, dense forms, semantic runtime information, safe save/reset behavior, explicit operations, and concurrency-aware configuration merging.

Mobile Settings preview

Workspace changes

• Tables: searchable explorer, Data/Structure/API tabs, safer values and exports, responsive record workflows.
• SQL Editor: execution-first editor/results layout, mobile tabs, local saved queries, safer result rendering and export.
• ERD: searchable/filterable canvas, neighbor focus, fit/reset, clearer table/view distinction.
• Accounts: compact user operations with responsive details and explicit destructive actions.
• WASM Components: dense component list and responsive detail/action layouts.
• Logs: activity visualization, expression filtering, request-safe pagination, semantic status/method presentation.
• OpenAPI: RapiDoc remains the sole renderer, with focused native navigation and fail-closed credential handling.
• Settings: refreshed General, Email, Authentication, Backups, Jobs, Databases, and read-only Schemas categories.

Safety and compatibility

• Preserves SolidJS, Kobalte, Tailwind, TanStack Query/Form/Table, CodeMirror, and RapiDoc.
• Preserves existing routes, APIs, storage keys, permissions, protobuf configuration hashes, and backend behavior.
• Configuration saves fail closed without a cached hash and preserve unrelated/concurrent remote changes.
• Credentials and backend error details are not exposed in UI feedback or logs.
• Async mutations await success and refresh before closing; pending dialogs cannot be dismissed into ambiguous states.
• Runtime JSON number handling is guarded where generated TypeScript bindings use bigint.
• Schema presentation is bounded by source size, nesting depth, formatted output, name safety, and collection count.

Validation

• pnpm check:format — passed
• pnpm check — TypeScript, ESLint, and 404/404 Vitest tests passed
• pnpm build — production build passed
• git diff --check — passed
• Browser acceptance across all major workspaces and all Settings categories:
  • desktop light: 1440×900
  • desktop dark: 1440×900
  • mobile: 390×844
• No horizontal body overflow or unexpected console errors in final browser matrix.
• Independent exact-spec and code-quality/security/accessibility reviews: approved.

Notes

This intentionally does not add a dashboard, replace RapiDoc, introduce new dependencies, add backend APIs, or expand backup/schema tooling beyond the existing product behavior.

[ignatz]

If you want to hop on a quick chat, you can contact me through my github email markb@mantisbible.com.

Appreciated. We can certainly chat but I would prefer all conversation related to the PR to be transparently persisted here. Let's see how far we get.

I work for Supabase, but this is just a hobby sideline because I'm a big fan of OSS and of Trailbase especially.

Appreciated. So you'd be ok, if I ever wanted to change the license to either a better known copyleft license like AGPL or a permissive license like Apache2? Just to be clear, TB will never be proprietary. (Some folks have complaint about OSL3). Not sure how relevant this is (I'm not a lawyer) but Supabase didn't pay for the tokens?

This is definitely a ton of code, but it's all just UI code, so there's not a lot of risk involved here.

I mostly agree with this sentiment. I wouldn't expect to find any code to exfiltrate tokens.

I'd just load it up and go through the screens and see if it works fine for you. I've done that and will continue to go through each screen individually, but overall it seems to look fine to me. Let me know what you'd like to do moving forward or if you want to break things up with a checklist, etc.

I'm also concerned with maintainability and my ability to change it. At first glimpse, some of the code looks a bit verbose. It is maybe worth pointing out that this change, which changes the style and adds some quality-of-life features, more than doubles the entire code of the admin UI. Besides, I'm a stickler so it's important for me to have looked at least over all the code once. It's the responsible thing to do.

I also started playing around with the UI and I agree that the increased information density is very nice and it mostly seems to work. I'm a bit indifferent about the brutalist esthetics. I'm down for using the shadcn sidebar, i don't love the double sidebar. I think the right thing to do would be to use a hierarchical representation in a single sidebar. I found a few very fixable styling issues, e.g.:

I haven't really played with state management yet. I'm less sure about how alien rapidoc looks now. I really love all the changes to the ERD.

[burggraf]

The chat invitation was more personal than to discuss the UI changes here -- agreed all code should be discussed in public. Yes, all the tokens are mine - this was just a personal thing and is not related to Supabase.

As for licensing, I personally prefer Apache but it depends on what your plans are for TB moving forward, and it's totally up to you.

Regarding these UI changes, you can definitely just leave this as an optional extension. I totally understand your concerns about code maintainability, but in this world of AI generation, that ship has pretty much sailed, at least for front-end work. I've been coding by hand for 40 years, but moving forward, people with your dedication to code quality are going to become more and more rare. What you've created is amazing, though, so keep doing what your doing as long as you possibly can.

Lastly, can you explain the styling issue you posted the screenshot for? Off the top of my head I can't spot the issue, depending on how far that screen is scrolled, etc. (Could just be it's too early in the morning and I haven't had my first cup of coffee yet.) EDIT: is it just the clipping at the top?

[ignatz]

The chat invitation was more personal than to discuss the UI changes here -- agreed all code should be discussed in public. Yes, all the tokens are mine - this was just a personal thing and is not related to Supabase.

Thanks for the clarification 🙏

As for licensing, I personally prefer Apache but it depends on what your plans are for TB moving forward, and it's totally up to you.

No major plan, just trying to straddle the middle-ground where improvements to TB itself find their way back to the community, while not trying to be a concern for peoples original work. But maybe to your other point, in an age of AI licenses feel a bit more "fluid".

Regarding these UI changes, you can definitely just leave this as an optional extension.

To be clear, I'm not trying to brush you off. There's good stuff here. I'm trying to be strategic about how to pull in things by priority in more manageable chunks that allows for review.

Independently, challenges with maintaining an admin UI as an extension right now (just trying to be transparent) would be:

• We'd have to version admin APIs more strictly (which isn't necessarily a bad thing, just something that wasn't necessary)
• The features are still growing, e.g. just in the last few months the WASM browser, the openApi browser and the backup UI were added.

I totally understand your concerns about code maintainability, but in this world of AI generation, that ship has pretty much sailed, at least for front-end work. I've been coding by hand for 40 years, but moving forward, people with your dedication to code quality are going to become more and more rare.

You're probably right. I'm just not yet ready to surrender. I want to feel like in 6 months I can still write code w/o a wall of overly verbose and nested code pushing me into the sweat surrender of the overlord.

What you've created is amazing, though, so keep doing what your doing as long as you possibly can.

That's very kind, just don't look to close :)

Lastly, can you explain the styling issue you posted the screenshot for? Off the top of my head I can't spot the issue, depending on how far that screen is scrolled, etc.

If you look at the bottom of the nested sidebar, it got scrolled up (rather than anchored to the screen's bottom) when scrolling the contents on the right.

(Also the press [/] to focus didn't work for me, anyway I'm sure we can find more little issues. That's totally expected and fixable, my point is merely that this would be easier in chunks)

For now I'm thinking of pulling in first or using your work as a template:

• for the ERD, which upon shallow inspection seemed to be the largest functional changes
• crank up information density.

Maybe there were other major pain points you addressed?

[burggraf]

This should be fixed now:

[burggraf]

Extensibility is the key here -- create a basic admin UI and link to community members' extensions as options. I can foresee a "simple admin UI" for people who just want simplicity. Another may have a built in AI chat window for people who just want to write prompts for everything. Another may have a lot more advanced tools for more veteran developers. Your new extension system is the secret sauce here, and reason I came back to take a second look at Trailbase after a failed attempt to use it about a year ago. While I'm a huge fan of Rust and anything written in Rust, early -on TB felt clunky and under-finished. Now it's not only more performant, but the Wasm extension system is brilliant. It wouldn't have worked a few years ago, though -- not enough people know how to setup a wasm toolchain and code for it. Today, people don't need to know anything about Wasm to code for it. And if you're coding with tokens, why would you choose to use Javascript/Typescript when you can use Rust and get better performance? Crazy times we're in.

[ignatz]

I came back to take a second look at Trailbase after a failed attempt to use it about a year ago. While I'm a huge fan of Rust and anything written in Rust, early -on TB felt clunky and under-finished.

That's absolutely fair. There's still a lot of room for improvement. If it had been or now would be perfect, we wouldn't be here discussing :). I really appreciate folks like yourself coming in to make it less buggy, less clunky day by day.

And if you're coding with tokens, why would you choose to use Javascript/Typescript when you can use Rust and get better performance? Crazy times we're in.

Maybe. Why would you choose to use TrailBase or Supabase at all? Didn't recently someone rewrite Postgres in Rust from "scratch" in a weekend? Even if you're right, I'm not sure how to not get existential :). Maybe you have a better understanding where that line would fall, I'm curious

Another may have a built in AI chat window for people who just want to write prompts for everything.

Sure thing, that's why we just added an MCP with access to the admin API. Why not skip the UI entirely?

Extensibility is the key here -- create a basic admin UI and link to community members' extensions as options. I can foresee a "simple admin UI" for people who just want simplicity.

Maybe. Just to stay on topic, I wouldn't call your refresh simpler, it still has all the same features and more. I'd call it improved, better, more polished, ... I'm genuinely interested to bring many of the changes in. Choice between simple and advanced, maybe useful. Choice between crappy and better, less useful :)

While we're chatting, I've started adopting some changes. I'm also discovering more and more quality-of-life features 🙏

[burggraf]

FYI: My goal for this was just to make a more polished admin ui in general, not necessarily to do quality of life improvements, though some of those came along the way. Your goals may differ -- I was just attempting to spruce things up a bit and give it a slightly better first impression for new users. If you'd like me to tackle certain screens from a usability or QOL standpoint, just point me to whatever your priorities are. @ignatz

[ignatz]

FYI: My goal for this was just to make a more polished admin ui in general, not necessarily to do quality of life improvements, though some of those came along the way. Your goals may differ -- I was just attempting to spruce things up a bit and give it a slightly better first impression for new users. If you'd like me to tackle certain screens from a usability or QOL standpoint, just point me to whatever your priorities are. @ignatz

Sounds like we very much agree on the goals. Your sprucing is greatly appreciated and very much not in vain. The only contention is around how to get those changes in. I'm just not sure how to give productive feedback on something that touches everything - maybe just a me problem :hide:.

That said, I love pretty much most of your proposed changes and already pulled many in. Some I mimicked, while the ERD graph UI I mostly just pulled in with some small tuning.

Arguably, this creates friction for you, moving the goalpost under your PR, but I'm still not sure my inner stickler could have done it any other way. Hopefully we're getting closer to your vision and can continue to riff on from here with smaller feature-by-feature or page-by-page changes. I'm also happy to change the overall esthetic but maybe while holding the features steady. I don't love the shadcn default look but I'm also not too sure about the more brutalist look 🤷‍♀️.

Hopefully this works for you and the timely assimilation is understood as a sign of deep appreciation. I would love to continue. WDYT?

[burggraf]

Yeah, no problem at all. Feel free to implement what you like, ignore or modify what you don't, and close the PR. Happy to help in any way.

[ignatz]

Yeah, no problem at all. Feel free to implement what you like, ignore or modify what you don't, and close the PR. Happy to help in any way.

Much appreciated. If you have the energy, maybe take a look at https://demo.trailbase.io/_/admin/ and yell at me for everything that I've missed or messed up 🙏

[burggraf]

Purple on black in the SQL editor. Yuck!

[burggraf]

In my version, I took extra care to identify and display uuid as a hex uuid string instead of a blob:

[ignatz]

I improved the dark-mode colors. I also discovered and really like the multi-format sql-editor data export. Keep em coming 🙏

[burggraf]

Regarding this:

In an ideal world, you'd pre-process the SQL being sent to the backend and warn users if you identify anything that's possibly DDL-related, letting them know it's not a good idea to run DDL commands in the SQL editor if you want migrations to be created automatically. In an even more ideal world, you'd be able to create those migrations automatically from the given SQL, but I don't think that's currently feasible. Maybe just make a note of these things as "nice-to-haves" for the future and move on. In the meantime, I think at the very least there should be a better, more concise explanation on this screen about the potential issues caused by modifying the schema directly.

[ignatz]

Regarding this:

In an ideal world, you'd pre-process the SQL being sent to the backend and warn users if you identify anything that's possibly DDL-related, letting them know it's not a good idea to run DDL commands in the SQL editor if you want migrations to be created automatically. In an even more ideal world, you'd be able to create those migrations automatically from the given SQL, but I don't think that's currently feasible. Maybe just make a note of these things as "nice-to-haves" for the future and move on. In the meantime, I think at the very least there should be a better, more concise explanation on this screen about the potential issues caused by modifying the schema directly.

All good points. The backend already parses and identifies schema mutations. It should be fairly doable. Both, to conditionally warn or write migration files

[ignatz]

Quick update, I've added schema-change detection and removed the by-default Callout 🙏 . We could also add the option to turn schema changes into migrations, it wouldn't be too hard to write a file. I do wonder if there's an impedance mismatch between the inherent iteration loop of an editor and the persistent, never-touch-me-again nature of migrations.