Skip to content
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

[feature] Move grpc client from internal to pkg #871

Open
DivPro opened this issue Aug 6, 2024 · 5 comments
Open

[feature] Move grpc client from internal to pkg #871

DivPro opened this issue Aug 6, 2024 · 5 comments

Comments

@DivPro
Copy link

DivPro commented Aug 6, 2024

I think we should move generation results from
https://github.com/centrifugal/centrifugo/tree/master/internal/apiproto

to https://github.com/centrifugal/centrifugo/tree/master/pkg/client

and change the docs

It will be useful to avoid unnesessary grpc client generation in projects, and just import client package from this repo.
Now, we don't have this opportunity when generated code has been placed at internal subdirectory

@FZambia
Copy link
Member

FZambia commented Aug 6, 2024

Hello @DivPro,

I think recent integration with Buf registry solves this (example for Go is here), and not only for Go, but for other languages too.

@DivPro
Copy link
Author

DivPro commented Aug 7, 2024

Hi, @FZambia

Yes, BSR is a good choice for some projects. But it's restricted in some countries by politic reasons (in Russia too) - and BSR access becomes a difficult task for CI/CD. Also it's a kind of vendor lock by Buf project itself, despite the compiler is open sourced. Hovewer, without BSR we have a choice between old raw protoc and modern buf compiler.
So, when we have limited access to BSR more people will prefer self-compiling via protoc, and it becomes unnesessary trouble when we simple can import precompiled package from this repo with go import

@FZambia
Copy link
Member

FZambia commented Aug 8, 2024

I see, though I don't really want developers to depend on Centrifugo repo directly to get Protobuf generated code. It may be problematic from dependency management in the future, Centrifugo is a complex project, and I'd like to keep it free from being a dependency of other Go projects.

To me a better way is to have a separate repo with a simple Makefile to load Centrifugo actual Protobuf schema file and generate code from it. This package may be re-used from other Go projects. You can make such package yourself and probably make it OSS if you want. Maybe we can introduce such package later inside centrifugal organization.

One other thing to mention, apiproto package is not ready to be exposed to public – it has more entities which should stay internal, so from this perspective making a separate package only for Protobuf generated code makes more sense to me also.

@DivPro
Copy link
Author

DivPro commented Aug 8, 2024

@FZambia Theank you, so let's think about a separate repo like https://github.com/centrifugal/gocent but for grpc

How can we synk it with source? Any github features(for CI) may be? And definition git tags synk

@FZambia
Copy link
Member

FZambia commented Aug 9, 2024

How can we synk it with source? Any github features(for CI) may be? And definition git tags synk

Probably a periodic GH Actions job and comparing api.proto file in the repo with file in upstream with automatic PR in case of changes could do the job. I think there are also GH actions dispatch hooks on file change, but I have not digged deeper. But I suppose the initial implementation may be a manual make command which downloads api.proto and re-generates code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
2 participants