La mise en œuvre du produit (Rails) qui est en charge du PM dans l'entreprise doit obtenir des informations d'autres services, et comme ce service n'était pas OpenAPI mais que l'interface API a été définie par gRPC, implémentez le client gRPC Fait. Comme je touchais un peu au gRPC dans les rails dans mon travail précédent, je pensais que cela augmenterait relativement l'effort de développement de l'équipe si je le faisais, alors j'ai décidé de le faire moi-même. La sortie à ce sujet.
Gemfile
gem "google-protobuf"
gem "grpc-tools"
gem "gruf"
docker-compose run --rm web bundle install
$ git submodule add [web URL or ssh key] proto
$ git submodule init
$ cd proto
$ git submodule update
docker-compose run --rm web grpc_tools_ruby_protoc -I [Répertoire Proto à compiler] --ruby_out=[Répertoire dans lequel les fichiers sont enregistrés après la compilation] --grpc_out=[Répertoire dans lequel les fichiers sont enregistrés après la compilation] [Répertoire Proto à compiler内の対象ファイル]
Après la compilation, le nom du fichier et le nom de la classe ne se mesurent pas l'un à l'autre, il ne suit pas les règles de chargement de Rails et n'est pas automatiquement chargé, vous devez donc le spécifier.
config/initializers/gruf.rb
require "gruf"
Gruf.configure do
Dir.glob(Rails.root.join("[Répertoire dans lequel les fichiers sont enregistrés après la compilation]/*_pb.rb")).each do |file|
require file
end
end
Dans le fichier compilé, il est automatiquement spécifié comme indiqué ci-dessous, et il est nécessaire de l'ajouter à ʻauto_load_path. Par exemple, [gruf-demo](https://github.com/bigcommerce/gruf-demo/blob/master/app/rpc/app/proto/Products_services_pb.rb)
require 'Products_pb'`
config/application.rb
class Application < Rails::Application
config.paths.add [Répertoire de fichiers Ruby après compilation], eager_load: true
end
À ce stade, tous les fichiers ruby compilés sont désormais disponibles pour l'implémentation client.
J'étais inquiet de savoir s'il fallait utiliser un module, mais dans l'implémentation existante, le traitement lié au client était intégré dans la couche de service, j'ai donc décidé de le suivre cette fois également.
Gruf :: Client.new
) J'étais un peu inquiet car cette zone est différente de cette implémentation, comme la saisie de ʻusername avec la clé de l'argument ʻoptions
de.app/services/grpc_client_service.rb
class GrpcClientService
def initialize
@metadata = {
login: ENV["GRPC_CLIENT"],
password: ENV["GRPC_PASSWORD"]
}
end
def run(service_klass, method, request)
client = Gruf::Client.new(
service: service_klass,
options: {
hostname: ENV["GRPC_HOST"],
channel_credentials: :this_channel_is_insecure
}
)
client.call(method, request.to_h, @metadata)
end
end
J'ai utilisé gruf dans mon travail précédent, alors je pensais que je pouvais me le permettre, mais je pensais que ce serait très différent de simplement l'utiliser. Je regrette d'avoir dû lire le code autour des paramètres.
De plus, cette fois, le serveur gRPC a été écrit en go, et lorsque l'appel du client ne s'est pas bien passé, j'ai eu du mal à lire le code et j'ai finalement abandonné, donc j'ai voulu étudier go aussi.
De plus, je suis resté un peu coincé parce que j'avais mal compris que j'avais mis metadata
au moment de l'initialisation du client ( Gruf :: Client.new
) (en fait je l'ai mis dans l'argument à l'appel), donc je l'ai écrit dans la bibliothèque Wiki Après tout, j'ai réalisé une fois de plus que c'était une chose rudimentaire que je devais lire le code fermement.
Recommended Posts