マイクロサービスアーキテクチャにおけるAPIコールの仕方とHTMLレンダリング - Qiita
先日、マイクロサービスの呼び出し方として、オーケストレーションとコレオグラフィについて書きましたが、同じく4章では、どうHTMLを組み立てるかという問題が提起されています。 ここもやや難解なので、咀嚼を試みます。 課題設定 次のようなECサイトを考えることにします。そして、4つのマイクロサービスを合成して構成します。 商品カタログサービス ショッピングカートサービス ショップサービス リコメンドサービス API合成 無垢な気持ちで設計すると、各々のマイクロサービスがWeb APIのインタフェースをもち、XMLやJSONを返して、ECサイト側で、テンプレートエンジンなどを用いて、HTMLをレンダリングするという方式になるかと思います。 そして、この形式でマイクロサービスを利用するサイト(アプリケーション)が増えていくと次の図のようになります。 これには、次の3つの欠点があるとされています。
Architecting RESTful Rails 4 API · Jesal Gadhia
Architecting RESTful Rails 4 API 22 Oct 2013 This is a follow-up to my previous post about Authentication with Rails, Devise and AngularJS. This time we’ll focus more on some aspects of the API implementation. One thing to keep in mind, where my previous example used Rails 3.2, I’m using Rails 4 this time around. Versioning If you are building an API which could be potentially consumed by many dif
小さなサーバーで大きなサービスをつくる | カメリオ開発者ブログ
アーキテクトのItoです。動画を撮るのが趣味ですが、最近はこの本を買って、カラーグレーディングの勉強をしています。とても良い本です。 さて、今回お話するのはバックエンドにあるフロントエンドについて。 以下はほぼ実際にカメリオで運用しているバックエンド構成です。 図中のサーバーというものはいわゆるHTTPベースのサーバーアプリで、ここでは緑をNode.js, グレーをPython, C++で実装しています。小さいサーバーがたくさんあります。主にクライアント〜フロントエンドAPIだけの構成図で、記事クローラーや各種管理画面などは図にはありませんが存在します。 まずフロントエンドにELB(AWSを使用)とNginxを置き、後ろに NodeベースのフロントエンドAPIサーバーを置きます。 ここはNode.jsで作られたアプリをサービスするごく一般的な方法です。 エンドポイント(api.kamel.
[その３] Netflix: APIの改善と継続的デリバリー - ワザノバ | wazanova
http://techblog.netflix.com/2013/08/deploying-netflix-api.html その1はこちら。 その2はこちら。 このシリーズの3回目は、Netflixのサービスが急成長する中で、APIの改善と平行して継続的デリバリーを実現した経緯を紹介してます。同社の継続的デリバリーの仕組みのキーワードは、"Automation and Insight"（自動化と見える化）。 1) 開発から本番アップまでのフロー 開発からAWSインフラへの本番アップまでの概念図がこちら。段階的に、開発している機能の精度があがりシステムの安定性が増すのを確認していくプロセス。 具体的な作業フロー図はこちら。ほとんどプロセスは自動化され、各ステップでコードのステータスを確認できるような見える化の工夫がなされている。 2) ブランチ 現状では下記の３つのブランチがあるが、中期的
[その２] Netflix: APIの改善と継続的デリバリー - ワザノバ | wazanova
http://techblog.netflix.com/2013/01/optimizing-netflix-api.html その1はこちら。 2回目は、改善をしたプライベートAPIのアーキテクチャーについて、もう少し詳細を掘り下げています。 1) サーバコールをまとめる 以前のNetflix APIでは、一つのユーザエクスペリエンスを実現するために、複数のリクエストをクライアント側からAPIにコールする仕様であった。[イメージ図] そこでリクエストを一つにまとめることで、WANの遅延の影響を一度だけ受けるかたちに抑えて効率化した。このまとめられたリクエストは、サーバ側では複数のものを並列処理できることを担保すべき。そうするとエンドポイントの開発をするクライアントエンジニアそれぞれが、ローレベルなスレッド/ 同期 / スレッドセイフティ / 並列データ構造 / ノンブロッキングIOなどの
[その１] Netflix: APIの改善と継続的デリバリー - ワザノバ | wazanova
http://techblog.netflix.com/2012/07/embracing-differences-inside-netflix.html 北米のインターネットトラフィックの30%以上を占めるNetflixのシステム構成は、UI（デスクトップ、スマホ、タブレット、ゲームコンソール、TV、ブルーレイ再生機）とサービス（Video meta data, search, user, A/B test, personalization）をAPIでつなぐアーキテクチャーになっていて、UIとサービスがそれぞれ独立して早いスピードで改善 & 新機能を投入できるかたちになっています。そのAPI改善から継続的デリバリーの仕組みをつくりあげるまでの昨年からの一連の動きを、４回にわけて紹介します。まず最初はAPIの改善の取組みから。 1) 背景 Web APIとしてはRESTが標準的になっている
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
