マイクロサービスにおけるWeb APIスキーマの管理 ─ GraphQL、gRPC、OpenAPIの特徴と使いどころ マイクロサービスにおける通信方式の選択について、おおた（ota42y）さんが、GraphQL・gRPC・OpenAPIといった主なWeb APIスキーマの管理の利点と使い分けを解説します。 近年流行しているマイクロサービスアーキテクチャにおいては、「どういった通信方式を選ぶか」が開発の効率やサービスの信頼性、パフォーマンスを大きく左右します。この記事では、GraphQL・gRPC・OpenAPIそれぞれの利点と適切な使い分けについて解説します。 マイクロサービスにおけるWeb API管理の重要性 Schema First DevelopmentとWeb API 人ではなくプログラムが処理できるよう管理する Web APIのインタフェース定義手法の比較 OpenAPI ─ R
This repository contains a Go command line tool which converts JSON and YAML OpenAPI descriptions to and from equivalent Protocol Buffer representations. Protocol Buffers provide a language-neutral, platform-neutral, extensible mechanism for serializing structured data. gnostic's Protocol Buffer models for the OpenAPI Specification can be used to generate code that includes data structures with ex
While designing APIs consumed by clients (mobile or web applications), a common problem is how to enforce the structure of your data messages between the server and the client. As of today, the JSON format is probably the most used format of exchange used for APIs. JSON is good because it's simple, easy to read and write, and has implementations in almost every language in the world of programming
MySQL 5.7.12 から追加された X Protocol は Protobuf というのを使ってるらしいです。 Protobuf というのをそこで初めて知ったので、とりあえず Ruby から Protobuf を利用する方法を調べてみました。 Protobuf はデータ構造をバイト列にエンコードしたり、その逆にバイト列をデータ構造にデコードしたりするライブラリのようです。 Ubuntu で protobuf を使うには、protobuf-compiler パッケージをインストールします。 % sudo apt-get install protobuf-compiler Ruby から Protobuf を使うには、protobuf gem をインストールします。 % gem install protobuf データ構造は .proto という拡張子のファイルで定義するようです。 My
Custom encoding: Go implementation in net/rpc vs grpc and why we switched At Dgraph , we aim to build a low latency, distributed graph database. This means our data is distributed among nodes in the cluster. Executing a query means multiple nodes are communicating with each other. To keep our latency of communication low, we use a new form of serialization library called Flatbuffers. What sets Fla
Recently, I've been using gRPC more and more when writing backend services and have loved working with it's stricter API definitions, nicer error handling, and type-checking. I also love how easy it is to communicate with services written in different languages with minimal boilerplate. At this point, I'd almost always choose gRPC over REST for these kinds of services (at least for what I do, your
gRPC is the new standard Google RPC framework for external and internal developers, however ATM: - not supported by Classic GAE yet - cannot sent a request in browser - no support for oauth 2.0 on the server-side pRPC allows you to write gRPC-compatible code and solve these problems at the same time. protocol, client, server: https://godoc.org/github.com/luci/luci-go/grpc/prpc cproto: go get -u g
pRPC: gRPC on Classic AppEngine today gRPC is great, but is not available on Classic AppEngine at this time, so while waiting for it we wrote pRPC (provisional RPC) for Go. It is compatible with gRPC server/client code, but works on HTTP 1.x and Classic AppEngine. In addition it has gRPC-compatible discovery and a CLI tool. IDLJust like gRPC, pRPC uses Protocol Buffers to define API. I assume you
For customersCustomer supportSubscription managementSupport casesRed Hat Ecosystem CatalogFind a partnerFor partnersPartner portalPartner supportBecome a partner Try, buy, & sellRed Hat MarketplaceRed Hat StoreContact salesStart a trialLearning resourcesDocumentationTraining and certification Hybrid cloud learning hubInteractive labsLearning communityRed Hat TVOpen source communitiesAnsibleGlobal
This document provides an overview of lightweight messaging and remote procedure call (RPC) systems in distributed systems. It discusses messaging systems, typical peer-to-peer and broker-based messaging topologies, characteristics and features of messaging systems, main classes of messaging systems including enterprise service buses (ESBs), JMS implementations, AMQP implementations, and lightweig
ふと思い出し書き直しの話 (1, 2) の続き。 書き直しの必要に迫られることも、たまにはある。それはオリジナルが手に入らないとき。転職先で前の職場にあった内製ツールが使いたい。慣れたプログラミング言語にあったライブラリが新しい言語に欲しい。そんなときは自分の新しい環境でオリジナル相当品を書き直したいかもしれない。再発明、移植なんて呼ぶこともある。 この書き直し、再発明は、必ずしもオリジナルを超えなくていい。越えるべきオリジナルを使えない事情があってのコードだから。スポーツの試合で怪我をしたエースのかわりに急遽投入された補欠の立場に似ている。ベストを尽くし役割を果たせばいい。補欠系書き直しとでも呼ぶことにしよう。 Bazel と補欠たち 一応の役目は果たすものの、オリジナルほどはぱっとしない。そんな補欠系書き直しはたくさんある。 プログラミング言語をまたいだ補欠系書き直しとして真っ先に思い
2015/09/02にLinear RPCをOSS (Open Source Software)として公開させて頂きました。 http://linear-rpc.github.io/ Linear RPCはデータフォーマットにMessagePackを使用したRPC (Remote Procedure Call)であるMessagePack RPCの一実装です。今回はC++によるクライアント/サーバーとJavaScriptによるクライアント実装などを公開させて頂きました。Linear RPCは、元々IPネットワーク経由で業務用機器を遠隔制御するためのプロトコルとして実装しましたが、RPCを利用したいすべてのアプリケーションやサービスで利用することが可能になっています。 なお、公開させて頂いた実装についてですが、C++11仕様ではありません。これは、Linux用のC++のコンパイラでC++11
筑波大学大学院博士課程 システム情報工学研究科修士論文 分散システムのためのメッセージ表現手法 に関する研究 古橋 貞之 (コンピュータサイエンス専攻) 指導教員 新城靖 2012 年 3 月 概要 今日では、プログラムを同時並行的に複数のサーバ上で実行し、ネットワークを介して互 いにメッセージを交換しあうことで構成される分散システムが、幅広く利用されている。そ れらのシステムは、スクリプト言語を含む様々なプログラミング言語で実装されたプログラ ムが、新旧入り混じった様々なサーバ上で実行され、ソフトウェアおよびハードウェアのアッ プデートを繰り返しながら長期間運用される。分散システムは、このような異種混合の環境 においても相互運用性を維持し、動作し続けなければならない。 そこで本研究では、分散システムのための新たなメッセージ表現手法を設計し実装した。こ れを MessagePac
Scala でもやるかとぶつやく同僚を見て, たしかに Scala したいかも...などと意思の弱い私は気をそそられ, しかし特に書くものも思いつかずなんとなくウェブをぶらぶらしていた. そういえば Heroku が Scala をサポートしたニュースを読んだっけと検索すると, たしかにアナウンスがあった. このアナウンスにあるサンプルコードは面白い. Lift でも Play でもなく, Twitter の RPC フレームワークである Finagle が使われている. Finagle でサンプルを書いた理由の一つは画面におさまる簡潔さ, あとは流行り物の目新しさだろうけれど, Heroku の勧める Polyglot Platform の ありかたを示す意味もある気がしなくもない. Polyglot Polyglot という言葉を最初に目にしたのは プロダクティブプログラマ だったと思
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
