Ecosyste.ms: Funds
An open API service for providing issue and pull request metadata for open source projects.
https://github.com/grpc-ecosystem/go-grpc-middleware
authentication generic-functions golang grpc interceptor library logging middleware retries testing
Last synced: about 3 hours ago
Repository metadata:
Golang gRPC Middlewares: interceptor chaining, auth, logging, retries and more.
- Host: GitHub
- URL: https://github.com/grpc-ecosystem/go-grpc-middleware
- Owner: grpc-ecosystem
- License: apache-2.0
- Created: 2016-05-14T17:48:56.000Z (over 8 years ago)
- Default Branch: main
- Last Pushed: 2024-10-25T23:23:57.000Z (15 days ago)
- Last Synced: 2024-10-29T20:31:52.639Z (11 days ago)
- Topics: authentication, generic-functions, golang, grpc, interceptor, library, logging, middleware, retries, testing
- Language: Go
- Homepage:
- Size: 13.6 MB
- Stars: 6,292
- Watchers: 85
- Forks: 692
- Open Issues: 92
-
Metadata Files:
- Readme: README.md
- Contributing: CONTRIBUTING.md
- License: LICENSE
Owner metadata:
- Name: gRPC Ecosystem
- Login: grpc-ecosystem
- Email: [email protected]
- Kind: organization
- Description: gRPC Ecosystem that complements gRPC
- Website: https://www.grpc.io
- Location:
- Twitter: grpcio
- Company:
- Icon url: https://avatars.githubusercontent.com/u/19352526?v=4
- Repositories: 22
- Last Synced at: 2024-10-30T22:02:05.506Z
- Profile URL: https://github.com/grpc-ecosystem
- Sponsor URL:
Committers metadata
Last synced: 1 day ago
Total Commits: 354
Total Committers: 156
Avg Commits per committer: 2.269
Development Distribution Score (DDS): 0.797
Commits in past year: 31
Committers in past year: 18
Avg Commits per committer in past year: 1.722
Development Distribution Score (DDS) in past year: 0.742
Name | Commits | |
---|---|---|
Michal Witkowski | m****l@i****o | 72 |
Dominic Green | d****1@g****m | 23 |
Bartlomiej Plotka | b****a@g****m | 19 |
Yash Sharma | y****4@g****m | 9 |
Akshay Shah | a****y@a****g | 8 |
Dmitry Savintsev | d****s | 7 |
aimuz | m****z@g****m | 6 |
Dominic Green | d****m@i****o | 6 |
Mikhail Mazurskiy | m****y@g****m | 5 |
Tiernan | t****r@j****u | 5 |
Rajiv Singh | r****7@g****m | 4 |
kartlee | k****n@s****m | 4 |
Mikhail Mazurskiy | 1****k | 3 |
Marc Wilson | m****g | 3 |
Till | t****g@p****m | 3 |
Tiago Peczenyj | t****j@g****m | 3 |
Junpei Kawamoto | k****i@g****m | 3 |
Johan Brandhorst | j****t@g****m | 3 |
Bulat Khasanov | a****i@y****u | 3 |
Jordan Liggitt | j****n@l****t | 2 |
Juraci Paixão Kröhling | j****b@k****e | 2 |
Matthias Loibl | m****l@m****m | 2 |
Maxim Korolyov | k****m@g****m | 2 |
Olivier Lemasle | o****e@g****m | 2 |
Oscar Gimenez | o****b@g****m | 2 |
Peter Edge | p****e@g****m | 2 |
Rahul Khairwar | r****r@g****m | 2 |
Sam Xie | s****m@s****e | 2 |
Stan Hu | s****u@g****m | 2 |
Taka Nishida | t****e@g****m | 2 |
and 126 more... |
Issue and Pull Request metadata
Last synced: about 3 hours ago
Package metadata
- Total packages: 30
- Total downloads: unknown
- Total docker downloads: 30,434,106,540
- Total dependent packages: 16,139 (may contain duplicates)
- Total dependent repositories: 75,723 (may contain duplicates)
- Total versions: 72
go: github.com/grpc-ecosystem/go-grpc-middleware
`grpc_middleware` is a collection of gRPC middleware packages: interceptors, helpers and tools. gRPC is a fantastic RPC middleware, which sees a lot of adoption in the Golang world. However, the upstream gRPC codebase is relatively bare bones. This package, and most of its child packages provides commonly needed middleware for gRPC: client-side interceptors for retires, server-side interceptors for input validation and auth, functions for chaining said interceptors, metadata convenience methods and more. By default, gRPC doesn't allow one to have more than one interceptor either on the client nor on the server side. `grpc_middleware` provides convenient chaining methods Simple way of turning a multiple interceptors into a single interceptor. Here's an example for server chaining: These interceptors will be executed from left to right: logging, monitoring and auth. Here's an example for client side chaining: These interceptors will be executed from left to right: monitoring and then retry logic. The retry interceptor will call every interceptor that follows it whenever when a retry happens. Implementing your own interceptor is pretty trivial: there are interfaces for that. But the interesting bit exposing common data to handlers (and other middleware), similarly to HTTP Middleware design. For example, you may want to pass the identity of the caller from the auth interceptor all the way to the handling function. For example, a client side interceptor example for auth looks like: Unfortunately, it's not as easy for streaming RPCs. These have the `context.Context` embedded within the `grpc.ServerStream` object. To pass values through context, a wrapper (`WrappedServerStream`) is needed. For example:
- Homepage: https://github.com/grpc-ecosystem/go-grpc-middleware
- Documentation: https://pkg.go.dev/github.com/grpc-ecosystem/go-grpc-middleware#section-documentation
- Licenses: Apache-2.0
- Latest release: v1.4.0 (published over 1 year ago)
- Last Synced: 2024-11-09T00:31:33.195Z (1 day ago)
- Versions: 7
- Dependent Packages: 15,493
- Dependent Repositories: 74,483
- Docker Downloads: 29,592,815,222
-
Rankings:
- Dependent packages count: 0.011%
- Docker downloads count: 0.013%
- Dependent repos count: 0.016%
- Average: 0.419%
- Stargazers count: 0.91%
- Forks count: 1.144%
go: github.com/grpc-ecosystem/go-grpc-middleware/v2
Package middleware `middleware` is a collection of gRPC middleware packages: interceptors, helpers and tools. gRPC is a fantastic RPC middleware, which sees a lot of adoption in the Golang world. However, the upstream gRPC codebase is relatively bare bones. This package, and most of its child packages provides commonly needed middleware for gRPC: client-side interceptors for retires, server-side interceptors for input validation and auth, functions for chaining said interceptors, metadata convenience methods and more. Simple way of turning a multiple interceptors into a single interceptor. Here's an example for server chaining: These interceptors will be executed from left to right: logging, monitoring and auth. Here's an example for client side chaining: These interceptors will be executed from left to right: monitoring and then retry logic. The retry interceptor will call every interceptor that follows it whenever when a retry happens. Implementing your own interceptor is pretty trivial: there are interfaces for that. But the interesting bit exposing common data to handlers (and other middleware), similarly to HTTP Middleware design. For example, you may want to pass the identity of the caller from the auth interceptor all the way to the handling function. For example, a client side interceptor example for auth looks like: Unfortunately, it's not as easy for streaming RPCs. These have the `context.Context` embedded within the `grpc.ServerStream` object. To pass values through context, a wrapper (`WrappedServerStream`) is needed. For example:
- Homepage: https://github.com/grpc-ecosystem/go-grpc-middleware
- Documentation: https://pkg.go.dev/github.com/grpc-ecosystem/go-grpc-middleware/v2#section-documentation
- Licenses: Apache-2.0
- Latest release: v2.1.0 (published 9 months ago)
- Last Synced: 2024-11-09T00:31:35.860Z (1 day ago)
- Versions: 8
- Dependent Packages: 403
- Dependent Repositories: 661
- Docker Downloads: 425,567,180
-
Rankings:
- Dependent packages count: 0.282%
- Dependent repos count: 0.287%
- Docker downloads count: 0.326%
- Average: 0.59%
- Stargazers count: 0.91%
- Forks count: 1.144%
go: github.com/grpc-ecosystem/go-grpc-middleware/providers/kit/v2
Package kit provides a small adapter required to use go-kit/log in logging gRPC middlewares. Please see examples for examples of use.
- Homepage: https://github.com/grpc-ecosystem/go-grpc-middleware
- Documentation: https://pkg.go.dev/github.com/grpc-ecosystem/go-grpc-middleware/providers/kit/v2#section-documentation
- Licenses: Apache-2.0
- Latest release: v2.0.0-rc.3 (published about 2 years ago)
- Last Synced: 2024-11-09T00:31:27.062Z (1 day ago)
- Versions: 1
- Dependent Packages: 32
- Dependent Repositories: 425
- Docker Downloads: 18,313,400
-
Rankings:
- Dependent repos count: 0.339%
- Docker downloads count: 0.4%
- Average: 0.719%
- Dependent packages count: 0.804%
- Stargazers count: 0.91%
- Forks count: 1.144%
go: github.com/grpc-ecosystem/go-grpc-middleware/providers/zerolog/v2
Package zerolog provides a small adapter required to use zerolog in logging gRPC middlewares. Please see examples for examples of use.
- Homepage: https://github.com/grpc-ecosystem/go-grpc-middleware
- Documentation: https://pkg.go.dev/github.com/grpc-ecosystem/go-grpc-middleware/providers/zerolog/v2#section-documentation
- Licenses: Apache-2.0
- Latest release: v2.0.0-rc.3 (published about 2 years ago)
- Last Synced: 2024-11-09T00:31:33.189Z (1 day ago)
- Versions: 3
- Dependent Packages: 118
- Dependent Repositories: 85
- Docker Downloads: 7,802
-
Rankings:
- Dependent packages count: 0.48%
- Dependent repos count: 0.644%
- Average: 0.841%
- Stargazers count: 0.91%
- Docker downloads count: 1.029%
- Forks count: 1.144%
go: github.com/grpc-ecosystem/go-grpc-middleware/providers/openmetrics/v2
- Homepage: https://github.com/grpc-ecosystem/go-grpc-middleware
- Documentation: https://pkg.go.dev/github.com/grpc-ecosystem/go-grpc-middleware/providers/openmetrics/v2#section-documentation
- Licenses: Apache-2.0
- Latest release: v2.0.0-rc.3 (published about 2 years ago)
- Last Synced: 2024-11-09T00:31:36.406Z (1 day ago)
- Versions: 1
- Dependent Packages: 13
- Dependent Repositories: 45
- Docker Downloads: 34,623,020
-
Rankings:
- Docker downloads count: 0.35%
- Dependent repos count: 0.857%
- Stargazers count: 0.909%
- Average: 1.095%
- Forks count: 1.141%
- Dependent packages count: 2.217%
go: github.com/grpc-ecosystem/go-grpc-middleware/providers/zap/v2
Package zap provides a small adapter required to use zap in logging gRPC middlewares. Please see examples for examples of use.
- Homepage: https://github.com/grpc-ecosystem/go-grpc-middleware
- Documentation: https://pkg.go.dev/github.com/grpc-ecosystem/go-grpc-middleware/providers/zap/v2#section-documentation
- Licenses: Apache-2.0
- Latest release: v2.0.0-rc.3 (published about 2 years ago)
- Last Synced: 2024-11-09T00:31:31.592Z (1 day ago)
- Versions: 1
- Dependent Packages: 11
- Dependent Repositories: 9
- Docker Downloads: 1,685
-
Rankings:
- Stargazers count: 0.91%
- Forks count: 1.144%
- Docker downloads count: 1.225%
- Average: 1.348%
- Dependent packages count: 1.687%
- Dependent repos count: 1.774%
go: github.com/grpc-ecosystem/go-grpc-middleware/providers/opentracing/v2
- Homepage: https://github.com/grpc-ecosystem/go-grpc-middleware
- Documentation: https://pkg.go.dev/github.com/grpc-ecosystem/go-grpc-middleware/providers/opentracing/v2#section-documentation
- Licenses: Apache-2.0
- Latest release: v2.0.0-rc.3 (published about 2 years ago)
- Last Synced: 2024-11-09T00:31:34.646Z (1 day ago)
- Versions: 1
- Dependent Packages: 3
- Dependent Repositories: 4
- Docker Downloads: 1,685
-
Rankings:
- Stargazers count: 0.909%
- Forks count: 1.141%
- Docker downloads count: 1.225%
- Average: 1.904%
- Dependent repos count: 2.572%
- Dependent packages count: 3.672%
go: github.com/grpc-ecosystem/go-grpc-middleware/tags
`grpc_ctxtags` adds a Tag object to the context that can be used by other middleware to add context about a request. Tags describe information about the request, and can be set and used by other middleware, or handlers. Tags are used for logging and tracing of requests. Tags are populated both upwards, *and* downwards in the interceptor-handler stack. You can automatically extract tags (in `grpc.request.<field_name>`) from request payloads. For unary and server-streaming methods, pass in the `WithFieldExtractor` option. For client-streams and bidirectional-streams, you can use `WithFieldExtractorForInitialReq` which will extract the tags from the first message passed from client to server. Note the tags will not be modified for subsequent requests, so this option only makes sense when the initial message establishes the meta-data for the stream. If a user doesn't use the interceptors that initialize the `Tags` object, all operations following from an `Extract(ctx)` will be no-ops. This is to ensure that code doesn't panic if the interceptors weren't used. Tags fields are typed, and shallow and should follow the OpenTracing semantics convention: https://github.com/opentracing/specification/blob/master/semantic_conventions.md Example using WithFieldExtractorForInitialReq Simple example of server initialization code, with data automatically populated from `log_fields` Golang tags.
- Homepage: https://github.com/grpc-ecosystem/go-grpc-middleware
- Documentation: https://pkg.go.dev/github.com/grpc-ecosystem/go-grpc-middleware/tags#section-documentation
- Licenses: Apache-2.0
- Latest release:
- Last Synced: 2024-11-06T23:30:56.592Z (3 days ago)
- Versions: 0
- Dependent Packages: 0
- Dependent Repositories: 0
-
Rankings:
- Stargazers count: 0.773%
- Forks count: 1.001%
- Average: 3.622%
- Dependent packages count: 6.151%
- Dependent repos count: 6.563%
go: github.com/grpc-ecosystem/go-grpc-middleware/logging/zap
`grpc_zap` is a gRPC logging middleware backed by ZAP loggers It accepts a user-configured `zap.Logger` that will be used for logging completed gRPC calls. The same `zap.Logger` will be used for logging completed gRPC calls, and be populated into the `context.Context` passed into gRPC handler code. On calling `StreamServerInterceptor` or `UnaryServerInterceptor` this logging middleware will add gRPC call information to the ctx so that it will be present on subsequent use of the `ctx_zap` logger. If a deadline is present on the gRPC request the grpc.request.deadline tag is populated when the request begins. grpc.request.deadline is a string representing the time (RFC3339) when the current call will expire. This package also implements request and response *payload* logging, both for server-side and client-side. These will be logged as structured `jsonpb` fields for every message received/sent (both unary and streaming). For that please use `Payload*Interceptor` functions for that. Please note that the user-provided function that determines whether to log the full request/response payload needs to be written with care, this can significantly slow down gRPC. ZAP can also be made as a backend for gRPC library internals. For that use `ReplaceGrpcLoggerV2`. *Server Interceptor* Below is a JSON formatted example of a log that would be logged by the server interceptor: *Payload Interceptor* Below is a JSON formatted example of a log that would be logged by the payload interceptor: Note - due to implementation ZAP differs from Logrus in the "grpc.request.content" object by having an inner "msg" object. Please see examples and tests for examples of use. Please see settable_test.go for canonical integration through "zaptest" with golang testing infrastructure. Initialization shows a relatively complex initialization sequence. Initialization shows an initialization sequence with the duration field generation overridden.
- Homepage: https://github.com/grpc-ecosystem/go-grpc-middleware
- Documentation: https://pkg.go.dev/github.com/grpc-ecosystem/go-grpc-middleware/logging/zap#section-documentation
- Licenses: Apache-2.0
- Latest release:
- Last Synced: 2024-11-06T23:30:51.921Z (3 days ago)
- Versions: 0
- Dependent Packages: 0
- Dependent Repositories: 0
-
Rankings:
- Stargazers count: 0.773%
- Forks count: 1.001%
- Average: 3.622%
- Dependent packages count: 6.151%
- Dependent repos count: 6.563%
go: github.com/grpc-ecosystem/go-grpc-middleware/providers/logr/v2
Package logr provides a small adapter required to use logr in logging gRPC middlewares. Please see examples for examples of use.
- Homepage: https://github.com/grpc-ecosystem/go-grpc-middleware
- Documentation: https://pkg.go.dev/github.com/grpc-ecosystem/go-grpc-middleware/providers/logr/v2#section-documentation
- Licenses: Apache-2.0
- Latest release: v2.0.0-rc.3 (published about 2 years ago)
- Last Synced: 2024-11-09T00:31:24.589Z (1 day ago)
- Versions: 1
- Dependent Packages: 0
- Dependent Repositories: 1
-
Rankings:
- Stargazers count: 0.911%
- Forks count: 1.14%
- Average: 3.824%
- Dependent repos count: 4.794%
- Dependent packages count: 8.453%
go: github.com/grpc-ecosystem/go-grpc-middleware/providers/prometheus
Package prometheus provides a standalone interceptor for metrics. It's next iteration of deprecated https://github.com/grpc-ecosystem/go-grpc-prometheus. See https://github.com/grpc-ecosystem/go-grpc-middleware/tree/main/examples for example.
- Homepage: https://github.com/grpc-ecosystem/go-grpc-middleware
- Documentation: https://pkg.go.dev/github.com/grpc-ecosystem/go-grpc-middleware/providers/prometheus#section-documentation
- Licenses: Apache-2.0
- Latest release: v1.0.1 (published 7 months ago)
- Last Synced: 2024-11-09T00:31:39.355Z (1 day ago)
- Versions: 3
- Dependent Packages: 66
- Dependent Repositories: 10
- Docker Downloads: 362,776,546
-
Rankings:
- Docker downloads count: 1.607%
- Dependent repos count: 1.694%
- Average: 3.918%
- Dependent packages count: 8.453%
go: github.com/grpc-ecosystem/go-grpc-middleware/providers/tokenbucket/v2
Simple example of server initialization code.
- Homepage: https://github.com/grpc-ecosystem/go-grpc-middleware
- Documentation: https://pkg.go.dev/github.com/grpc-ecosystem/go-grpc-middleware/providers/tokenbucket/v2#section-documentation
- Licenses: Apache-2.0
- Latest release: v2.0.0-rc.3 (published about 2 years ago)
- Last Synced: 2024-11-09T00:31:28.848Z (1 day ago)
- Versions: 1
- Dependent Packages: 0
- Dependent Repositories: 0
-
Rankings:
- Stargazers count: 0.581%
- Forks count: 0.739%
- Average: 4.416%
- Dependent packages count: 6.999%
- Dependent repos count: 9.346%
go: github.com/gRPC-ecosystem/go-grpc-middleware
`grpc_middleware` is a collection of gRPC middleware packages: interceptors, helpers and tools. gRPC is a fantastic RPC middleware, which sees a lot of adoption in the Golang world. However, the upstream gRPC codebase is relatively bare bones. This package, and most of its child packages provides commonly needed middleware for gRPC: client-side interceptors for retires, server-side interceptors for input validation and auth, functions for chaining said interceptors, metadata convenience methods and more. By default, gRPC doesn't allow one to have more than one interceptor either on the client nor on the server side. `grpc_middleware` provides convenient chaining methods Simple way of turning a multiple interceptors into a single interceptor. Here's an example for server chaining: These interceptors will be executed from left to right: logging, monitoring and auth. Here's an example for client side chaining: These interceptors will be executed from left to right: monitoring and then retry logic. The retry interceptor will call every interceptor that follows it whenever when a retry happens. Implementing your own interceptor is pretty trivial: there are interfaces for that. But the interesting bit exposing common data to handlers (and other middleware), similarly to HTTP Middleware design. For example, you may want to pass the identity of the caller from the auth interceptor all the way to the handling function. For example, a client side interceptor example for auth looks like: Unfortunately, it's not as easy for streaming RPCs. These have the `context.Context` embedded within the `grpc.ServerStream` object. To pass values through context, a wrapper (`WrappedServerStream`) is needed. For example:
- Homepage: https://github.com/gRPC-ecosystem/go-grpc-middleware
- Documentation: https://pkg.go.dev/github.com/gRPC-ecosystem/go-grpc-middleware#section-documentation
- Licenses: Apache-2.0
- Latest release: v1.4.0 (published over 1 year ago)
- Last Synced: 2024-11-09T00:31:29.637Z (1 day ago)
- Versions: 7
- Dependent Packages: 0
- Dependent Repositories: 0
-
Rankings:
- Stargazers count: 0.581%
- Forks count: 0.739%
- Average: 4.416%
- Dependent packages count: 6.999%
- Dependent repos count: 9.346%
go: github.com/grpc-ecosystem/go-grpc-Middleware
`grpc_middleware` is a collection of gRPC middleware packages: interceptors, helpers and tools. gRPC is a fantastic RPC middleware, which sees a lot of adoption in the Golang world. However, the upstream gRPC codebase is relatively bare bones. This package, and most of its child packages provides commonly needed middleware for gRPC: client-side interceptors for retires, server-side interceptors for input validation and auth, functions for chaining said interceptors, metadata convenience methods and more. By default, gRPC doesn't allow one to have more than one interceptor either on the client nor on the server side. `grpc_middleware` provides convenient chaining methods Simple way of turning a multiple interceptors into a single interceptor. Here's an example for server chaining: These interceptors will be executed from left to right: logging, monitoring and auth. Here's an example for client side chaining: These interceptors will be executed from left to right: monitoring and then retry logic. The retry interceptor will call every interceptor that follows it whenever when a retry happens. Implementing your own interceptor is pretty trivial: there are interfaces for that. But the interesting bit exposing common data to handlers (and other middleware), similarly to HTTP Middleware design. For example, you may want to pass the identity of the caller from the auth interceptor all the way to the handling function. For example, a client side interceptor example for auth looks like: Unfortunately, it's not as easy for streaming RPCs. These have the `context.Context` embedded within the `grpc.ServerStream` object. To pass values through context, a wrapper (`WrappedServerStream`) is needed. For example:
- Homepage: https://github.com/grpc-ecosystem/go-grpc-Middleware
- Documentation: https://pkg.go.dev/github.com/grpc-ecosystem/go-grpc-Middleware#section-documentation
- Licenses: Apache-2.0
- Latest release: v1.4.0 (published over 1 year ago)
- Last Synced: 2024-11-09T00:31:36.067Z (1 day ago)
- Versions: 7
- Dependent Packages: 0
- Dependent Repositories: 0
-
Rankings:
- Stargazers count: 0.581%
- Forks count: 0.739%
- Average: 4.416%
- Dependent packages count: 6.999%
- Dependent repos count: 9.346%
go: github.com/grpc-ecosystem/go-grpc-middleware/providers/phuslog/v2
Package phuslog provides a small adapter required to use phuslog in logging gRPC middlewares. Please see examples for examples of use.
- Homepage: https://github.com/grpc-ecosystem/go-grpc-middleware
- Documentation: https://pkg.go.dev/github.com/grpc-ecosystem/go-grpc-middleware/providers/phuslog/v2#section-documentation
- Licenses: Apache-2.0
- Latest release: v2.0.0-rc.3 (published about 2 years ago)
- Last Synced: 2024-11-09T00:31:28.784Z (1 day ago)
- Versions: 1
- Dependent Packages: 0
- Dependent Repositories: 0
-
Rankings:
- Stargazers count: 0.581%
- Forks count: 0.739%
- Average: 4.416%
- Dependent packages count: 6.999%
- Dependent repos count: 9.346%
go: github.com/grpc-ecosystem/go-grpc-mIDdleware
`grpc_middleware` is a collection of gRPC middleware packages: interceptors, helpers and tools. gRPC is a fantastic RPC middleware, which sees a lot of adoption in the Golang world. However, the upstream gRPC codebase is relatively bare bones. This package, and most of its child packages provides commonly needed middleware for gRPC: client-side interceptors for retires, server-side interceptors for input validation and auth, functions for chaining said interceptors, metadata convenience methods and more. By default, gRPC doesn't allow one to have more than one interceptor either on the client nor on the server side. `grpc_middleware` provides convenient chaining methods Simple way of turning a multiple interceptors into a single interceptor. Here's an example for server chaining: These interceptors will be executed from left to right: logging, monitoring and auth. Here's an example for client side chaining: These interceptors will be executed from left to right: monitoring and then retry logic. The retry interceptor will call every interceptor that follows it whenever when a retry happens. Implementing your own interceptor is pretty trivial: there are interfaces for that. But the interesting bit exposing common data to handlers (and other middleware), similarly to HTTP Middleware design. For example, you may want to pass the identity of the caller from the auth interceptor all the way to the handling function. For example, a client side interceptor example for auth looks like: Unfortunately, it's not as easy for streaming RPCs. These have the `context.Context` embedded within the `grpc.ServerStream` object. To pass values through context, a wrapper (`WrappedServerStream`) is needed. For example:
- Homepage: https://github.com/grpc-ecosystem/go-grpc-mIDdleware
- Documentation: https://pkg.go.dev/github.com/grpc-ecosystem/go-grpc-mIDdleware#section-documentation
- Licenses: Apache-2.0
- Latest release: v1.4.0 (published over 1 year ago)
- Last Synced: 2024-11-09T00:31:23.311Z (1 day ago)
- Versions: 7
- Dependent Packages: 0
- Dependent Repositories: 0
-
Rankings:
- Stargazers count: 0.581%
- Forks count: 0.739%
- Average: 4.416%
- Dependent packages count: 6.999%
- Dependent repos count: 9.346%
go: github.com/grpc-ecosystem/go-grpc-middleware/providers/logrus/v2
Package logrus provides a small adapter required to use logrus in logging gRPC middlewares. Please see examples for examples of use.
- Homepage: https://github.com/grpc-ecosystem/go-grpc-middleware
- Documentation: https://pkg.go.dev/github.com/grpc-ecosystem/go-grpc-middleware/providers/logrus/v2#section-documentation
- Licenses: Apache-2.0
- Latest release: v2.0.0-rc.3 (published about 2 years ago)
- Last Synced: 2024-11-09T00:31:23.707Z (1 day ago)
- Versions: 1
- Dependent Packages: 0
- Dependent Repositories: 0
-
Rankings:
- Stargazers count: 0.581%
- Forks count: 0.739%
- Average: 4.416%
- Dependent packages count: 6.999%
- Dependent repos count: 9.346%
go: github.com/grpc-ecosystem/go-grpc-middleware/providers/logrus
Initialization shows a relatively complex initialization sequence.
- Homepage: https://github.com/grpc-ecosystem/go-grpc-middleware
- Documentation: https://pkg.go.dev/github.com/grpc-ecosystem/go-grpc-middleware/providers/logrus#section-documentation
- Licenses: Apache-2.0
- Latest release: (published 6 months ago)
- Last Synced: 2024-11-06T23:30:49.407Z (3 days ago)
- Versions: 0
- Dependent Packages: 0
- Dependent Repositories: 0
-
Rankings:
- Forks count: 0.739%
- Stargazers count: 0.783%
- Average: 4.467%
- Dependent packages count: 6.999%
- Dependent repos count: 9.346%
go: github.com/grpc-ecosystem/go-grpc-middleware/providers/kit
Initialization shows a relatively complex initialization sequence.
- Homepage: https://github.com/grpc-ecosystem/go-grpc-middleware
- Documentation: https://pkg.go.dev/github.com/grpc-ecosystem/go-grpc-middleware/providers/kit#section-documentation
- Licenses: Apache-2.0
- Latest release: (published 6 months ago)
- Last Synced: 2024-11-06T23:30:57.160Z (3 days ago)
- Versions: 0
- Dependent Packages: 0
- Dependent Repositories: 0
-
Rankings:
- Forks count: 0.739%
- Stargazers count: 0.783%
- Average: 4.467%
- Dependent packages count: 6.999%
- Dependent repos count: 9.346%
go: github.com/grpc-ecosystem/go-grpc-middleware/providers/zap
Package zap provides a small adapter required to use zap in logging gRPC middlewares. Please see examples for examples of use.
- Homepage: https://github.com/grpc-ecosystem/go-grpc-middleware
- Documentation: https://pkg.go.dev/github.com/grpc-ecosystem/go-grpc-middleware/providers/zap#section-documentation
- Licenses: Apache-2.0
- Latest release: (published 6 months ago)
- Last Synced: 2024-11-08T00:03:48.840Z (2 days ago)
- Versions: 0
- Dependent Packages: 0
- Dependent Repositories: 0
-
Rankings:
- Stargazers count: 0.895%
- Forks count: 1.038%
- Average: 4.803%
- Dependent packages count: 7.917%
- Dependent repos count: 9.361%
go: github.com/grpc-ecosystem/go-grpc-middleware/logging/zap/ctxzap
`ctxzap` is a ctxlogger that is backed by Zap It accepts a user-configured `zap.Logger` that will be used for logging. The same `zap.Logger` will be populated into the `context.Context` passed into gRPC handler code. You can use `ctxzap.Extract` to log into a request-scoped `zap.Logger` instance in your handler code. As `ctxzap.Extract` will iterate all tags on from `grpc_ctxtags` it is therefore expensive so it is advised that you extract once at the start of the function from the context and reuse it for the remainder of the function (see examples). Please see examples and tests for examples of use.
- Homepage: https://github.com/grpc-ecosystem/go-grpc-middleware
- Documentation: https://pkg.go.dev/github.com/grpc-ecosystem/go-grpc-middleware/logging/zap/ctxzap#section-documentation
- Licenses: Apache-2.0
- Latest release:
- Last Synced: 2024-11-05T23:01:15.664Z (4 days ago)
- Versions: 0
- Dependent Packages: 0
- Dependent Repositories: 0
-
Rankings:
- Dependent packages count: 6.151%
- Average: 6.357%
- Dependent repos count: 6.563%
go: github.com/grpc-ecosystem/go-grpc-middleware/util/backoffutils
Backoff Helper Utilities Implements common backoff features.
- Homepage: https://github.com/grpc-ecosystem/go-grpc-middleware
- Documentation: https://pkg.go.dev/github.com/grpc-ecosystem/go-grpc-middleware/util/backoffutils#section-documentation
- Licenses: Apache-2.0
- Latest release:
- Last Synced: 2024-11-09T00:31:32.138Z (1 day ago)
- Versions: 0
- Dependent Packages: 0
- Dependent Repositories: 0
-
Rankings:
- Dependent packages count: 6.151%
- Average: 6.357%
- Dependent repos count: 6.563%
go: github.com/grpc-ecosystem/go-grpc-middleware/util/metautils
- Homepage: https://github.com/grpc-ecosystem/go-grpc-middleware
- Documentation: https://pkg.go.dev/github.com/grpc-ecosystem/go-grpc-middleware/util/metautils#section-documentation
- Licenses: Apache-2.0
- Latest release:
- Last Synced: 2024-11-06T23:30:50.795Z (3 days ago)
- Versions: 0
- Dependent Packages: 0
- Dependent Repositories: 0
-
Rankings:
- Dependent packages count: 6.151%
- Average: 6.357%
- Dependent repos count: 6.563%
go: github.com/grpc-ecosystem/go-grpc-middleware/retry
`grpc_retry` provides client-side request retry logic for gRPC. It allows for automatic retry, inside the generated gRPC code of requests based on the gRPC status of the reply. It supports unary (1:1), and server stream (1:n) requests. By default the interceptors *are disabled*, preventing accidental use of retries. You can easily override the number of retries (setting them to more than 0) with a `grpc.ClientOption`, e.g.: Other default options are: retry on `ResourceExhausted` and `Unavailable` gRPC codes, use a 50ms linear backoff with 10% jitter. For chained interceptors, the retry interceptor will call every interceptor that follows it whenever a retry happens. Please see examples for more advanced use. Simple example of using the default interceptor configuration. Example with an exponential backoff starting with 100ms. Each next interval is the previous interval multiplied by 2. Complex example with a 100ms linear backoff interval, and retry only on NotFound and Unavailable. Simple example of an idempotent `ServerStream` call, that will be retried automatically 3 times.
- Homepage: https://github.com/grpc-ecosystem/go-grpc-middleware
- Documentation: https://pkg.go.dev/github.com/grpc-ecosystem/go-grpc-middleware/retry#section-documentation
- Licenses: Apache-2.0
- Latest release:
- Last Synced: 2024-11-05T23:01:17.917Z (4 days ago)
- Versions: 0
- Dependent Packages: 0
- Dependent Repositories: 0
-
Rankings:
- Dependent packages count: 6.151%
- Average: 6.357%
- Dependent repos count: 6.563%
go: github.com/grpc-ecosystem/go-grpc-middleware/logging/settable
grpc_logsettable contains a thread-safe wrapper around grpc-logging infrastructure. The go-grpc assumes that logger can be only configured once as the `SetLoggerV2` method is: ```Not mutex-protected, should be called before any gRPC functions.``` This package allows to supply parent logger once ("before any grpc"), but later change underlying implementation in thread-safe way when needed. It's in particular useful for testing, where each testcase might need its own logger.
- Homepage: https://github.com/grpc-ecosystem/go-grpc-middleware
- Documentation: https://pkg.go.dev/github.com/grpc-ecosystem/go-grpc-middleware/logging/settable#section-documentation
- Licenses: Apache-2.0
- Latest release:
- Last Synced: 2024-11-05T23:01:18.927Z (4 days ago)
- Versions: 0
- Dependent Packages: 0
- Dependent Repositories: 0
-
Rankings:
- Dependent packages count: 6.151%
- Average: 6.357%
- Dependent repos count: 6.563%
go: github.com/grpc-ecosystem/go-grpc-middleware/logging
grpc_logging is a "parent" package for gRPC logging middlewares. The gRPC logging middleware populates request-scoped data to `grpc_ctxtags.Tags` that relate to the current gRPC call (e.g. service and method names). Once the gRPC logging middleware has added the gRPC specific Tags to the ctx they will then be written with the logs that are made using the `ctx_logrus` or `ctx_zap` loggers. All logging middleware will emit a final log statement. It is based on the error returned by the handler function, the gRPC status code, an error (if any) and it will emit at a level controlled via `WithLevels`. This particular package is intended for use by other middleware, logging or otherwise. It contains interfaces that other logging middlewares *could* share . This allows code to be shared between different implementations. All field names of loggers follow the OpenTracing semantics definitions, with `grpc.` prefix if needed: https://github.com/opentracing/specification/blob/master/semantic_conventions.md There are three implementations at the moment: logrus, zap and kit See relevant packages below.
- Homepage: https://github.com/grpc-ecosystem/go-grpc-middleware
- Documentation: https://pkg.go.dev/github.com/grpc-ecosystem/go-grpc-middleware/logging#section-documentation
- Licenses: Apache-2.0
- Latest release:
- Last Synced: 2024-11-08T00:03:45.167Z (2 days ago)
- Versions: 0
- Dependent Packages: 0
- Dependent Repositories: 0
-
Rankings:
- Dependent packages count: 6.151%
- Average: 6.357%
- Dependent repos count: 6.563%
go: github.com/grpc-ecosystem/go-grpc-middLeware/v2
- Homepage:
- Documentation: https://pkg.go.dev/github.com/grpc-ecosystem/go-grpc-middLeware/v2#section-documentation
- Licenses: apache-2.0
- Latest release: v2.1.0 (published 9 months ago)
- Last Synced: 2024-11-09T00:31:34.013Z (1 day ago)
- Versions: 8
- Dependent Packages: 0
- Dependent Repositories: 0
-
Rankings:
- Dependent packages count: 6.956%
- Average: 7.401%
- Dependent repos count: 7.846%
go: github.com/grpc-ecosystem/go-grpc-middLeware
`grpc_middleware` is a collection of gRPC middleware packages: interceptors, helpers and tools. gRPC is a fantastic RPC middleware, which sees a lot of adoption in the Golang world. However, the upstream gRPC codebase is relatively bare bones. This package, and most of its child packages provides commonly needed middleware for gRPC: client-side interceptors for retires, server-side interceptors for input validation and auth, functions for chaining said interceptors, metadata convenience methods and more. By default, gRPC doesn't allow one to have more than one interceptor either on the client nor on the server side. `grpc_middleware` provides convenient chaining methods Simple way of turning a multiple interceptors into a single interceptor. Here's an example for server chaining: These interceptors will be executed from left to right: logging, monitoring and auth. Here's an example for client side chaining: These interceptors will be executed from left to right: monitoring and then retry logic. The retry interceptor will call every interceptor that follows it whenever when a retry happens. Implementing your own interceptor is pretty trivial: there are interfaces for that. But the interesting bit exposing common data to handlers (and other middleware), similarly to HTTP Middleware design. For example, you may want to pass the identity of the caller from the auth interceptor all the way to the handling function. For example, a client side interceptor example for auth looks like: Unfortunately, it's not as easy for streaming RPCs. These have the `context.Context` embedded within the `grpc.ServerStream` object. To pass values through context, a wrapper (`WrappedServerStream`) is needed. For example:
- Homepage: https://github.com/grpc-ecosystem/go-grpc-middLeware
- Documentation: https://pkg.go.dev/github.com/grpc-ecosystem/go-grpc-middLeware#section-documentation
- Licenses: Apache-2.0
- Latest release: v1.4.0 (published over 1 year ago)
- Last Synced: 2024-11-09T00:31:26.687Z (1 day ago)
- Versions: 7
- Dependent Packages: 0
- Dependent Repositories: 0
-
Rankings:
- Dependent packages count: 6.956%
- Average: 7.401%
- Dependent repos count: 7.846%
go: github.com/grpc-ecosystem/go-grpc-mIddleware
`grpc_middleware` is a collection of gRPC middleware packages: interceptors, helpers and tools. gRPC is a fantastic RPC middleware, which sees a lot of adoption in the Golang world. However, the upstream gRPC codebase is relatively bare bones. This package, and most of its child packages provides commonly needed middleware for gRPC: client-side interceptors for retires, server-side interceptors for input validation and auth, functions for chaining said interceptors, metadata convenience methods and more. By default, gRPC doesn't allow one to have more than one interceptor either on the client nor on the server side. `grpc_middleware` provides convenient chaining methods Simple way of turning a multiple interceptors into a single interceptor. Here's an example for server chaining: These interceptors will be executed from left to right: logging, monitoring and auth. Here's an example for client side chaining: These interceptors will be executed from left to right: monitoring and then retry logic. The retry interceptor will call every interceptor that follows it whenever when a retry happens. Implementing your own interceptor is pretty trivial: there are interfaces for that. But the interesting bit exposing common data to handlers (and other middleware), similarly to HTTP Middleware design. For example, you may want to pass the identity of the caller from the auth interceptor all the way to the handling function. For example, a client side interceptor example for auth looks like: Unfortunately, it's not as easy for streaming RPCs. These have the `context.Context` embedded within the `grpc.ServerStream` object. To pass values through context, a wrapper (`WrappedServerStream`) is needed. For example:
- Homepage: https://github.com/grpc-ecosystem/go-grpc-mIddleware
- Documentation: https://pkg.go.dev/github.com/grpc-ecosystem/go-grpc-mIddleware#section-documentation
- Licenses: Apache-2.0
- Latest release: v1.4.0 (published over 1 year ago)
- Last Synced: 2024-11-09T00:31:38.542Z (1 day ago)
- Versions: 7
- Dependent Packages: 0
- Dependent Repositories: 0
-
Rankings:
- Dependent packages count: 6.999%
- Average: 8.173%
- Dependent repos count: 9.346%
go: github.com/grpc-ecosystem/go-grpc-middleware/examples/v2
- Homepage: https://github.com/grpc-ecosystem/go-grpc-middleware
- Documentation: https://pkg.go.dev/github.com/grpc-ecosystem/go-grpc-middleware/examples/v2#section-documentation
- Licenses: Apache-2.0
- Latest release: (published 6 months ago)
- Last Synced: 2024-11-08T00:03:50.306Z (2 days ago)
- Versions: 0
- Dependent Packages: 0
- Dependent Repositories: 0
-
Rankings:
- Dependent packages count: 8.859%
- Average: 9.424%
- Dependent repos count: 9.989%
Dependencies
- github.com/go-kit/log v0.1.0
- github.com/gogo/protobuf v1.3.2
- github.com/golang/protobuf v1.3.3
- github.com/opentracing/opentracing-go v1.1.0
- github.com/sirupsen/logrus v1.4.2
- github.com/stretchr/testify v1.7.0
- go.uber.org/zap v1.18.1
- golang.org/x/net v0.0.0-20201021035429-f5854403a974
- golang.org/x/oauth2 v0.0.0-20180821212333-d2e6202438be
- golang.org/x/sys v0.0.0-20211025201205-69cdffdb9359
- google.golang.org/genproto v0.0.0-20200423170343-7949de9c1215
- google.golang.org/grpc v1.29.1
- 108 dependencies