概要 gRPCを使用して、Go、Node.jsのプログラム間でRPC通信をします。 クライアント側をGo、サーバ側をNode.jsが担当します。 環境 MacOS Catalina: 10.15.1 Go: 1.13.4 Node.js: 10.15.3 クライアント(Go)の作成 クライアント側のディレクトリを作成します。
はじめに このドキュメントは、gRPCを用いてサーバからクライアントへのPUSH通知を実現した事例をまとめたものです。 ここでいう PUSH 通知とは、通常のクライアントからサーバへのリクエストではなく、何かしらの契機によりサーバからクライアントへ送信される通知を指します。 例えばチャットツールでよくあるように、誰かのメッセージが入力されたらチャット参加者全員に通知されるというものです。 gRPCを利用してみた事例は現時点でも多く存在しますが、サーバ側からの通知の実現方法を述べた情報は調べた限りでは多くありませんでした。 本ドキュメントは、gRPC での PUSH 通知をどのように実装するのか？、そして、その時の課題にどのようなことがあるのか？という情報を提供することを目的としています。 TL;DR サーバからの PUSH 通知を、gRPC の Server Streaming RPC と
grpc_tools_node_protoc_tsを使って.protoファイルからTypeScriptの型定義ファイルを生成するNode.jsTypeScriptgRPC 概要 grpc-toolsを使って.protoファイルからNode.jsのgRPC clientコードを生成するでは、javascriptのmessage定義とclient実装を自動生成しましたが、今回は、これらのjavascriptに対応する型定義ファイル(.d.ts)を自動生成してみたいと思います。 前提 grpc-toolsを使って.protoファイルからNode.jsのgRPC clientコードを生成するの 生成するまでを手元で動作させていることが前提です。 また、プロジェクトディレクトリに今回使用するプラグイン grpc_tools_node_protoc_t をインストールしておく必要があります。
package main import ( "context" pb "github.com/morix1500/sample-go-grpc-middleware/proto" "google.golang.org/grpc" "net" ) type HelloService struct{} func (h HelloService) Hello(ctx context.Context, in *pb.HelloRequest) (*pb.HelloResponse, error) { return &pb.HelloResponse{ Message: "Hello, " + in.Name, }, nil } func main() { s := grpc.NewServer() pb.RegisterHelloServiceServer(s, HelloService{}) l
tl;dr すべての RPC に共通する処理には gRPC Interceptor を利用する 認証 Interceptor はすべての RPC で同じ処理を行って、認可 Interceptor は gRPC サービスごとに別の処理を行えるようにする 認証に使う Authorization 値は Metadata として送信する 複数の Interceptor をまとめて書くには go-grpc-middleware の chain を使う ここでは簡単のため Unary RPC を前提にまとめる gRPC Interceptor gRPC サーバーはオプションとして UnaryServerInterceptor 型を渡すことができる。UnaryServerInterceptor 型はすべての RPC の実行前後に処理のフックを追加することができるので、いわゆるミドルウェアを実装するために
はじめに Protocol BuffersはGoogle謹製のデータシリアライゼーションのツールです。言語非依存な形式でメッセージフォーマットを記述するとそのスタブを色々な言語向けに生成してくれる。XMLやJSONと違ってバイナリフォーマットであることが特徴で、転送時の効率が良いことが期待されます。似たような技術として MessagePackがありますね。さらにgRPCというフレームワークを使うとプロトコルのやり取りの定義までできて、RESTful APIでのSwaggerみたいな位置付けにもなる（ドキュメント生成＋ブラウザでの呼びだしみたいなことはできないけど）。 とは言え、外部から呼び出されるAPIにgRPC + Protocol Buffers というのはあまりないと思っていて、そこは昔だとSOAP+XML、今はREST+JSONか、流行り始めている GraphQL+JSONになるの
HTTPのステータスコードにあたる概念がgRPC Codeであり、以下で定義されている。 https://github.com/googleapis/googleapis/blob/master/google/rpc/code.proto 例えばGo言語だと以下にprotoから生成されたコードがある。 https://github.com/grpc/grpc-go/blob/master/codes/codes.go 一覧 適当に翻訳していく。 OK = 0 エラーなし。成功を返した。 HTTPだと 200 OK CANCELLED = 1 処理がキャンセルされた。通常は呼び出し側によるキャンセル。 HTTPだと 499 Client Closed Request ※Lを2つ重ねるスペルなことに注意。後述 UNKNOWN = 2 不明エラー。他のアドレス空間から受け取ったステータスを、適切
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 設計がしっかりしていないまま開発をしてしまうとビジネスロジックとライブラリが密結合となりがちです。 密結合度が高いほど修正が困難となり、継続的な開発の難易度が上がっていきます。（技術的負債） またプロジェクトが大きくなってくると扱うデータ量も多くなり処理速度もデータ量に比例するため、計算量オーダーの影響を受けます。 プロジェクトのそれぞれの機能に対して 再利用可能 テストしやすい 機能追加しやすい ビジネスロジックとライブラリ、REST API（+マスターデータ）を分離できる となっていれば継続的な開発がしやすいです。 最近で
はじめに gRPCという言葉自体はよく聞いていたのですが、「RESTと同じような立ち位置なんだよね？何が違うの？」という状況だったので調べてまとめてみました。 モダンな技術を採用している企業では、既にサービスで当たり前のように活用されている技術ですので、gRPCの基本レベルで自信無い方は目を通してみてください。 gRPCとは gRPCはGoogle謹製のHTTP/2を利用したRPCフレームワークです。 Protocol Buffersを利用し、データをシリアライズして高速なRPCを実現します。 （Protocol Buffers以外も利用可能ですが、デファクトスタンダードとなっているため、本記事ではProtocol Buffersを前提に説明します。） protoファイルと呼ばれるIDL(Interface Definition Language)にAPI仕様を記述します。 また、IDLか
はじめに gRPCサーバのバリデーションを実装するにあたって、go-proto-validatorsは大変便利なのですが、gRPCクライアントツールで動作確認できないという罠に嵌ったので、原因と解決策を共有します。 go-proto-validatorsの基本 go-proto-validatorsとは？ go-proto-validatorsはGo向けのgRPCのバリデーションツールです。 protoファイルに直接バリデーションルールを記載することでIF情報を一元管理できるようになるのと、バリデーションコードの自動生成ができるのが良いところです。 使い方やルール一覧などの詳細はGitHubのページを確認してください。 Star数の割にはかなり良さそうです。 なぜgo-proto-validatorsを使いたいのか？ gRPCサーバのバリデーション実装には、REST-APIサーバ同様にoz
#はじめに 「gRPCって何？」 「gRPCを聞いたことあるけど使ったことがない。」 「gRPCをGolang/Go言語で使うにはどうしたらいいの？」 という人向け（私です）に記載しました。 gRPCをGolangで使ってみましょう。 「Go Quick Start」 を参考にしています。 https://grpc.io/docs/quickstart/go.html #gRPCとは gRPC は、Googleが開発したプロトコルです。デフォルトでは、Protocol Bufferを使って、データをシリアライズ化し、高速な通信が可能です。 gRPCでは、クライアントアプリケーションは別のマシン上のサーバーアプリケーションのメソッドをローカルオブジェクトのように直接呼び出すことができるため、分散型のアプリケーションやサービスを簡単に作成できます。 gRPCは多くの言語をサポートしています。た
まえがき この記事は以下の順序で組み立てられています。 gRPC用のコードを自動生成する APIとして呼び出される関数の実装をする gRPCサーバーとして起動する CLIツールを使って呼び出してみる 記事を書くために動作確認をしている環境はUbuntu18.04です。 ただしMacやその他のOSでも、ツールのインストール周りを公式のドキュメントに差し替えて頂ければ動かせるかと思います。 間違いなどありましたら、コメントや編集リクエストなどを貰えると嬉しいです。 gRPC用のコードを自動生成する 1. リクエストとレスポンスの構造を定義する まずはProtocol Buffersと呼ばれる、構造を定義する為の言語を使って、リクエストやレスポンスを定義していきます。 example.proto syntax = "proto3"; package pb; message HelloReques
この記事は 第2のドワンゴ Advent Calendar 2017 最終日の記事です。 はじめに ウェブ技術を語る上で欠かすことのできない要素として、HTTPがある。 従来のHTTP/1を無くして、ここまでのウェブの発展はなかったといえるだろう。言うまでもなく、HTTP/1が我々人類に齎した功績は大きい。 しかしその一方で、その規格のシンプルな原理原則に縛られた結果、要件を達成するために非効率なネットワーク使用を前提とするシステムが量産されるなど、HTTP/1がもたらした技術的負債も存在する。 その中の一分野として、双方向通信に着目したときに、HTTP/1からHTTP/2へのアップグレードによってどのような変化がもたらされたか。 本稿ではHTTP/2という規格と、それが持つ可能性の一端としてgRPCについての仕組みを紹介し、従来とこれからのWeb開発における双方向通信について述懐する。
前回のgRPCのクイックスタートをやったときにサーバーリフレクションのことがよくわからなかった。サーバーリフレクションにもチュートリアルがあったのでやってみた。 TL;DR サーバーリフレクションを使うと実行中のサーバからプロトコルバッファーの定義を取得したり、実行出来るようになる。 Goで利用するには、grpc.NewServer()のあとで通常のプロトコルバッファーのRegisterをした後reflection.Registerメソッドを呼ぶだけ チュートリアルの手順通りに行うとc++のクライアントからサーバのプロトコルバッファーを確認することができる。 Server Reflectionとは GRPC Server Reflection Protocol https://github.com/grpc/grpc/blob/master/doc/server-reflection.md
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
