New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gRPC as default client/server #2331
Comments
@xpunch thoughts? |
grpc seams to be the most popular rpc framework in go, but move the default server & client to grpc will make a breaking change. The simplest way is move grpc plugins into go-micro, then set the default server and client to grpc like go-micro v2. |
You're sort of arguing points I've argued before but I found gRPC became the sort of defacto standard wire format for RPC and if thats what go-micro is maybe it should support that. The v2 implementation with defaults was a bit clunky. I think gRPC not honouring the transport is fine, but its also a design construct of go-micro v0 and it should be ok to evolve and let go of things if it makes sense. Being truly transport agnostic is nice but only if the design supports proper scalability and I guess maybe multi-transport support. There is the potential for redesign of the client/server to strip and separate PubSub from it. We're separately having a discussion in another issue about moving beyond protobuf and gRPC but it might be a v5 or beyond thing. I'm mostly just interested to see that we're serving the needs of people using go-micro. If the majority are in favour of gRPC then we should pursue it, if not and they prefer a transport agnostic system then we go in that direction. Go Micro has the potential to be completely agnostic of these things and more powerful in the long term. HTTP => gRPC => Web3???? |
Currently go-micro works fine in my projects, the architecture is flexible enough to support all my needs. Some of my services is running under go-micro v2 and v3, and I'm going to upgrade new services into v4. The reason why I'm willing to upgrade with go-micro is the communication between services is compatible. So it'll be fine to have breaking changes or evolution if it can still works with my old services(just my personal option).
|
I have only used go-micro a little, but used GRPC quite a bit with golang and other languages. I dont like grpc because grpc-web is too restrictive. GPRC has this create schema evolution story, so that old clients can do IO with newer severs. GRPC does have async but its not that nice. Protobufs and flatbuffers are just the serialisation without the transport and so gives you the best of both worlds. JsonSchema is basically what openAPI3.2. In other works openapi is a extension of jsonschema. You can do sync and asyn with openapi, jsonschema. checkout this ! like all technical opinions it depends what you want the platform for !! I quite like the general design thrust of the examples and the events system. Events uses gorilla web sockets which is a shame cause i cant compile to my go-micro golang clients to wasm, where as with https://pkg.go.dev/nhooyr.io/websocket its easy. Also nats now has websockets and full cache and bucket store. Definitely replaces redis and etcd. Not quite postresql, but there is always genji. another way is to use NATS as the transport, because its got load balancing, fault tolerance, built in security, clustering, leaf nodes and hence shards, and can use tcp or websockets. |
https://github.com/google/tarpc
I found that really interesting |
In my use case, I use grpc as replacement of REST API in mobile development, and default transport for micro service on server side. |
No compilation. I like it. But its rust not golang. there are ways to hook up golang to rust apparently. |
Its not about using tarpc, its about taking the idea of having something defined without the use of proto |
@asim https://github.com/smallnest/rpcx is pure golang and the schema is the go code. the team writing tarpc,compare it rpcx here: google/tarpc#224 I have not had a chance to try either yet though. rpcx supports QUIC though :) |
tooling seems ok too... |
Ok now i get it... |
We need to make a decision on this. @xpunch I'm thinking we strip Publish from Client and Subscribe from Server. Rip out the mucp implementation and transport package. Default to gRPC. Call it a v4.5.0 despite the breakage. Maybe even think about making the service routing dns based if that makes more sense for new environments aka kubernetes. |
If we are going to make breaking changes, then it should be v5. Usually, X.Y.Z means Major.Minor.Patch, v4 users should be OK to upgrade to latest v4 smoothly. |
Anyone interested in gRPC becoming the default client/server? It seems like most people adopt it and potentially makes sense to be the default.
The text was updated successfully, but these errors were encountered: