Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Console + CLI way to view enqueued events in topic / for a subscription #3148

Open
deniseli opened this issue Oct 17, 2024 · 1 comment
Open
Labels
console Web console dx triage Issue needs triaging

Comments

@deniseli
Copy link
Contributor

From @KendallWeihe:

a GUI tool for reading the topic/queues. at KFC we used Azure Service Bus as our pubsub and I remember relying heavily on the GUI tool for inspecting messages in the queue for production debugging. just a thought! thanks again

@deniseli deniseli added console Web console dx labels Oct 17, 2024
@github-actions github-actions bot added the triage Issue needs triaging label Oct 17, 2024
This was referenced Oct 17, 2024
@deniseli
Copy link
Contributor Author

deniseli commented Oct 17, 2024

Would be good for this interface to support filtering. Kendall also suggested SQL-like syntax for more advanced filtering. We've discussed this in the past already for the graph view for security review, and also discussed threading that through more of the console/cli, so this definitely warrants further thought/discussion.

Main trade-offs off the top of my head:

  • Change in how we add new filterable-attributes to user-facing record types from: straightforward backend change followed by a DX person making a ConsoleService API change + UI change --> straightforward backend change + some sort of config/annotation/directive/similarly-easy change denoting whether the new attribute should be exposed to users + console/cli sql interface picks it up automatically and no changes needed for console API or UI.
  • Broadly re-usable SQL-like interface in the console, so we don't need to build custom filters for each attr
  • Easy to pack tons and tons of filtering capability into a tiny amount of UI real estate
  • SQL-like filters tend to be unfriendly to less technical users / non-power users. Discoverability of filterable attributes is also hard, unless we make the whole view's schema both accessible and grokkable.

Probably would want to just create a view that's a restricted subset of FTL's actual database contents, restricted based on what we want users to actually have access to, and let them hit that directly with the psql dialect. We do not want our own SQL dialect. oheckno.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
console Web console dx triage Issue needs triaging
Projects
None yet
Development

No branches or pull requests

1 participant