retry-go
go-retryablehttp
| retry-go | go-retryablehttp | |
|---|---|---|
| 5 | 3 | |
| 2,223 | 1,847 | |
| 1.9% | 1.6% | |
| 6.2 | 3.7 | |
| 15 days ago | 7 days ago | |
| Go | Go | |
| MIT License | Mozilla Public License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
retry-go
-
Retry operations with constant, delays and exponential backoff strategies
Why this instead of https://github.com/avast/retry-go or https://github.com/cenkalti/backoff ?
- Network Error Handling
-
retry package for golang
What is that advantage of your package compared to other ones like https://github.com/avast/retry-go?
-
Go, NATS, gRPC and PostgreSQL clean architecture microservice with monitoring and tracing 👋
processCreateEmail handling create email events, it's start tracing span, increase metrics counters, then unmarshal message data, and call usecase create method, if it fails, we retry for 3 times using retry-go, if it still fails, we check is the current message redelivered and if redelivery count > maxRedeliveryCount(it's up to your business logic, here is 3 times limit), handling error cases can be very different and depends on your service business logic, in this example used Dead Letter Queue approach.
-
Go, Kafka, gRPC and MongoDB microservice with metrics and tracing 👋
Workers validate message body then call usecase, if it's returns error, try for retry, good library for retry is retry-go, if again fails, publish error message to very simple Dead Letter Queue as i said, didn't implement here any interesting business logic, so in real production we have to handle error cases in the better way. And after message success processed commit it.
go-retryablehttp
- Network Error Handling
-
Building with the GitHub API
Both cases can be mitigated with automated retries. We went with hashicorp/go-retryablehttp as Echoes is built in Go. The library's default retry policy rightly doesn't consider a 401 response as a recoverable error, but this can be changed using the [CheckRetry hook](https://pkg.go.dev/github.com/hashicorp/go-retryablehttp#CheckRetry).
- Any http client framework?
What are some alternatives?
kafka-go - Kafka library in Go
resty - Simple HTTP and REST client library for Go
pgx - PostgreSQL driver and toolkit for Go
heimdall - An enhanced HTTP client for Go
Echo - High performance, minimalist Go web framework
ghinstallation - HTTP Round Tripper for GitHub Apps - Authenticate as an Installation Workflow
Gin - Gin is a HTTP web framework written in Go (Golang). It features a Martini-like API with much better performance -- up to 40 times faster. If you need smashing performance, get yourself some Gin.
github - Go library for accessing the GitHub v3 API
grpc-go - The Go language implementation of gRPC. HTTP/2 based RPC
sarama - Sarama is a Go library for Apache Kafka. [Moved to: https://github.com/IBM/sarama]
kafdrop - Kafka Web UI
swag - Automatically generate RESTful API documentation with Swagger 2.0 for Go.