サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
VOYAGE Lighthouse Studio の海老原 (@co3k) です。先日 30 歳になった記念としてタイトルはオヤジギャグです。 さて、普段は 神ゲー攻略 というゲーム攻略サイトを運営しているのですが、とある派生サービスを立ち上げるにあたり、 WebAPI スキーマ定義をgRPC に基づく形式の Protocol Buffers で書き、 protoc-gen-swagger プラグインを介してOpenAPI 定義ファイルとして生成する、というアプローチを採りました。 yugui さんの素晴らしい記事、「今さらProtocol Buffersと、手に馴染む道具の話」によってスキーマ定義言語としての Protocol Buffers がにわかに注目を浴びて以降、似たようなことをやりたいという方もいらっしゃるのではないでしょうか。 ところが、おそらく単体で protoc-g
以前の記事ではprotocプラグインの書き方を紹介したが、実は1つ問題があった。 実用的なプラグインを書こうとした場合に、しばしば生成時に必要な、ドメイン固有の情報が足りないのである。本稿ではそれを補うカスタムオプションの話をする。 ここでもう一度確認しよう。protocのプラグインはProtocol Buffersのスキーマを読んで任意の処理を行える仕組みだ。それはCodeGeneratorRequest内のFileDescriptorProto messageを読み取って任意のバイト列を出力し、出力を受け取ったprotocが指定通りにファイルにバイト列を書き込んでくれる。 ただ、FileDescriptorProtoはprotobufのスキーマ言語の文法をprotobufメッセージとして表現したものに過ぎないから、極めて一般的なデータ構造とサービス定義を表現する能力しか持たない。プログ
数多くのAPI で長期にわたって一貫したデベロッパー エクスペリエンスを提供するために、API で使用されるすべての名前は、次の特徴を備えていることが推奨されます。 シンプル 直感的 整合性 これには、インターフェース、リソース、コレクション、メソッド、メッセージの名前が含まれます。 多くの開発者は英語が母語ではないため、大部分の開発者がAPI を簡単に理解できるようにすることが、これらの命名規則の 1 つの目標です。そのためには、メソッドやリソースに名前を付けるときに、シンプルで整合性のある少ない語彙を使用することが推奨されます。API で使用される名前は、正しいアメリカ英語にすることが推奨されます。たとえば、licence ではなく license、colour ではなく color などです。 用語が長い場合は、簡略化するために、一般に使用されている短縮形や略語を使用することも
動機 FRESH!はMicroservicesアーキテクチャでやっているが、今まさにAPI v2というのが動いていて構成の刷新に動いている。技術的なトピックとしては iOS/AndroidからAPIへの通信をフルgRPC化 Service Meshの導入Amazon ECS ->Kubernetes化 といったところで本格的に動きはじめている。 1つのRepositoryに1サービスという構成で作っているので、それぞれにgRPCのインタフェースを用意し、Service MeshでよしなにRoutingやDiscoveryしていく感じ。サービス毎にgRPC/Protocol Buffersのインタフェース定義のIDL（.protoファイル）を配置していく。 .proto群をかき集めたい iOSやAndroidはもちろんMicroservices間の通信もそうなのだが、様々なサービスのID
概要gRPCで通信しようとすると.protoファイルが沢山出てきます。 ただ人によってインデントが異なったりするのは良くないので、何かしらformatterが無いかなと探したらgithub.com こちらのissueで「Googleではclang-formatを使ってるよ」という回答があったのでそれを使ってみます。 環境macOS Mojave 10.14.2 clang-format 8.0.0 設定 インストール brew でインストールできます。 $ brew install clang-format 使い方 $ xargs clang-format -i foo.proto で整形できます。ディレクトリ丸ごと実行したい場合は./proto/ディレクトリで定義しているとすると $ find ./proto/ -name "*.proto" | xargs clang-forma
Covers how to use the proto3 revision of the Protocol Buffers language in your project. Thisguide describes how to use the protocol buffer language to structure your protocol buffer data, including .proto file syntax and how to generate data access classes from your .proto files.It covers the proto3 revision of the protocol buffers language. For information on editions syntax, see the Protobuf E
Protocol Buffers are a language-neutral, platform-neutral extensible mechanism for serializing structured data.It’s like JSON, exceptit’s smaller and faster, andit generates native language bindings. You define how you want your data to be structured once, then you can use special generated source code to easily write and read your structured data to and from a variety of data streams and using
Protocol Buffersは別に新しい技術ではない。同時にそれは、未だ知られざる、未だに可能性を秘めた先端のソフトウェア技術基盤である。 新しくないのは事実で、GoogleがProtocol Buffersをオープンソース化したのは2008年のことだし、オープンソース化前に社内で使われ出したのは更に昔に遡るだろう。たぶん。 デザイン的にもJSON対応は後付けで、将来JSONが隆盛を極めることなんか全然想定していなかったのが透けて見えて古くさい。 しかし、同時にどうも情報に聡い人であってもなかなかその真価を実感し得ておらず、ある意味で未知の技術であるらしい。ならば、Protobuf (Protocol Buffersの略)を解説した文書は幾多あれども、それに1を加えるのもやぶさかではない。 Protocol Buffersとは Protobufはスキーマ言語だ! 一般的にはProtob
1リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
