mss-boot-io community update: green CI, RFC-first security migration, and review tasks

wenxiang lin — Tue, 09 Jun 2026 11:33:39 +0000

A quick community-ops update for mss-boot-io.

The four core repositories currently have no open pull requests, and main-branch CI, CodeQL, and OpenSSF Scorecard checks are green.

The remaining frontend and docs security alerts are not being handled as risky one-off overrides. They are tracked as migration RFCs instead:

mss-boot-admin-antd: frontend Umi / Vite / router security migration
mss-boot-docs: docs dumi / Umi / Vite toolchain migration

I also split the RFCs into smaller contributor-friendly documentation tasks:

frontend migration impact inventory
frontend smoke and rollback checklist
docs toolchain migration impact inventory
docs smoke and rollback checklist

Review help is especially useful around:

quickstart friction
RBAC / Casbin clarity
migration and rollback design
frontend release boundaries
docs gaps for first-time contributors

GitHub organization:
https://github.com/mss-boot-io

The goal is not to chase dependency upgrades blindly, but to keep the project reviewable, testable, and safe for contributors.

Building a Go Admin Framework Around Governance, Not Just CRUD

wenxiang lin — Mon, 08 Jun 2026 15:15:58 +0000

I maintain mss-boot-admin, an open-source Go + React admin project.

This is not a launch post, and I am not asking for stars. I am looking for architecture and governance feedback from developers who have built or maintained internal admin systems.

Why governance matters more than CRUD

CRUD is usually the visible part of an admin system. The hard part starts after the first screens exist:

who can see which menu
which role can call which API
how configuration changes are tracked
how migrations are reviewed
how operational state is exposed
how tests and release notes stay connected to real behavior
how contributors can understand the project without private maintainer memory

That is the direction I want mss-boot to move toward: not just generating admin pages, but making backend governance easier to reason about.

What mss-boot-admin is today

The project currently combines:

Go backend code around the mss-boot framework
Gin and GORM in the backend stack
Casbin for authorization concerns
React, Ant Design v5, and Umi on the frontend side
modules around users, roles, menus, APIs, configuration, notices, tasks, monitoring, and statistics

The broader organization is also moving toward a GitHub-first open-source workflow: CI, CodeQL, OpenSSF Scorecard, issue/PR templates, docs, release notes, and Discussions as the public source of truth.

The architecture question

One design shape in the backend is:

Controller -> Action -> Provider

The goal is to keep controllers thin, keep resource operations consistent, and give cross-cutting concerns a place to live: permissions, context, hooks, data scope, audit behavior, and later better observability.

The tradeoff is obvious: Go developers are rightfully skeptical of abstraction that hides behavior.

So the question is not "can this reduce repetition?" It can. The better question is:

Does it stay debuggable, testable, and understandable as the project grows?

That is the part I want feedback on.

Why I am moving away from generator-first thinking

Code generation can be useful for setup. But if an admin system becomes important, generation is not the main problem anymore.

The harder problems are:

consistent authorization
safe configuration changes
migration discipline
documentation that stays current
release and environment separation
reviewable changes from external contributors
visibility into what changed and why

This is also why I do not want to make legacy dynamic/virtual model features the main direction. They may still matter for existing installations, but the current direction is standard Go code, API-first development, clear tests, and maintainable contracts.

How AI fits into the workflow

I use AI as a maintainer assistant, not as the owner of the project.

The useful parts are:

summarizing PR risk
finding docs gaps
preparing test plans
reviewing dependency upgrades
turning repeated issues into FAQ candidates
keeping project memory in docs instead of private chat history

The maintainer still owns the decisions. That distinction matters.

What I would like feedback on

I would really appreciate criticism on these points:

Does an Action/Hook style layer make sense for a Go admin backend, or does it hide too much behavior?
Where would you draw the line between generic resource actions and explicit service methods?
How would you make hook execution observable and testable?
What would make the README or onboarding more credible to Go developers?
Which parts would you distrust most without stronger tests?

Useful links:

Backend/admin repo: https://github.com/mss-boot-io/mss-boot-admin
Core framework repo: https://github.com/mss-boot-io/mss-boot
Frontend repo: https://github.com/mss-boot-io/mss-boot-admin-antd
Docs: https://docs.mss-boot-io.top
Community discussion index: https://github.com/orgs/mss-boot-io/discussions/377

If you have feedback, I would prefer a GitHub Discussion or Issue so the context stays reusable for other contributors.

DEV Community: wenxiang lin