マイクロサービスバックエンドAPIのためのRESTとgRPC
1. The document discusses RESTful APIs and gRPC, comparing their characteristics and use cases. 2. RESTful APIs typically use HTTP and JSON to access resources via URLs while gRPC uses protocol buffers and HTTP/2 for efficient streaming and RPC. 3. gRPC is better suited for microservices and mobile apps due to its ability to handle streaming and performance, while REST is more widely used due to i
Nginx でリバースプロクシを立てるときに気にすべき proxy_next_upstream 設定 - 無印吉澤
個人的に、Nginx で「これは危険だ」と思っている設定があって、Nginx でなにかあるたびにその設定をつい疑ってしまいます。その設定について他の人に話すたびに、いちいち資料を集めるのが面倒になってきたので、今回はその設定項目についての情報をまとめておきます。 まだ理解に自信がない部分があるので、新しい情報が入ってきたら、この記事を適宜修正します。 リバースプロクシ設定の基本 Nginx をリバースプロクシとして使う時には、ngx_http_upstream_module でサーバのグループを定義します。そして、サーバ名やロケーション（パス）に対して、送信先のグループを指定します。 以下はマニュアルにある例です。その Nginx サーバへのすべてのアクセスを、backend グループに指定されたいずれかのサーバに送信します。 upstream backend { server backe
GitHub - adnanh/webhook: webhook is a lightweight incoming webhook server to run shell commands
webhook is a lightweight configurable tool written in Go, that allows you to easily create HTTP endpoints (hooks) on your server, which you can use to execute configured commands. You can also pass data from the HTTP request (such as headers, payload or query variables) to your commands. webhook also allows you to specify rules which have to be satisfied in order for the hook to be triggered. For
継続的なAPI開発に。Goのマイクロサービスまとめ | NTT Communications Developer Portal
昨今人気を集めているGo言語ですが、メリットとして以下の点が挙げられます。 ビルド後の実行速度が速い 環境構築のスピードが速い バージョン依存の問題が少ない 環境依存の問題が少ない ポータル性がよい 逆にデメリットとしては以下の点も良く挙げられます。 JSON、XMLなどの扱いにも厳密な構造体が必要になる 冗長的になりがちな戻り値のエラーチェック デバッガや、Loggerなどが充実していない 開発時・運用時のノウハウ・ナレッジが、まだまだ少ない そんな中、上記のデメリットをカバーするためにGoによるマイクロサービスフレームワークの存在があります。今回はGo製のマイクロサービスのフレームワークやツールキットをご紹介します。 goa :: Design-first API Generation デザインファーストを謳うGO製マイクロサービスフレームワークです。デザインコード(goa API D
Swagger+JSON SchemaでAPIの型をテストして開発サイクルをスピードアップさせた話 - pixiv inside
CTO兼福岡オフィス立ち上げ担当として新アプリを作っている@edvakfです。 JSON APIを開発しているとこういう問題がありがちですよね。 仕様どおりにAPIの形式を作ったはずだけどなんか自信が持てない テストでいくつかのキーが存在するかの簡単なチェックはしてるつもりだけど、全部チェックするのは大変すぎる APIのControllerやViewをリファクタリングしたらレスポンスの形が変わってアプリがめっちゃクラッシュし始めた というのが怖くて誰もリファクタリングできなくなった APIドキュメントがメンテされない 知らない間にレスポンスのフィールドが増えてたけどドキュメントに書いてない これらを解決したい！と思って試行錯誤したら、スマートに解決することができました。この記事ではRailsのことについて書きますが、考え方は他の言語・フレームワークでも同じです。 なお、今回使ったgemのバ
GraphQLは何に向いているか - k0kubun's blog
今年GitHubがGraphQL APIを正式公開したあたりから、GraphQLが去年とかに比べちょっと流行り始めたように感じる。idobataがGraphQL APIを公開したり、Kibelaも公開APIをGraphQLで作ることを宣言している。 利用者側からすると使えるインターフェースの中から必要なものを調べて使うだけなのであまり考えることはないのだが、自分がAPIを提供する立場になると話は変わってくる。REST APIとGraphQL APIはどちらかがもう一方のスーパーセットという風にはなっておらず、どちらかを選択すると何かを捨てることになるので、要件に応じてどちらを選ぶのが総合的に幸せなのか考える必要がある。 以前趣味でGitHub連携のあるサービスを作っており、それを最近GraphQL API v4を使うように移行し、そこでついでにそのサービスのGraphQL APIを書いてみ
マイクロサービスアーキテクチャにおけるAPIコールの仕方とHTMLレンダリング - Qiita
先日、マイクロサービスの呼び出し方として、オーケストレーションとコレオグラフィについて書きましたが、同じく4章では、どうHTMLを組み立てるかという問題が提起されています。 ここもやや難解なので、咀嚼を試みます。 課題設定 次のようなECサイトを考えることにします。そして、4つのマイクロサービスを合成して構成します。 商品カタログサービス ショッピングカートサービス ショップサービス リコメンドサービス API合成 無垢な気持ちで設計すると、各々のマイクロサービスがWeb APIのインタフェースをもち、XMLやJSONを返して、ECサイト側で、テンプレートエンジンなどを用いて、HTMLをレンダリングするという方式になるかと思います。 そして、この形式でマイクロサービスを利用するサイト(アプリケーション)が増えていくと次の図のようになります。 これには、次の3つの欠点があるとされています。
APIサーバを立てるためのCORS設定決定版 - Qiita
タイトルは釣り、かつ、自分のための備忘録です。 マイクロサービスアーキテクチャでサービスを構築すると、APIサーバをサービスごとに立てるわけですが、 ブラウザ上のJSエンジンからAPIサーバを叩く時に避けて通れないのが、Same-Origin Policy（同一生成元ポリシー）によるCORS (Cross-Origin Resource Sharing)制限です。 これを回避するには、APIサーバ側でAccess-Control-*ヘッダを適切に返す必要がありますが、どう設定するべきかの情報が意外と少ないので（自分的）これが決定版！ という設定を考えてみました。 結論 nginxの場合の設定例です。 server { listen 80; server_name site.localhost; charset utf-8; root /var/www/app/public; locatio
Web API: The Good Partsを読んだので「設計変更しやすいWeb API」についてまとめた - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに APIの勉強のために、Web API: The Good Partsを読みました。平易な日本語で書いてあるので、読みやすかったです。 とはいえ、何度も本を読み返すのは大変なので、自分用まとめも兼ねて書こうと思った次第です。 1個1個まとめていくと結構な量があるので今回は「設計変更しやすいWeb API」についてまとめました。 本でいうと5章に書いてあります。 この記事も参考に Web API: The Good Partsの他のまとめ記事もここに載せておきます。 2.2: Web API: The Good Partsを読んだ
RESTful API の設計のキホン
2016/10/12 社内勉強会で使ったスライドを社外向けに一部加筆訂正したもの
HTTP API の設計方向
見てみると、たしかに Get 系の API だとしても POST を利用しているし、API の URL 設計に get_shared_link_file のようによく言われる REST っぽい設計は使っていなかった。 この方針は同意だ。自分は結構前に REST っぽい API を捨てることにした。だからといって REST API がダメだとかは思っていない。 一般ユーザが使う場合の API は REST API であるほうが慣れ親しんでいる場合が多いからだ。 AWS で利用されている HTTP API 仕様AWS の DynamoDB の Erlang/OTP ドライバーを書いているときに気づいたのだが、AWS の一部のサービスはかなり独特な API の仕様になっている。
Sam Newman - Backends For Frontends
Introduction With the advent and success of the web, the de facto way of delivering user interfaces has shifted from thick-client applications to interfaces delivered via the web, a trend that has also enabled the growth of SAAS-based solutions in general. The benefits of delivering a user interface over the web were huge - primarily as the cost of releasing new functionality was significantly red
BFF @ SoundCloud
Our friends at SoundCloud embarked on a journey a few years ago that changed their system and moved it from a monolithic Rails application towards an ecosystem of microservices. One thing that worked particularly well for them during that project is the BFF pattern, Backends for Frontends. Their BFF usage and the success story behind it may help other teams; so we decided to write it up. We hope y
microservicesに分割する際に注意するべき5つのこと - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに マーティンファウラーがmicroservicesの記事で、小さな役割をもったサービス群にアプリケーションを分割することを提案しています。 cookpadが、サービスをマイクロサービス群に分割していることの記事が注目を浴びており、最近急速にバズワード化しているように感じます。 バズワード化して、ポイントが損なわれる前にいくつかの注意点をまとめておきます。 1.インフラコストは基本的に増大する microservicesは、今まで単一のアプリケーションコードで行われていたことを複数のサービスサーバーに分割して管理・運営していくこと
REST APIとは？ - API設計のポイント
最近は様々なサービスでWebAPIが提供されています。普段の開発をする中でもシステム連携などでAPIを作る機会が出てくるのではないでしょうか。 WebAPIの中でもREST APIなんてものもよく聞くのかなぁと思います。REST APIの設計は色々と奥が深く、なかなかおもしろい技術です。 今回はそんなREST APIを設計する上でのポイントをご紹介していきます。この記事では実装よりも設計思想的な部分を書いています。次回以降にもう少し実装に近いレベル記事を書いきます！ REST APIは、「Representational State Transfer（表現状態の転送）」というアーキテクチャスタイルに従って設計されたAPIのことです。RESTの概念は2000年にRoy Fieldingによって提唱され、Webアーキテクチャにおける一つの重要な原則として広く認識されています。 じゃあ、REST
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - go-playground/webhooks: :fishing_pole_and_fish: Webhook receiver for GitHub, Bitbucket, GitLab, Gogs
ScalaでウェブAPIを書いている人が設計や実装やその他について話そうか
gRPC and REST with gRPC in practice
Web APIにバージョンをつけないように
Not Found
