doc: add diagram for how Go SDK interacts with Dapr runtime
- Dominant language
- Go
- Stars
- 479
- Forks
- 187
- PR merge metrics
- No merged PRs in 30d
Description
**Is your feature request related to a problem? Please describe.**
There is no visual representation for how the SDK interacts with the Dapr runtime.
**Describe the solution you'd like**
It would be nice for community members to have a diagram depicting the interactions with end user applications, the Dapr Go SDK, and the Dapr sidecar close to the codebase, within the README.md file.
The diagram should include:
- 3 main components: end user application, Dapr Go SDK, Dapr sidecar
- Initialization: which protocol is the application Dapr client using to establish connection with the Dapr sidecar, HTTP or gRPC? That depends on the SDK and should be depicted visually.
- API calls that one can use the Dapr client for. For example you can save & retrieve state from state stores, publish and subscribe to events using pub/sub, invoke other services using service invocation, etc. We should represent which APIs the SDK supports.
- Overall request routing (when app makes API call through Dapr client, then the request is sent to the Dapr sidecar running along the app)
Other ideas that can be included in diagram:
- Sidecar processing
- Response handling
- Middleware and observability
- Error handling
- Security
**Describe alternatives you've considered**
We could technically keep the README.md file as is, but it would be nice to have visuals here for community members understanding of these interactions.
**Additional context**
https://docs.dapr.io/developing-applications/sdks/
Contributor guide
Research direction
Start with README.md and the linked Dapr SDK documentation to understand the Go SDK's HTTP and gRPC connection paths and supported APIs. Define a diagram covering the end-user application, Go SDK, sidecar, request routing, and representative state, pub/sub, and service-invocation calls; the work is done when the visual is added near the codebase and clearly explains these interactions.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- documentation
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100