Skip to content

feat(components): support remote RPC server connections via full URL configuration#2350

Open
dividedmind wants to merge 1 commit intomainfrom
feat/full-rpc-url
Open

feat(components): support remote RPC server connections via full URL configuration#2350
dividedmind wants to merge 1 commit intomainfrom
feat/full-rpc-url

Conversation

@dividedmind
Copy link
Copy Markdown
Collaborator

@dividedmind dividedmind commented Feb 19, 2026

Add ability to connect to remote RPC servers by accepting full URLs (e.g., 'http://remote:8080', 'https://api.example.com/rpc') in addition to port numbers. This removes the hardcoded localhost limitation while maintaining full backward compatibility with existing port-based configuration. Allowing specifying full URL will make it possible to connect to RPC servers on other hosts; this scenario can occur eg. in the context of remote (eg. SSH, WSL, devcontainer) VSCode development.

Changes:

  • Add RPCUrlUtils module for parsing URLs and port numbers
  • Update AppMapRPC, RPC, ChatSearch, ReviewBackend, and CLI to accept URLs
  • Convert HTTPS → WSS automatically for secure WebSocket connections
  • Add comprehensive unit and integration tests (32 tests)
  • Preserve backward compatibility with existing port-only usage

New usage examples:

new AppMapRPC('http://remote-server:8080')
new AppMapRPC('https://api.example.com/rpc')
<v-chat-search :appmap-rpc-url="'http://remote:8080'" />

Backward compatible:

new AppMapRPC(3000)  // Still works as before
<v-chat-search :appmap-rpc-port="3000" />  // Still works

Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Adds support for configuring RPC connections using full URLs (including remote hosts and HTTPS→WSS WebSocket upgrades) while preserving existing port-based configuration behavior across the components package and CLI UI entrypoint.

Changes:

  • Introduces RPCUrlUtils.parseRpcUrl to normalize port/URL inputs into HTTP + WS endpoints.
  • Updates RPC client wiring (AppMapRPC, RPC, ChatSearch, ReviewBackend) to accept rpcUrl/URL strings in addition to ports.
  • Adds/updates unit tests covering URL parsing and constructor behavior; updates CLI navie.html bootstrap to accept rpcUrl query param.

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 8 comments.

Show a summary per file
File Description
packages/components/tests/unit/lib/RPCUrlUtils.spec.js Adds unit tests for URL/port parsing behavior and edge cases.
packages/components/tests/unit/chat/AppMapRPC.spec.js Extends constructor tests for URL inputs and backward compatibility.
packages/components/src/pages/ChatSearch.vue Adds appmapRpcUrl prop and uses it when constructing AppMapRPC.
packages/components/src/lib/ReviewBackend.ts Makes RPC configuration accept rpcUrl as an alternative to rpcPort.
packages/components/src/lib/RPCUrlUtils.ts New utility to normalize RPC configuration into HTTP + WS URLs.
packages/components/src/lib/RPC.ts Updates browser RPC client to fetch() against a normalized HTTP URL instead of hardcoded localhost.
packages/components/src/lib/AppMapRPC.ts Extends constructor to accept URL strings; updates WebSocket subscribe to use derived WS URL.
packages/cli/src/html/navie.js Accepts rpcUrl query parameter and maps it to the ChatSearch prop.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copy link
Copy Markdown
Contributor

@hleb-rubanau hleb-rubanau left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general, it's very well instrumented with great test coverage.

However, some Copilot nitpicks may still worth attention, plus please consider my comment regarding default scheme (which is optional suggestion, for your decision).

Once these comments/discussions would be processed, I won't see any obstacle for approval. :)

Copy link
Copy Markdown
Contributor

@hleb-rubanau hleb-rubanau left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The only change I request is adding a small remark somewhere in the docs, warning users that specifying remote server without protocol schema is intended for local setups in secure environments and will be resolved to http (not https) by default.

It does not affect functionality and may never be needed in practice.

However, I believe this small disclaimer could prevent big surprises in the future -- both for company and customers.

Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 8 out of 8 changed files in this pull request and generated 3 comments.


💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

…configuration

Add ability to connect to remote RPC servers by accepting full URLs
(e.g., 'http://remote:8080', 'https://api.example.com/rpc') in addition
to port numbers. This removes the hardcoded localhost limitation while
maintaining full backward compatibility with existing port-based configuration.

Changes:
- Add RPCUrlUtils module for parsing URLs and port numbers
- Update AppMapRPC, RPC, ChatSearch, ReviewBackend, and CLI to accept URLs
- Convert HTTPS → WSS automatically for secure WebSocket connections
- Add comprehensive unit and integration tests
- Preserve backward compatibility with existing port-only usage

New usage examples:
  new AppMapRPC('http://remote-server:8080')
  new AppMapRPC('https://api.example.com/rpc')
  <v-chat-search :appmap-rpc-url="'http://remote:8080'" />

Backward compatible:
  new AppMapRPC(3000)  // Still works as before
  <v-chat-search :appmap-rpc-port="3000" />  // Still works
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants