Skip to content

Conversation

@bianbbc87
Copy link
Contributor

@bianbbc87 bianbbc87 commented Oct 11, 2025

What does this PR do / why we need it:
This PR adds comprehensive design documentation introducing a transport abstraction layer for argocd-agent.
The goal is to decouple the principal–agent data stream from the current gRPC dependency and enable multiple transport backends — gRPC, HTTP, and Kafka — for improved compatibility across diverse network environments (e.g., firewalled, air-gapped, or proxy-restricted systems).

This proposal introduces two key abstractions:

  • Transport Interface – handles connection management (Connect, Close, CreateConnection)
  • Stream Interface – defines event-level data operations (Send, Receive, Close)
    By isolating these layers, the agent can easily switch between different transport protocols without modifying higher-level business logic. This enables a cleaner, more modular architecture for future expansion.

Transport Strategy Notes:
HTTP-based Transport:

  • Short/Long Polling (impossible) → too much overhead
  • SSE + HTTP POST (possible) → feasible, but event ack is unclear (needs validation)
  • WebSocket (possible) → already implemented as fallback, can be extended for use

TCP-based Transport (Message Router Model):

  • Introduce Message Router only for queue-based transports
  • HTTP transports use direct connections (no router)
  • Default router implementation: Kafka (possible)

Key additions:

  • Step-by-step communication flow analysis (Before/After)
  • Transport interface design and package structure
  • Code transformation examples showing minimal changes required
  • Implementation strategy for gradual migration

Which issue(s) this PR fixes:

Fixes #260

How to test changes / Special notes to the reviewer:

  • This is documentation-only PR, no code changes
  • Review the proposed architecture for technical feasibility
  • Verify that the Before/After communication flow accurately reflects current implementation
  • Check if the package structure reorganization makes sense
  • Ensure the migration strategy preserves backward compatibility

Checklist

  • Documentation update is required by this PR (and has been updated) OR no documentation update is required.

@bianbbc87 bianbbc87 marked this pull request as draft October 11, 2025 06:51
@bianbbc87 bianbbc87 force-pushed the design/260-make-message-transport branch from 0c3235b to 02e756e Compare October 11, 2025 06:52
└── server.go ← Kafka server

pkg/client/
└── remote.go ← (기존 유지, gRPC transport에서 래핑)
Copy link

@daengdaengLee daengdaengLee Oct 11, 2025

Choose a reason for hiding this comment

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

remote.go : client.Remote 를 인터페이스로 변환
remote_grpc.go : gRPC 용 client.Remote 구현체
remote_http.go : http 용 client.Remote 구현체
...

agent/ 하위에서는 eventstremapapi 패키지의 인터페이스와 메시지 구조체에만 의존, client.Remote 인터페이스 의존

이런 형태로 pkg/client 쪽 설계가 들어가야 하지 않을까요?

--- english transalted ---

remote.go : convert client.Remote into an interface
remote_grpc.go : gRPC implementation of client.Remote
remote_http.go : HTTP implementation of client.Remote
...

Under the agent/ directory, it only depends on the interfaces and message structs from the eventstreamapi package, and on the client.Remote interface.

Wouldn't this be the right direction for the pkg/client design?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

remote.go가 connection 을 담당하고 있어서, 원래 작성했던 connection.go를 제거하고 remote 쪽으로 옮겼습니다 !

@bianbbc87 bianbbc87 marked this pull request as ready for review October 11, 2025 08:31
@bianbbc87 bianbbc87 changed the title docs: add design proposal for pluggable message transport interface design: add design proposal for pluggable message transport interface Oct 11, 2025
Signed-off-by: EunJiJung <[email protected]>
@bianbbc87 bianbbc87 changed the title design: add design proposal for pluggable message transport interface docs: add design proposal for pluggable message transport interface Oct 11, 2025
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.

Make message transport extensible/pluggable

2 participants