サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
まとめ 相性バツグンといわれる、モバイル xgRPCは思ったよりずっと簡単に実装可能 複数言語間でもProtocol Buffersの恩恵により型変換を意識することなくスムーズに開発が進められる。 メソッド、引数の型、引数の返り値の型が自動生成されるのでとても良い RESTfulAPIにおけるheaderを、表現力の高いMetaDataとして利用し、認証認可等にも使えそう Streamをうまく使いこなせば、ユーザー体験をめっちゃ高くできそう。チャットやゲームなどの双方向通信が比較的楽に実装できるかも どんな人向きでない記事？ NestJSの詳しい実装を知りたい方 Bidirectional streaming, Client streamの詳細実装を知りたい方 モバイル向け通信技術の本格的な選択肢、gRPCを実際に試してみたい 現在、私の働いているMinediaで開発しているサービス群
3-shake にはSreake共有会 という毎週、火曜日と木曜日に担当者が現場で得た知見などを発表する社内勉強会が開催されています。こちらのブログはそれらを変更修正しております。 syu-m-5151.hatenablog.com 元々しようとしていたの話Go 1.18 の最新情報←Generics の深い話とかはもう既出すぎて気になる人は読んでるGo でのTDD(が実は20周年なので)←書いてる途中で自分が言うべきことなんてないことに気付く 今後、案件で増えるであろうgRPC についてインフラエンジニアが知っておいても良いと思ったという話 ← 今ここ TL;DR protobuf (Protocol Buffers) はデータフォーマットで、JSONの役割を置き換えるものです。一方gRPC は通信プロトコルで、HTTPの役割を置き換えるものです。gRPC をライブラリやツール
こんにちは、ティアフォーで認証認可基盤を開発している澤田です。 最近取り入れたProtobufで、素晴らしいRESTAPIの開発体験をしたのでご紹介します。 なお、ティアフォーではマイクロサービスを支える認証認可基盤を一緒に開発いただけるメンバーを募集しています。ご興味のある方は下記ページからご応募ください。 herp.careers 実現したかったこと マイクロサービス間連携のAPI開発において、以下の条件を満たすやり方を探していました。 スキーマを最初に定義してリクエストとレスポンスの型が自動で生成される ドキュメント（openapi.yaml）が生成される バリデーションが定義できて、その実装が自動で生成される 実現方法Go言語で開発する場合はgo-swaggerでも実現できますが、本記事では、Protobufで実現できるgRPCGatewayとprotoc-gen-valid
Envoy is an open source edge and service proxy, designed for cloud-native applications As on the ground microservice practitioners quickly realize, the majority of operational problems that arise when moving to a distributed architecture are ultimately grounded in two areas:networking andobservability.It issimply an orders of magnitude larger problem tonetwork and debug a set of intertwined d
マイクロサービスにおけるWeb APIスキーマの管理 ─ GraphQL、gRPC、OpenAPIの特徴と使いどころ マイクロサービスにおける通信方式の選択について、おおた（ota42y）さんが、GraphQL・gRPC・OpenAPIといった主なWeb APIスキーマの管理の利点と使い分けを解説します。 近年流行しているマイクロサービスアーキテクチャにおいては、「どういった通信方式を選ぶか」が開発の効率やサービスの信頼性、パフォーマンスを大きく左右します。この記事では、GraphQL・gRPC・OpenAPIそれぞれの利点と適切な使い分けについて解説します。 マイクロサービスにおけるWebAPI管理の重要性 Schema First DevelopmentとWebAPI 人ではなくプログラムが処理できるよう管理する WebAPIのインタフェース定義手法の比較OpenAPI ─ R
マイクロサービスや自作ミドルウェアのAPIをメンテナブルにしたいよねっていう文脈で、OpenAPIやGraphQL、gRPCといった技術が採用されるのを最近よく目にする。 バックエンドを実装しているWebエンジニアとしては、こういう仕組みが整備されつつあるのはありがたい。APIをシステムの外に公開しようとすると、ドキュメンテーション/バリデーション/クライアントの実装など、意外と副次的な作業が必要なので、、汎用化されたツールに頼れるのは助かる。マイクロサービスを用いたアーキテクチャを考えるにあたっても、システム間のアダプタをイメージしやすくなる。 そういう背景で、最近家ではgRPCを調べている。このあとはgRPCについて調べたことのメモや感想のコーナーになっているので、興味があったらどうぞ。 主な情報源 だいたいこのへんを眺めておくと、gRPCの基本については抑えることができる。grpc
// 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
Today, we’re excited to share the first native support forgRPC traffic, released inNGINX Open Source 1.13.10.NGINX Plus Release 15 includesgRPC support as well as the support for HTTP/2 server push introduced inNGINX 1.13.9.NGINX can already proxygRPC TCP connections. With this new capability, you can terminate, inspect, and routegRPC method calls. You can useit to: Publish agRPC service
1リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
