search

fatih / twirpdemo

An example repository of using the Twirp RPC framework with Go
MIT License
33 stars 4 forks source link

Question about Twirp and gRPC #1

Closed huseyinbabal closed 2 years ago

huseyinbabal commented 2 years ago

Thanks for the demo first 🏅 . I have a couple of questions about twirp and demo as follows;

  1. Let say that I am building a public API and generating clients for multiple languages. Is it possible to skip the client generation part for twirp, since I don't want to maintain the client part in the related service implementation folder?
  2. This is partially related to question#1. Client generation seems practical in terms of consuming it on other services, e.g. product service uses customer service client to consume customer endpoints. If you are in a monorepo, do you directly use customer service client in product service by accessing that package? Or you are using replace directive within your productservice/go.mod file?
  3. You can ignore this if you are not using dedicated repo for your microservices. Do you generate a client within the service repo and tag it as client/v1.9.1 and use something like github.com/fatih/customerservice client/v1.9.1 in your product service go mod file?
  4. Have you ever thought to maintain your proto files in a separate repo so that with a simple GitHub action, you can generate lang-specific grpc implementations and use them as a dependency in any client project? e.g. https://github.com/huseyinbabal/demory-proto
  5. Do you think, tracing and observability are easy within twirp? Any plug-and-play integration so that my correlation ids can be autogenerated and passed between services.

Thanks in advance

fatih commented 2 years ago

Hi @huseyinbabal

Thanks for the questions. Let me answer them:

  1. I don't think there is any option you can pass to skip Client generation: https://github.com/twitchtv/twirp/tree/main/protoc-gen-twirp But you could write a Tool yourself to strip that part if it's important. I probably wouldn't deal with it/
  2. We directly import the generated package and the clients. For monorepo it's easy, for poly repos, our Twirp proto files and generated code lives in a separate repo, i.e: github.com/company/service-proto. This repository includes the Go and Rails code.
  3. See 2. We don't use semver, and use Git SHA directly. It's very difficult to maintain semver between services, so we just do go get github.com/company/service-proto/go@git_sha
  4. Yeap, see 2, both at GitHub and PlanetScale, we have several different repositories, so if we have a service that is consumed by others, we put it inside a separate repository.
  5. It's very easy via hooks. Here is a package for OpenTracing: https://github.com/twirp-ecosystem/twirp-opentracing You can apply the same principles for OpenTelemetry specific projects.
huseyinbabal commented 2 years ago

Thank you for your time and valuable answers 🙏