GraphQL と N+1 SQL 問題と dataloader - Qiita
この記事ではハイパフォーマンスな GraphQL サーバを実装するのに避けて通れない N+1 SQL 問題について解説します。 TL;DR GraphQL は resolver を個別にかつ再帰的に実行していくため、 RDB のリレーションを効率的に先読みすることができません。そのため一般的に遅延読み込みを行います。 Facebook 社は GraphQL で遅延読み込みするために dataloader という npm パッケージを公開しており、各種言語にその移植版のライブラリが存在しているので、それを使って N+1 SQL 問題を抑制しましょう。 （復習）N+1 SQL 問題とは N+1 問題は「1 つの SQL で N 件のレコードをフェッチしたあと、それぞれ対して関連するレコードを個別にフェッチするのに N つの SQL を発行している」状態を指す言葉です。言葉で書いてもよく分からな
10分で GraphQL 入門 - Qiita
これは 6/28 に開催される GraphQL ナイト のための資料です ここまでで分かること クエリは独自言語みたい クエリを変えることで柔軟にデータをとってこれそう クエリと結果の見た目が似てるのは分かりやすそう（主観） でも facebook はなんで作ったの？ facebook の事情 数十億ユーザから膨大なリクエストがくる 新興国の低速なネットワークからのモバイル接続も多い アップデートされないモバイルアプリもサポートする つまり リクエスト回数は可能な限り減らしたい 後方互換を維持しながら API を開発したい 無駄なデータを送りたくない （大規模開発なので型安全も欲しい） 規模は違えど我々も同じような問題を抱えているのでは？ なぜ既存のものではダメだったのか？ より詳しくは昔の graphql.org のページを参照（internet archive） v.s. REST 複
.zshrcで見かけるautoloadの意味と使い方 - Qiita
今回はこの autoload が何をするものなのか解説します。 autoloadはシェル関数を読み込む autoload はシェル関数を 自動読み込み するシェルの組み込み関数です。上記のスクリプトの場合、 compinit というシェル関数を自動読み込みします。 シェルコマンドは PATH に入っていればそれだけで実行可能でしたが、シェル関数の場合は関数を定義しなければ使えません。 autoload はファイルシステム上にある関数定義を読み込むための関数なのです。そして autoload 探索するディレクトリは FPATH に入っています。 余談ですが FPATH だと : 区切りの文字列、 fpath だと配列になります。PATH と path と同じですね。 シェル関数とシェルコマンドの違い autoloadを使ってみる % mkdir ~/functions % FPATH="${
新QiitaでReactをやめてhyperappを採用した背景 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 12/1 に Qiita のトップページをリニューアルしました。これまで React を使っていましたが、それをやめて hyperapp を採用しました。まわりを見てもあまり採用事例が見当たらないので、この記事では一体なんで今をときめく React ではなく hyperapp を選択したのか、どういうところが魅力的なのかについて プレゼンテーション層を実装するためのツールとして 学習コスト の観点から書きたいと思います。なおこの記事に書かれていることは全て個人の感想であり、はっきりいって個人の日記レベルです。 それと hyperapp
RSpecを並列実行するgemを作っている話 - Qiita
これは Ruby アドベントカレンダー 24 日目の記事です。 Railsを長く開発していると機能を追加していくにつれてテストコードも肥大化し、初めのうちは一瞬で終わっていたrspecも気がつけば数十分かかるようになっていたということも多いと思います。テストをCIで回していると、結果が得られるまで作業が止まることになるので、テスト時間の肥大化は結構大きなインパクトを持ってきます。 テストの中にボトルネックがある場合それを解消することである程度の高速化ができますが、純粋にテストの数が多いということになると、全てのテストを実行するのを諦めないのであれば、テストを並列に実行するのが高速化のアプローチとなります。 テストを並列実行するgem テストを並列に実行するgemはすでに世の中にいくつもあります。 rrrspec Cookpad社が作っているrrrspecはRSpecを複数サーバで分散実行し
RDB - 実例で学ぶ、JOIN (NLJ) が遅くなる理屈と対処法 - Qiita
"Nested Loop Joinしか取り上げて無いのにタイトルが大きすぎないか" と指摘を頂いたので、タイトルを修正しました。Merge JoinとHash Joinのことはまた今度書こうと思います。 「JOINは遅い」とよく言われます。特にRDBを使い始めて間がない内にそういう言説に触れた結果「JOIN=悪」という認識で固定化されてしまっている人も多いように感じています。 たしかに、JOINを含むようなSELECT文は、含まないものに比べて重たくなる傾向があることは事実です。また、本質的に問い合わせたい内容が複雑で、対処することが難しいものも存在します。しかし、RDBの中で一体どういうことが起きているのかを知り、それに基いて対処すれば高速化できることも少なくないと考えています。 本稿では、JOINの内部動作を解説した上で、Webサービスを作っているとよく出てくるJOIN SQLを例題に
Node書くならEventEmitterについて知っとくべし - Qiita
Nodeの組み込みモジュール・サードパーティモジュール問わず広く使われるのが EventEmitter オブジェクト。 これはNodeで使われるデザインパターンの筆頭みたいなものなので、知っておかねばならない。 ドキュメント: Events ブラウザ上のJavaScriptで addEventListener を使ってイベントドリブンの開発を行うが、Node上でそれを行うのための機能を提供するのが EventEmitter。 例えば次のように使う var EventEmitter = require('events').EventEmitter; function asyncFunc() { var ev = new EventEmitter; console.log('in asyncFunc'); setTimeout(function () { ev.emit('done', 'fo
モデルのバリデーションエラーはカスタムイベントで通知すると便利 - Qiita
Backbone.js Tips And Patterns | Smashing Coding を読みました。 ほとんどは特に真新しくもない当たり前な内容なんですが、 "BROADCAST CUSTOM ERROR EVENT" はいいなと思ったので紹介します。 このパターンは Model で複数の属性のバリデーションを行いたい場面で使うものです。 RETURN AN ERROR OBJECT まず、普通な validate の実装です。 validate: function (attrs) { var errors = []; if (_.isUndefined(attrs.name)) { errors.push({ attr: 'name', message: 'Name is required' }); } if (errors.length) return errors; } ま
ビューが画面に現れたら処理を実行する - Qiita
Backbone.js Advent Calendar 2日目! 勢い良く走り始めたBackbone.js Advent Calendarですが、初日に引き続き2日目もビューに関連する話題です。 ビューの遅延評価をしたい Backbone.jsに限らずサービスを高速化するために、遅延評価を行いたい場面は沢山あります。たとえば画像掲示板のシステムを作っていたら、いきなり画像全てを読み込もうとするとサーバにも負荷がかかりますし、何よりユーザが表示しない画像まで読み込むのは無駄です。他にもTwitterのようなタイムラインに対して、一番下までユーザがスクロールしたら自動的に続きを読み込むような処理を行いたい場合もあるでしょう。 という訳でユーザのスクロールをトリガーにしてイベントを発火させられるBackbone.LazyViewというのを作ってみました。 taak84u9/backbone-la
RailsアプリでBackbone.jsを使う - Qiita
Backbone.js Advent Calendar 5日目 Backbone.jsの本家ドキュメントにtodoリストをブラウザのLocalStorageを使って保存するチュートリアルがあります。 todo.js 今回は、このtodoアプリのバックエンドとして、Ruby on Railsを使うように変更してみたいと思います。 Backbone.jsとサーバの通信 Backbone.jsはModelやCollectionの内容をサーバと同期するための手段を提供してくれています。標準で用意されているBackbone.syncはサーバがRESTfulと呼ばれるインタフェースを提供していることを前提に動作しますが、同期する方法を自作することも可能で、例えば上記のtodoリストのチュートリアルではLocalStorageにデータを保存するために、Storeという名前のオブジェクトを自作して用いてい
Modelの一対多を実装する - Qiita
例えば、Blogテーブルにuser_idカラムがあり、これがUserテーブルへの外部キー制約になっているような場合、WebフレームワークではBlogモデルにuserフィールドを持たせて、そのフィールドにメッセージを送ると、参照しているUserモデルのインスタンスを返してくれるようになっている場合が多いと思います。 このような関係をBackbone.jsで実現しようと思い、つい以下のように書きたくなってしまうかも知れません。 var User = Backbone.Model.extend({}); var author = new User({id: $(".user_id").html()}); var Blog = Backbone.Model.extend({}); var entry = new Backbone({text: $(".text").html(), user_id:
Backbone.js入門 「View と Model と Collection の連携」 - Qiita
閲覧上の注意 この記事で対象としているバージョン0.5.3は結構古いので注意してください。 その他の割りと新しい情報は Backbone.js Advent Calendar 2012 などにあります。 （追記ここまで） Backbone.js入門シリーズも佳境に差し掛かってきました。 View と Model の連携は既に取り上げたので、今回は特に Collection と View Model との連携に主眼を当てて記述したいと思います。 View と Collection の連携 復習の意味も込めて、View と Model の連携方法をもう一度記述すると、大枠として次のようになります。 // モデルの定義 Hoge = Backbone.Model.extend({}); // ビューの定義 HogeView = Backbone.View.extend({ events: { "
Backbone.js入門 「Router と History」 - Qiita
閲覧上の注意 この記事で対象としているバージョン0.5.3は結構古いので注意してください。 その他の割りと新しい情報は Backbone.js Advent Calendar 2012 などにあります。 （追記ここまで） Backbone.js入門の最終回は Router と History です。 Backbone.js入門 「MVC」で述べたように、URL が変更された時に発生する popstate または hashchange イベントを監視してルーチンを起動するのが Router の役目です。History は Router の裏方で頑張る実体で、直接操作することはほとんどありません。 URL が変更された時にアクセスされるのが Router なので、Rails 的な MVC の枠組みで言えばコントローラと言えますし、伝統的な MVC で言えば全てのアンカーとブラウザの進退ボタンを
Backbone.js入門 「View」 - Qiita
閲覧上の注意 この記事で対象としているバージョン0.5.3は結構古いので注意してください。例えばこの記事の内容でいえば、$elプロパティなどが追加されています。 その他の割りと新しい情報は Backbone.js Advent Calendar 2012 などにあります。 （追記ここまで） Backbone.js Advent Calendar もようやく折り返し地点。 そんな節目のエントリで取り上げるのが Backbone.js プログラミングでの最重要登場人物の一人である View です。 前回のエントリで Backbone.js では View が各種の処理を起動するということを説明しました。 今回は View を使って、イベントハンドリングを行う方法について主に解説していこうと思います。 View と DOM tree View の役割は大きく分けて2つあります。 特定の DOM
Backbone.js入門 「Model」 - Qiita
閲覧上の注意 この記事で対象としているバージョン0.5.3は結構古いので注意してください。例えばこの記事の内容でいうと、validateに失敗したときに発生するイベントは'error'から'invalid'に変更されています。 その他の割りと新しい情報は Backbone.js Advent Calendar 2012 などにあります。 （追記ここまで） 今日のテーマは Model です。 MVC に関する回で Backbone.js における MVC は Rails などの WAF における MVC よりは伝統的な MVC に近い というようなことを書きました。 しかしながら、モデルに関して言えばどちらの場合も大差ありませんから、気分が楽です。 Rails におけるモデルである ActiveRecord が OR マッパーとしての役割を持っていたり、データのバリデーション機能を持っていた
Backbone.js入門 「View と Model の連携」 - Qiita
閲覧上の注意 この記事で対象としているバージョン0.5.3は結構古いので注意してください。 その他の割りと新しい情報は Backbone.js Advent Calendar 2012 などにあります。 （追記ここまで） 今日のテーマは View と Model の連携です。 基本的なパターン 例えばブログサービスを作っているとします。 おそらく Blog というモデルや、それを表示するページのビューを作ることになると思いますが、記事の全文を表示するビューや複数の記事をリスト形式で表示するビュー、編集ビューなどなど、一つのモデルに対して複数のビューが存在するのが一般的ではないでしょうか。 このように View と Model は基本的に 多対一 の関係になっています。 そのため、Model の属性が変更されたら、複数の View に変更を通知・反映しなければなりません（でなければユーザはシ
Qiitaがquery-stringっぽい構文を自前実装した理由 - Qiita
これは Elasticsearch Advent Calendar 2014 15日目の記事です。 今秋、Qiitaの検索システムが刷新されました。 Qiita/Qiita:Teamの検索システムがパワーアップしました - Qiita Blog ブログ記事の中でも簡単に紹介していますが、例えば title:"elasticsearch 入門" と検索すると、タイトルに "elasticsearch" と "入門" を単語を含んだ記事を検索できたり、他にも OR が使えたり、マイナス検索ができたりします。 一見すると query string query でも使ってるみたいですが実際はそんなことはなく、泥臭く検索文字列をその都度解析し、生成したクエリをElasticsearchに投げています。この記事では、なぜ query string query を使わずに自分で書いたのかという話と、公開
CoffeeScriptとJavaScriptやPythonやRubyの文法の比較 - Qiita
PythonやRubyだとあんな感じで書くけど、CoffeeScriptだとどうかなーというのを思い浮かぶがままに書き下していく。 JavaScriptも追加 コメント
Backbone.js入門 「MVC」 - Qiita
閲覧上の注意 この記事で対象としているバージョン0.5.3は結構古いので注意してください。 その他の割りと新しい情報は Backbone.js Advent Calendar 2012 などにあります。 （追記ここまで） 予定では View の日ですが、当初の予定を変更して、今回は Backbone.js における MVC について解説したいと思います。 なお、今回の内容は、私の認識方法の紹介であり、異なる考え方をする人もいると思います。 とりあえず大事なことは「Rails の MVC と同じものだと考えてはいけない」ということです。 Backbone.js と MVC Ruby on Railsに代表される MVC アーキテクチャを採用した WEB アプリケーションフレームワーク (WAF) に慣れ親しんでいる人にとって、MVC という単語は馴染み深いものだと思います。 しかしながら、本
js->coffee移行にあたって考えたこと - Qiita
個人製作のシステムのjsをcoffeeに完全移行したのでその雑感を書きます。あくまでも個人的な感想です。感じ方は人それぞれです。 ちなみに僕は勉強を兼ねて手で移行させましたが、js2coffeeというツールを使うと自動で変換してくれるらしいです。 先に結論 coffeeの方がいいと思う。 よくある批判に「js書けばいいじゃん」というのがあるけど、極端な話、「アセンブラ書けばいいじゃん」と高級言語が出てきた頃に言ってた人と主張の方向性は似てると思う。極端すぎるけど。 jsには落とし穴がいっぱいある。慣れてもたまにはまる。varを忘れたり「関数の頭で全部のvarを列挙する」というプラクティスに従ってたら、冗長になって管理するコスト高くなったり。 coffeeを使うとそういう余計な問題を意識しなくてよくなるのはとても大きい。 しかもjsでできることの全てをcoffeeでできる。工夫が必要になる場
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
