asaskevich/eventbus

<explanation>

Below is a tailored guide for creating a precise system‐design/architecture diagram of the EventBus project. Use this as a blueprint to communicate clearly to your engineering peers.

1. Identify the project type and purpose

• This is a Go library (“EventBus”) implementing an in‑process publish/subscribe event bus with optional asynchronous callbacks and an RPC‑based cross‑process extension (client/server).

• It is intended to be embedded into other Go applications to decouple components via topic‑based events.

2. Analyze the file structure

• Top‑level source files:

– event_bus.go : core EventBus implementation

– network_bus.go : RPC wrapper enabling cross‑process events

– client.go : client‑side RPC helper

– server.go : server‑side RPC helper

• Tests accompany both core and network layers (event_bus_test.go, network_bus_test.go).

• CI/config: .travis.yml, README.md, LICENSE.

3. Examine README for additional insights

• Lists supported methods: New, Subscribe, Publish, SubscribeAsync, WaitAsync, etc.

• Shows in‑process usage vs. cross‑process usage via client and server.

• RPC endpoints exposed at configurable addresses/paths.

4. Main components for the diagram

A. Core EventBus module

– “EventBus” object

– Subscriber registry (map[topic][]callbacks)

– Publisher entry point

– Async dispatcher (goroutine pool or fire‑and‑forget with WaitAsync)

B. Network layer

– RPC server (server.go) exposing EventBus.Publish and Subscribe operations

– RPC client (client.go) calling remote Publish/Subscribe

C. Host application (consumer)

– In‑process components using the EventBus API

– May run as a Publisher, a Subscriber, or both

D. Cross‑process communication

– TCP transport via net/rpc

– HTTP paths or RPC endpoints (e.g., “/_server_bus_”, “/_client_bus_”)

5. Relationships and interactions

• In‑process publish/subscribe

– Publisher → EventBus.Publish → lookup topic handlers → invoke handlers (sync or async)

– Async mode forks goroutines and increments a wait‑group; WaitAsync blocks until done.

• Cross‑process

– Client.Subscribe(…) registers a local handler and issues an RPC call to the server to register interest.

– Server.Publish(…) triggers local EventBus.Publish and broadcasts to registered remote clients via RPC callback.

– RPC transport is bidirectional: client→server for subscriptions, server→client for event delivery.

6. Architectural patterns and design principles

• Decoupling via publish/subscribe pattern

• Separation of concerns:

– Core dispatch logic separated from network transport

– Sync vs. async invocation layers

• Lightweight, single‑binary library (no external dependencies beyond Go stdlib and net/rpc)

• Test‑driven design (unit tests for core and network layers)

7. Diagram‐drawing guidelines

• Use distinct shapes/colors:

– Rectangles for modules (Core EventBus, NetworkBus, RPC Client, RPC Server)

– Cylinders for persistent registries (subscriber registry, wait‑group state)

– Clouds or lightning bolts to represent the network transport

• Label each component clearly.

• Draw directional arrows:

– In‐process Publish → dispatcher → subscribers

– RPC client → (TCP) → RPC server

– RPC server → (TCP) → local EventBus

– Async forks → worker goroutines

• Group sync vs. async flows with dashed vs. solid arrows or different colors.

• Annotate key methods on each component box (e.g., Subscribe, Publish, SubscribeAsync, WaitAsync).

8. Tailoring to this project

• Emphasize the tiny footprint: combine “event_bus.go” logic with “network_bus.go” as two layers.

• Show how client.go and server.go wrap the core EventBus into RPC services.

• Call out configuration parameters (address, RPC path) as labels on the network arrows.

9. Essential elements to include

• Component labels: Core EventBus, Async Dispatcher, Subscriber Registry, RPC Server, RPC Client

• Data‐flow arrows: topic registration, event publishing, handler invocation

• Network transport symbol: TCP/RPC link between client and server

• Color coding:

– Blue for in‑process flow

– Green for async paths

– Orange for cross‑process RPC

By organizing the diagram into these clear layers—core bus, async handling, RPC transport, and host application—you will capture all essential architecture elements without unnecessary complexity. Ensure every arrow, label, and color directly corresponds to code artifacts (files and methods), making the design both accurate and immediately recognizable to other engineers.

</explanation>