Terminal UI (TUI) for Bruno - Interactive API testing without leaving the terminal

[cchirag]

Background & Motivation

As a developer who spends most of my time in vim/neovim, I rarely want to leave my terminal environment. Tools like lazygit have shown how powerful terminal-based interactive interfaces can be - they provide the speed and keyboard-driven workflow of CLI tools while maintaining the discoverability and visual feedback of GUI applications.

Currently, most API clients (Postman, Insomnia, etc.) are desktop applications, and while Bruno's desktop app is excellent, it requires running an Electron app with its associated resource overhead. Bruno's CLI is great for automation and CI/CD, but lacks the interactive exploration capabilities needed during active development.

Proposal: Bruno TUI

I'd like to propose building a Terminal User Interface for Bruno that would:

• Stay in the terminal ecosystem - No context switching between terminal and desktop apps
• Leverage existing architecture - Build on top of Bruno's current collection format and processing logic
• Resource efficient - Avoid Electron's memory/CPU footprint while maintaining interactivity
• Complement existing tools - Work alongside the desktop app and CLI, not replace them

Use Cases

• Developers working in terminal-centric environments (vim/neovim users, tmux workflows, etc.)
• Quick API testing during development without launching heavy desktop apps
• Resource-constrained systems where Electron apps are too heavy
• Integration with terminal-based development workflows
• Developers who prefer keyboard-driven interfaces for faster interaction

Core Features (MVP)

• Interactive request builder (method, URL, headers, body)
• Real-time response viewing with syntax highlighting
• Collection navigation and management
• Environment/variable management
• Request history
• Support for Bruno's existing file formats (.bru files)

Technical Approach

• Build as a separate binary that leverages Bruno's core libraries
• Use existing collection parsing and request execution logic
• Focus on keyboard-driven navigation (vim-like keybindings as option)
• Maintain compatibility with Bruno's file formats and structure

Questions for the Team

1. Does this align with Bruno's vision and roadmap?
2. Are there architectural considerations I should be aware of?
3. Would you be open to this as a community contribution?
4. Are there existing libraries/components I should leverage?
5. Any preferences for implementation language/framework (considering Bruno's current stack)?

[Konkrad]

I like the idea. How would you approach it technically? It seems like there are not many TUI frameworks available for nodejs.

[cchirag]

There are several tools like Ink, Blessed, and OpenTUI that make it easier to build a TUI while keeping the codebase maintainable. I haven’t explored all of them enough to say which is the best fit yet, but if this idea feels worth pursuing, we could pick one, build a small POC with minimal features, and test how users interact with it.

[SunP04]

Instead of creating a new one from the ground up, I recommend just supporting existing libraries, like atac