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 複
新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を複数サーバで分散実行し
CircleCIを使ってbundle updateを定期実行する - Qiita
自動実行の流れ 1. CircleCIを起動する Nightly builds というAPIを使います。本来は重たいテストを夜中に1回だけ実行する、みたいな用途で使うことを意図しているのでNightly buildsという名前になっていますが、簡単な話が「外から環境変数を追加した上で、特定のブランチに対するテストを実行させる」機能です。 BUNDLE_UPDATE という環境変数を設定した上でmasterブランチをビルドするとbundle updateが実行されるようにすることにしました。以下のようなスクリプトを用意し、cronで平日の朝に自動実行するようにしています。 _project=user-name/repo-name # 適当に変える _branch=master _circle_token=$1 trigger_build_url=https://circleci.com/ap
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 を使わずに自分で書いたのかという話と、公開
Facebookみたいにtextareaの一部を強調する - Qiita
Facebookで人物を補完すると、その人物名の周りに枠が表示されて強調されますよね（gif画像参照）。 これのやり方を解説します。 TL;DR textareaの強調表示は、textareaを透明にして後ろにいい感じの背景を設置してるだけ textareaの中にDOMを入れても表示されない パッと考えるとtextareaの中にDOMツリーを入れるとそれが表示されるんじゃないか、と思うかも知れません が、ぜんぜんそんなことは無くて、そのまま文字列が表示されてしまいます。 ご存知のようにtextareaやinputは、他の要素のように子要素を表示するのではなく、自身のvalue属性の値を画面に表示する働きをします。value属性は文字列を格納するためのものなのでDOMを入れられないわけですね。 強調用のDOMを重ねあわせる textareaにはDOMをそのまま入れられないので、仕方がなく周り
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
