Die Implementierung des für PM zuständigen Produkts (Rails) im Unternehmen muss Informationen von anderen Diensten abrufen. Da dieser Dienst nicht OpenAPI war, sondern die API-Schnittstelle von gRPC definiert wurde, implementieren Sie den gRPC-Client Hat. Da ich mich in meinem vorherigen Job ein wenig mit gRPC in Schienen beschäftigt habe, dachte ich, dass dies den Entwicklungsaufwand des Teams relativ erhöhen würde, wenn ich es tun würde, also entschied ich mich, es selbst zu tun. Die Ausgabe darüber.
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 [Proto-Verzeichnis, das kompiliert werden soll] --ruby_out=[Verzeichnis, in dem Dateien nach dem Kompilieren gespeichert werden] --grpc_out=[Verzeichnis, in dem Dateien nach dem Kompilieren gespeichert werden] [Proto-Verzeichnis, das kompiliert werden soll内の対象ファイル]
Nach dem Kompilieren greifen der Dateiname und der Klassenname nicht ineinander und folgen nicht den Rails-Laderegeln und werden nicht automatisch geladen. Sie müssen sie daher angeben.
config/initializers/gruf.rb
require "gruf"
Gruf.configure do
Dir.glob(Rails.root.join("[Verzeichnis, in dem Dateien nach dem Kompilieren gespeichert werden]/*_pb.rb")).each do |file|
require file
end
end
In der kompilierten Datei wird sie automatisch wie unten gezeigt angegeben und muss zu "auto_load_path" hinzugefügt werden.
Aus z. B. gruf-demo
require 'Products_pb'
config/application.rb
class Application < Rails::Application
config.paths.add [Ruby-Dateiverzeichnis nach der Kompilierung], eager_load: true
end
Zu diesem Zeitpunkt sind alle kompilierten Ruby-Dateien für die Client-Implementierung verfügbar.
Ich war besorgt darüber, ob ich ein Modul verwenden sollte, aber in der vorhandenen Implementierung war die clientbezogene Verarbeitung in die Service-Schicht integriert, sodass ich mich entschied, diesmal auch diesem zu folgen.
Gruf :: Client.new
) Ich war ein wenig besorgt, weil sich dieser Bereich von dieser Implementierung unterscheidet, z. B. das Einfügen von "Benutzername" in den Schlüssel des Arguments "Optionen" von.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
Ich habe Gruf in meinem vorherigen Job verwendet, also dachte ich, ich könnte es mir leisten, aber ich dachte, es wäre ganz anders, als es nur zu benutzen. Ich bedauere, dass ich den Code um die Einstellungen hätte lesen sollen.
Auch dieses Mal wurde der gRPC-Server in go geschrieben, und als der Anruf vom Client nicht gut lief, fiel es mir schwer, den Code zu lesen, und ich gab schließlich auf, also wollte ich auch go lernen.
Außerdem blieb ich ein wenig stecken, weil ich falsch verstanden habe, dass ich zum Zeitpunkt der Client-Initialisierung "Metadaten" ("Gruf :: Client.new") eingegeben habe (eigentlich habe ich sie in das Argument beim Aufruf eingefügt), also habe ich sie in das Bibliotheks-Wiki geschrieben Immerhin wurde mir wieder klar, dass es eine rudimentäre Sache ist, den Code fest zu lesen.
Recommended Posts