Swiftでプロトコルバッファを使う - Qiita
先日、Apple から Swift Protobuf Plugin が公開されました。これは Swift でプロトコルバッファを使うためのツールです。 私はプロトコルバッファにそこまで詳しくないのでこれは良い機会だと思って試しに使ってみることにしました ####そもそもプロトコルバッファとは？ プロトコルバッファ(protobuf)とは、Googleが開発したオブジェクトシリアライズツールです。JSONのようにデバイス間でデータを送受信する際などに使えます。JSONと異なりパーズの必要はなく、バイト列から決め打ちでデータをとり出すので速い上にデータ量も非常に小さいです。 あらかじめデータコンテナ( protobuf では message という)の仕様を表す定義ファイル(.proto)を作成し、それを元に message クラスを自動生成してコンテナにアクセスします。データの構造をあらかじ
gRPCでブロードキャストを実現 - Qiita
gRPC Googleが中心となって開発しているRPCのフレームワークです。 Streaming RPCという、接続を維持したままリアルタイムにメッセージをやりとりできるRPCが用意されているため、オンラインゲームのようなリアルタイム性の高いものにも使えそうだと期待しています。 ブロードキャスト ブロードキャストとは、図のように、接続中のみんなにメッセージを飛ばすことです。 オンラインゲームや多人数のチャットを実装する際は必須となります。 gRPCにブロードキャスト専用の機能はある？ ないです。 gRPCは名前の通り、RPC（遠隔呼び出し）のためのフレームワークであり、 クライアント側が遠隔にあるサーバーに対して関数を呼び出す部分のみを提供しています。 ということで、専用の機能がないので、自前で仕組みを構築します。 Goで実装してみる ということで、gRPCでブロードキャストの実装を実際に
gRPC & Goで超簡素なチャットツールを実装する - Qiita
はじめに この記事はユニークビジョン株式会社 Advent Calendar 2018の12日目の記事です。 11日目から続けてgRPCで超簡素なチャットツールを実装してみました。 今回はgRPCのServer-side streaming RPCとClient-side streaming RPCを活用してリアルタイムなテキストのやりとりを実装します。 streamとは クライアントもしくはサーバが断続的なメッセージの末尾(EOF等)に到達するまで受信もしくは送信できる方式で、今回はリアルタイムなチャットメッセージの送受信に使用します。 準備 基本的に前回のプロジェクトを踏襲しています。 ディレクトリ構成 syntax = "proto3"; option java_multiple_files = true; option java_package = "io.tokikokoko.h
内部実装から理解するgRPC - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 概要 目的 gRPCはDocumentにあるように以下の特徴があるかと思います。 protocol buffer のようなインターフェース定義語 (IDL) から生成されたコードを利用してRPCができる HTTP/2で通信することができ、リクエストとレスポンスをそれぞれ分割できる 多言語に対応している しかし、この記事ではこれらの機能の紹介ではなく、gRPCの仕組みを理解することを意図しています。 なぜそれを意図したかというと普段の開発でgRPCを利用しているものの、どのような仕組みでRPCが実現できているのかイメージが持てていなかった
gRPCのChannelzを使ってみた - Qiita
Channelzとは gRPCを使おうとして最初にはまるのがコネクションの扱いな気がします。HTTPでリクエストするのと違ってリクエストとコネクションの管理が独立しているのでTransient Failureってなんや！ということが一回はあると思います。更にLoad BalancingしているとgRPCのコード上のコネクション(grpc.ClientConn)が複数のサーバへのコネクションを束ねている状態になるのでもっと複雑になります。 Transient failureなどの状態についての詳細はこちら。 https://github.com/grpc/grpc/blob/master/doc/connectivity-semantics-and-api.md そこで様々なコネクションの状態を観測できるようにしようということでChannelzというものが提案された(既にマージ済み)。 ht
nginx に実装された gRPC サポートを試してみる - Qiita
Announcing gRPC Support in NGINX ということで、nginx 1.13.9 で gRPC サポートが入り、HTTP と同じように gRPC ストリームを扱えるようになるようです。めでたい！ grpc_pass ディレクティブが新規に実装され、grpc:// と grpcs:// なバックエンドに対してリバースプロキシを行えるようになるようです。これを使って、 TLS 終端を nginx にやってもらったり 複数のバックエンドを置いて柔軟にロードバランスしてもらったり 同一のエンドポイントに複数 gRPC service を設定して、nginx にルーティングしてもらったり などの設定をすることが可能になるようです。 まだ正式にリリースされているわけではないので、今回は HEAD を持ってきて、リリースに載っている例を試してみます。 下準備 今回は適当に EC2
gRPC status codeの一覧 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 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 =
Goで始めるgRPC入門 - Qiita
なにこれ? 昔どこかに書いた記事が吹っ飛んで悲しかったので、こちらに復帰。 Goを使ってgRPCのServer,Clientを実装する記事となります。 gRPC? gRPCは、Googleによって開発されたRPCフレームワークです。 HTTP/2を使用した通信部分のライブラリ(ProtocolBuffersでシリアライズ)とProtocolBuffers(標準)としたテンプレートコードの生成がセットで提供されています。 ざっくりと言っちゃうと、HTTP/2を使った手続き部分がばっくり提供されていて Server,ClientのコードはProtocみたいなエコシステムでgenerate できる、という省エネでHTTP/2に乗れる仕組みです。わーい。 HTTP/2のstreamもサポートしています。 gRPCのサポートするRPC方式は以下の通り。 Unary RPC (1リクエスト1レスポンス
Protocol Buffers(proto3)でoptionalをどう扱うか - Qiita
2021.4.14 追記 proto3で削除されたoptionalですがv3.15(experimentalオプションを利用する場合はv3.12)から正式に実装されたため、それ以降のバージョンを利用する場合は素直にoptionalを利用してもらうのがいいと思います！ https://github.com/protocolbuffers/protobuf/releases/tag/v3.15.0 Protocol Buffersはproto3でrequiredとoptionalが削除されました。 そもそも削除された経緯に関しては、@qsonaさんのエントリーにて、分かりやすくまとめて下さっています。 そこで課題になるのが、proto3において各フィールドは全てデフォルト値を持つため、デフォルト値が設定されたフィールドが利用側から 意図的にセットされたデフォルト値と同様の値 存在しないためセッ
Go - gRPC での認証・認可を Interceptor を使って実装する - Qiita
tl;dr すべての RPC に共通する処理には gRPC Interceptor を利用する 認証 Interceptor はすべての RPC で同じ処理を行って、認可 Interceptor は gRPC サービスごとに別の処理を行えるようにする 認証に使う Authorization 値は Metadata として送信する 複数の Interceptor をまとめて書くには go-grpc-middleware の chain を使う ここでは簡単のため Unary RPC を前提にまとめる gRPC Interceptor gRPC サーバーはオプションとして UnaryServerInterceptor 型を渡すことができる。UnaryServerInterceptor 型はすべての RPC の実行前後に処理のフックを追加することができるので、いわゆるミドルウェアを実装するために
HTTP/2における双方向通信とgRPCとこれから - Qiita
この記事は 第2のドワンゴ Advent Calendar 2017 最終日の記事です。 はじめに ウェブ技術を語る上で欠かすことのできない要素として、HTTPがある。 従来のHTTP/1を無くして、ここまでのウェブの発展はなかったといえるだろう。言うまでもなく、HTTP/1が我々人類に齎した功績は大きい。 しかしその一方で、その規格のシンプルな原理原則に縛られた結果、要件を達成するために非効率なネットワーク使用を前提とするシステムが量産されるなど、HTTP/1がもたらした技術的負債も存在する。 その中の一分野として、双方向通信に着目したときに、HTTP/1からHTTP/2へのアップグレードによってどのような変化がもたらされたか。 本稿ではHTTP/2という規格と、それが持つ可能性の一端としてgRPCについての仕組みを紹介し、従来とこれからのWeb開発における双方向通信について述懐する。
gRPCって何？ - Qiita
// Code generated by protoc-gen-go. DO NOT EDIT. // source: helloworld.proto ... package helloworld ... // The request message containing the user's name. type HelloRequest struct { Name string `protobuf:"bytes,1,opt,name=name" json:"name,omitempty"` } func (m *HelloRequest) Reset() { *m = HelloRequest{} } func (m *HelloRequest) String() string { return proto.CompactTextString(m) } func (*HelloReq
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
gRPC-WebのProxyをNginxにしてみた - Qiita