grpc-spring-boot-starter icon indicating copy to clipboard operation
grpc-spring-boot-starter copied to clipboard

Collaboration on shareable grpc-spring-boot-starter features

Open ST-DDT opened this issue 3 years ago • 5 comments

Hi I'm ST-DDT (Core Developer of yidongnan/grpc-spring-boot-starter).

I noticed, that we both implement similar features for both of our libraries, so I would like to propose a collaboration on those features in an independent (github) organization. For the sake of discussion lets call it grpc-spring for now.

This organization would host repositories for features that could be beneficial for both our projects (and also others). For a start I considered these features:

  • Security/Authentication/Authorisation (Server + some client parts, if applicable)
  • ExceptionHandling (annotation driven; Server)
  • Spring-Cloud Discovery NameResolverProvider (Client)
  • Spring-Cloud Discovery Service registration (Server)
  • spring-boot-grpc-java-bom (Optional, maybe for our own use)
  • (I'm open for suggestions)

(+ related documentation)

These libraries should hopefully not require spring boot or at least keep it optional.

I don't care who the owner is, but I would like to keep the group id different from both our projects (to not promote one or the other). Maybe org.grpc_spring?

What I wish to achieve with this organization:

  • Reduce code duplication
  • Keep documentation for shared features in a central place (+maybe explicit permission to reuse/embed it in both our projects)
  • Increase the code usage (more frequently used => less bugs + more features)
    • This includes 3p libraries and frameworks
  • Provide others with the option to share their grpc-spring code (e.g. grpc-spring-security-keycloak)
  • (Optional) Bring both our projects closer together (and maybe merge them in the far future)

Non goals:

  • Copy one's project to the organization, discarding the other
  • Adding annotations for/dependencies to either of our projects

What do you think of my proposal?

ST-DDT avatar Jan 17 '21 21:01 ST-DDT

Thanks for reaching out, @ST-DDT . I wonder how you imagine two starters built on one shared core library. What will differentiate them ?

jvmlet avatar Jan 21 '21 15:01 jvmlet

There wouldnt be a "core" library. The would be multiple feature libraries. There are plenty of features that will only be present in our indivual libraries. Such as server/client creation/configuration, interceptors...

Maybe those will at some point be moved over, but then the org should have gained a solid foundation and would replace the existing projects, but that is probably in the far future, if at all. Having two projects for the same task is probably non-optimal.

At the time I joined the grpc development, also considered joining this project, but its focus was on being lightweight server only. And I needed client support for my work. I still keep an eye open on this project (e.g. security/auth issues), but my job forces me to keep the other one updated. Since I cannot drop my project and I dont want to request you to drop yours, I would still like to join forces on some features. Together we are strong enough to establish standards for grpc-spring.

Another reason is that I get proposals for grpc-spring features, that quite dont fit into a grpc-spring-boot-starter. If we would join forces in a grpc-spring orga, then those projects would automatically gain a good place.

ST-DDT avatar Jan 21 '21 17:01 ST-DDT

@ST-DDT, As a first step in collaboration efforts you are welcome to support this proposal by voting up.

jvmlet avatar Jan 29 '21 06:01 jvmlet

In lieu of this, I have created a PR to port over the GrpcRequestScope in yidongnan/grpc-spring-boot-starter done by @ST-DDT (https://github.com/yidongnan/grpc-spring-boot-starter/pull/259)

@ST-DDT are you ok with this being ported over and can you take a look if possible? https://github.com/LogNet/grpc-spring-boot-starter/pull/198

bherrmann2 avatar Apr 09 '21 15:04 bherrmann2

Well, my original idea behind the collaboration was to prevent this from being necessary... I'm fine with you porting this feature over. It would be nice, if you could add a (by @ST-DDT) to the PR description after the PR reference though. That way I get notified, that others consider it useful and am able to notify you, if I ever find a bug in "my" code.

ST-DDT avatar Apr 11 '21 12:04 ST-DDT