gogoprotobuf
nsq
Our great sponsors
gogoprotobuf | nsq | |
---|---|---|
8 | 14 | |
5,629 | 24,561 | |
0.2% | 0.6% | |
0.0 | 6.3 | |
9 months ago | 2 days ago | |
Go | Go | |
GNU General Public License v3.0 or later | MIT License |
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.
gogoprotobuf
-
Why Does gRPC Insist on Trailers?
That probably won't happen either, because the Google gRPC team is also quite resistant to any kind of change (that isn't driven by internal needs at Google). Projects like GoGo Protobuf had to be developed to fill gaps that the Google team refused to fill or accept PRs for.
-
Anyone needs a (long-term) contributor for their open source project written in Go?
the gogo protobuf compiler toolchain is looking for a maintainer https://github.com/gogo/protobuf u/MehdiHK
-
Distributed IM Service in Golang
protobuff : Google's binary data transfer protocol
-
Crowdstrike releases replacement for Gogo/protobuf
Looks like Crowdstrike just pushed out publicly a replacement for gogo/proto. It looks like the library solves 2 problems:
-
2022-01-11 gRPC benchmark results
Seems like we're pretty middle of the road. I can only guess as to why but it probably has to do with heavy usage of pointers and reflection. Gogo/protobuf solved this performance with code generation, but the go protobuf implementation has essentially eschewed it. I do wonder how the benchmark would look using the new vitess proto library for Go (which has many of the benefits of gogo but with active development and an API built on top of the Google one)
-
Go-generated protobufs with map[string]interface{}
Yeah, it's a pretty thick Makefile and set of shell scripts, but it's seemingly using things like: k8s.io/code-generator/cmd/go-to-protobuf and github.com/gogo/protobuf/protoc-gen-gogo and github.com/gogo/protobuf/protoc-gen-gogofast which from what I can tell... [it looks like this can probably help me a bit in understanding how to make custom types](https://cloud.redhat.com/blog/kubernetes-deep-dive-code-generation-customresources).
-
🐱👓 PowerProto: One-click installation and version control of gRPC toolchain (protoc, protoc-gen-go)
repositories: # Definition depends on the 27156597fdf4fb77004434d4409154a230dc9a32 version of https://github.com/googleapis/googleapis # and defines its name as GOOGLE_APIS # It can be referenced in importPaths by $GOOGLE_APIS GOOGLE_APIS: https://github.com/googleapis/googleapis@27156597fdf4fb77004434d4409154a230dc9a32 # Definition depends on the 226206f39bd7276e88ec684ea0028c18ec2c91ae version of https://github.com/gogo/protobuf # and defines its name as GOGO_PROTOBUF # It can be referenced in the importPaths by $GOGO_PROTOBUF GOGO_PROTOBUF: https://github.com/gogo/protobuf@226206f39bd7276e88ec684ea0028c18ec2c91ae
-
Обережно кодогенерація
В проекті ми використовуємо офіційну бібліотеку Protobuf github.com/protocolbuffers/protobuf, яка підчас серіалізації використовує рефлексію і будує слайс байтів через append. А потім я дізнався про "Protocol Buffers for Go with Gadgets" github.com/gogo/protobuf, бібліотеку-fork яка генерує додатковий код щоб прибрати рефексію підчас серіалізації і вже записує в слайс байтів по індексу бо так швидше. Коли змінював одну бібліотеку на іншу то важливим вважав що стало працювати швидше і написані раніше тести пройшли успішно. І все б було гаразд але в проекті існувала латка яка через пару тижнів після заміни перезапустила мікросервіс через паніку:
nsq
- NSQ: Open-source realtime distributed messaging, billions of messages / day
-
MQTT vs. Kafka: An IoT Advocate's Perspective
Interesting. What are you thoughts on NSQ?
https://github.com/nsqio/nsq
Was looking at it earlier today, but haven't ever tried it out.
-
Any thoughts on using Redis to extend Go's channels across application / machine boundaries?
(G)NATS can do millions of messages per second and is the right tool for the job (either that or NSQ). Redis isn't even the fastest Redis protocol implementation, KeyDB significantly outperforms it.
-
FileWave: Why we moved from ZeroMQ to NATS
Bit.ly's NSQ is also an excellent message queue option.
-
Infinite loop pattern to poll for a queue in a REST server app
Queue consumers are interesting because there are many solutions for them, from using Redis and persisting the data in a data store - but for fast and scalable the approach I would take is something like SQS (as I advocate AWS even free tier) or NSQ for managing your own distributed producers and consumers.
- NSQ – A realtime distributed messaging platform
-
What are pros and cons of Go?
distrubition server engine ( for example websocket server multi ws gateway and worker pool,nsq.io realtime message queue and so on)
- Nsq - A realtime distributed messaging platform
- Is there any conventionally accepted repo that is representative of well designed go code ?
- NSQ: A realtime distributed messaging platform
What are some alternatives?
asn1
NATS - Golang client for NATS, the cloud native messaging system.
colfer - binary serialization format
NATS - High-Performance server for NATS.io, the cloud and edge native messaging system.
goprotobuf - Go support for Google's protocol buffers
RabbitMQ - Open source RabbitMQ: core server and tier 1 (built-in) plugins
easyjson - Fast JSON serializer for golang.
Apache Kafka - Mirror of Apache Kafka
mapstructure - Go library for decoding generic map values into native Go structures and vice versa.
ZeroMQ - ZeroMQ core engine in C++, implements ZMTP/3.1
go-capnproto - Cap'n Proto library and parser for go. This is go-capnproto-1.0, and does not have rpc. See https://github.com/zombiezen/go-capnproto2 for 2.0 which has rpc and capabilities.
etcd - Distributed reliable key-value store for the most critical data of a distributed system