search

micro / go-micro

A Go microservices framework
https://go-micro.dev
Apache License 2.0
21.84k stars 2.35k forks source link

[FEATURE] eliminate the protoc generator #2279

Closed asim closed 2 months ago

asim commented 3 years ago

The protoc generator was a bit of a hack. It would be nice to eliminate this in favour of a built in generator based on templates in the Micro CLI.

AuditeMarlow commented 2 years ago

What exactly is it that you had in mind? Get rid of the generator completely and instead build templates for the Micro CLI with conditionals based on the proto?

asim commented 2 years ago

Yea basically the proto generator is a fork of the one for grpc. If we do this in pure Go with templates it might be better for long term changes. It might also facilitate separation from protobuf in the future.

AuditeMarlow commented 2 years ago

I'm having trouble picturing this still. I suppose the Micro CLI generated file should not reside in proto, but elsewhere considering it will in fact not be a protobuf generated file. I also want to prevent Micro CLI generated projects from being polluted with packages that are not protobuf generated users should not edit. I have witnessed this pattern in Kratos and I can't say I was thrilled to be met with stuff I shouldn't be touching or should've otherwise be abstracted away in the framework itself.

In contrast we can still bundle protobuf and Micro CLI generated files under the same package, but should most likely be named differently than proto. That also begs the question, do we want Micro CLI to mimic protoc-gen-micro's generated file, or should we consider a different approach altogether?

asim commented 2 years ago

I think it's an opportunity to diverge and learn from the past. Go Micro started out with no code generation. Back then gRPC didn't exist and so there was no concept of a "Service" in protobuf, or at least no code generator for it. When gRPC came about I adapted the code to reduce boilerplate for Go Micro but effectively I think it's not the greatest developer experience, more a byproduct of Google's internal tooling.

Ideally Go Micro is Go first, meaning built entirely on Go and the Go interfaces. Go includes a go generate command which is what they advocate for with code generation (see blog post https://go.dev/blog/generate). I think we could potentially define services in pure Go and generate whatever's necessary with pure Go as a sort of breakaway from protobuf and an advancement on a better dev UX.

It's all initial thoughts but I always imagined as Go Micro went from v1 to v10, it would leave behind past things. As in, the first rpc client/server was hand crafted on top of http 1.0. The next used code generation via protobuf, then gRPC and removed the need for the transport interface. Future versions might move beyond gRPC and in those cases I could imagine not needing protobuf e.g maybe its pure json, maybe its flatbuffers, or whatever other thing comes about.

The same goes for the broker and related interfaces. The broker was hacked as a point to point http solution. I could imagine a very that's using gossip and raft or just bakes in nats as we tried in v2. Lots of different possibilities.

bhoriuchi commented 2 years ago

Any thoughts on potentially using openapi spec to define the configuration that drives the code generation? It's extensible and the type/service/client generation could be pluggable to use notype, protobuf, etc