RockteMQ-AI commented on issue #1951:
URL:
https://github.com/apache/rocketmq-dashboard/issues/1951#issuecomment-5262995033
**Issue Evaluation**
Category: `type/enhancement` | Status: **Evaluated**
**Feasibility:** Feasible
**Scope:** Backend (`InstanceProvider` SPI, new capability endpoint),
Frontend (navigation filtering, API service layer)
**Compatibility:** No breaking changes — purely additive API endpoint
This is a well-structured proposal that addresses a real UX problem: users
see navigation entries for capabilities that the selected instance provider
does not support, only to get HTTP 501 after the request.
The capability-driven approach is sound:
- A provider-owned capability enum with a default SPI contract is the right
abstraction
- `GET /api/instances/{instanceId}/capabilities` as a single source of truth
avoids the current fragmented per-feature pattern
- Frontend consuming the contract to filter navigation is a clean separation
of concerns
**Implementation notes:**
1. The capability enum should be extensible (not a sealed set) so new
providers can declare capabilities without modifying the core contract
2. Consider caching the capability response on the frontend (per selected
instance) to avoid repeated calls on every navigation
3. The graceful degradation requirement (API failure does not remove core
navigation) is important — the frontend should default to showing all entries
if the capabilities endpoint fails
**Scope is well-defined.** The explicit out-of-scope section (runtime
probing, Proxy Admin, LiteTopic) prevents scope creep.
---
*Automated evaluation by RockteMQ-AI*
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
