RESTアンチパターン
人々がRESTに挑戦しようとすると、通常、実例を探し始めます。そして、「RESTful」であると主張している多くの実例を探したり、「REST API」と名づけたりするだけでなく、RESTを行っていると主張する特定のサービスが何故失敗するのかに関する多くの議論を集めています。 何故、このようなことが起こるのでしょうか? HTTPは新しいものではありません。しかし、それは様々な方法で適用されています。それらのいくつかはＷｅｂデザイナが考えていたことと一致していますが、その多くは異なります。人が利用する、他のプログラムによって利用される、あるいはその両方の目的でそれらを構築するかどうかによらず、あなたのＨＴＴＰアプリケーションにＲＥＳＴの原則を適用するということは、あなたがまさにあべこべのことをするということを意味します。つまり、あなたは「正しく」Ｗｅｂを利用しようとしているのです。あなたがその
私がMVCフレームワークをもはや使わない理由
数ヶ月前、私はなぜここにたどり着き、何が可能かを理解する旅に出ました。この旅は、私にアプリケーションアーキテクチャ、MVCという強烈な宗教に対する疑いをもたらしました。そして、リアクティブ、関数型プログラミングの真の実力に触れたのです。また、シンプルさに集中する旅でもあり、私たちの産業はうまくやっているという考えを捨てる旅でもありました。どんなことを見つけたか興味がある方もいるでしょう。 私たちの見ている画面の背後にあるパターンはMVC –Model-View-Controllerです。まだウェブがなくソフトウエアアーキテクチャも分厚いクライアントが単一のデータベースに原始的なネットワークでアクセスするのがせいぜい、という時代にMVCは生まれました。そして数十年後、MVCはまだ現役であり、衰え知らずでオムニチャネルアプリケーションの開発に使われています。 Angular2のリリースの前にM
REST の欠点は何か
原文(投稿日：2013/05/26)へのリンク 数年前、Ganesh Prasad氏はインターネットはRESTより基礎的かどうかを問うた。その後も氏はRESTやSOA、最近はクラウドについて、RESTの原則を支持しながら議論を続けてきた。近頃、LinkedIn REST Architectsグループにポストされた"RESTの欠点は何か?"という質問に対して、氏は次のように、自身のブログの内容を繰り返すことで答えている。 RESTには"欠点"のようなものがあるとは思いません。RESTはRESTという名が示す通りに上手く動作しています。しかし、RESTアーキテクチャの実装はHTTPプロトコルしか使わないことは覚えておくべきです。将来は他のプロトコルを使う実装を構想することができるでしょう。そこでは何かしらの改善が行われるはずです。 氏は続けて、改善の余地がある4つの領域について話す。ちなみに氏
Datomic情報モデル
Datomicは、情報システムであるデータベースと考えられています。情報は事実の集合であり、事実は起きたことです。人は過去を変えられません。つまり、データベースはその部分を更新するのではなく、事実を蓄積するものなのです。過去は忘れられる一方で、変えることはできません。そのため、誰かが住所を「変更」したら、Datomicは過去の事実を置き換えるのではなく、新しい住所を持つという事実を記憶します。(現時点のことが単に格納されています。) この不変性により、数多くの重要なアーキテクチャに関する利点と機会が生まれます。前回の記事では、Datomicアーキテクチャのことを書きました。この記事では、情報モデルとプログラミングの経験に注目します。 従来のデータベース(と数多くの新しいデータベース!)は、「今」、目の前にある事実、に注目しますが、そうすることで情報を失っています。ビジネスは歴史的情報の中に
Datomicのアーキテクチャ
従来のRDBMSはデータを操作するために強力な論理的、宣言的、集合指向言語を提供します。しかし残念ながら、この強力さはデータベースサーバ側限定であり、データがアプリケーションに渡ってしまうとネストしたforループによってその効果がなくなってしまいます。Datomicは分散インデックスを提供し、宣言的問い合わせコンポーネントをアプリケーションサーバ層に配置できるようにします。この問い合わせエンジンはDatomicがホストするデータとインメモリのデータソースの両方のデータを一貫性のある高レベルの手法で操作できます。 全般的な関心 Datomicの設計には多くのコンセプトが取り込まれています。 単純さと合成。システムはひとつのことを行うサービスを複数組み合わせて構成するべきであり、サービスは互いを知っているべきでない。ストレージやキャッシュのような領域には良く考えられたシンプルなコンポーネントが
ORMのパフォーマンス最適化
これは明らかに遅く非効率だ。この問題はEager Loadingというテクニックを使うことで解決できる。もし最初の注文クエリの一部として後で必要となる顧客とのアソシエーションをすべてロードしておけば、Customerに対するアクセスはただのプロパティへのアクセスになる。こうすれば後のデータベースクエリは不要になり、N+1問題も起こらない。 LightSpeedでは、そのEager Load設定をTrueに変更することで（もしくは手書きコードのエンティティにEagerLoadAttributeを適用することで）、アソシエーションのEager Loadを可能にする。Eager Loadされるアソシエーションをもつエンティティをクエリすると、LightSpeedは追加のSQLを生成して、‘プライマリ’エンティティと同じように関連したエンティティを取得する。 Order.Customerアソシエー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GraphQL対REST - 考慮すべき点
Google：マネージャはやはり重要な存在である
Microsoft REST APIガイドラインはRESTfulではない
スクラムの７つの罪とアジャイルのアンチパターン
Webフレームワークベンチマーク2015
Googleがプログラマのビルドエラーを研究
PayPalにおけるNode.jsのSSLパフォーマンス改善
PayPal社がバックエンドをJavaからJavaScriptへ移行
BackboneとAngularを比較する
Ruby on Railsの現状と調査結果
Top JavaScript MVC Frameworks - InfoQ
作業中断のコスト
Facebook:「HTML5に賭けたのは間違い」発言の技術的な理由と反応
MoSH - モバイルシェル (The Mobile Shell)