GraphQLの特徴を分解する ~API インターフェース・Universal BFF・API Gateway~ - Qiita
GraphQLはWeb APIを構築するためのとても強力なアプリケーション（仕様）ですが、多面的な特徴を持つためにすぐに理解しづらいところがあるのかなと思ってます。そのためこれまでにいくつか記事を書いてきました。 GraphQLはサーバーサイド実装のベストプラクティスとなるか GraphQLの全体像とWebApp開発のこれから 今回もGraphQLの解説になりますが、今回は特徴を整理し、手短に見ていきたいと思います。GraphQLの理解につながれば幸いです。 GraphQLの特徴を３つに分ける GraphQLの特徴を分けると大きく3つに分かれると考えます。(プラスでエコシステム） APIインターフェスとして Universal BFFとして API Gatewayとして (エコシステム) それぞれ見ていきます。 APIインターフェースとしてのGraphQL GraphQLの最も目立つ部分で
GraphQLの全体像とWebApp開発のこれから - Qiita
TL;DR GraphQLはクライアント側とサーバー側の双方の複雑化を解決するために利用されてる フロントエンドにとってGraphQLはHTTP上で動く信頼できる唯一のリソースとして振る舞う フロントエンドの状態管理のベストプラクティスとしてのApollo Client クライアントファーストなAPI, GraphQLはWeb APIのベストプラクティスになり得る クラシックアプリケーションを改修することなくGraphQLとモダンフロントエンドで今どきのアプリを作れる はじめに GraphQLは非常に良く出来たソフトウェア(の仕様)ですが、複数の側面を持つことからすぐに理解することが難しくまだ日本ではあまり受け入れられていない印象があります。GraphQLを端的に何と言われると "全てのフロントエンドのためのAPI BFF" なのですが、それだけで理解出来る人はなかなか居ないように思います
dev.toがなぜinsanely fastを実現出来ているか - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? INSANELY FAST Qiitaを読んでる人なら https://dev.to をほとんどの人が見たはず。見てない人は見てきてください、速すぎて驚くはず。またmizchiさんがdev.toに書いた なぜ dev.to がこんなにも速く、こんなにも自分にとって感動的なのか - dev.to を見た人も多いと思う。個人的にHeroku, Railsを採用してここまで爆速なサイトを構築出来ていることは今までの常識を覆す衝撃な出来事だった。こんな新しい発見をもたらしてくれたdev.toには本当に感謝してる。自分もこんなサイト作ってみたいな
macOSでディスプレイ1枚で作業する技術 - Qiita
これが自分が使っている設定です。メインブラウザのSafariは1, エディタ系は2, ターミナルは3, 開発ツールは4, Chromeは5, 6~8は自由に使うスペース、9はSlack, iTunesは10, FinderやSkitchなど他のアプリと合わせて使うものはAll。2つのアプリケーションを並べて使いたい時は空いているスペースにアプリケーションを持って行くようにしています。これは割り当ててる対応表覚えるというよりは、1つのデスクトップに複数のアプリケーションがたくさんある状態を防ぐのと、どんなときでもctrl+1を押せばSafariが開くという安心感を得るだけでも効果があります。 まとめ 再掲: ショートカットキーでアプリをバシバシ変えれます 以上の設定を行うことでディスプレイ1枚でもアプリケーションの切り替えコストが低くなって作業しやすくなります。普段⌘+tabで遷移もよくやっ
CapybaraのJSテストがrandom failする - Qiita
Rspec/Capybara で poltergeist や capybara-webkit を使ってJavascriptを含めたテストを行っている場合にランダムにテストが失敗することがある。(Random fail) ###主な原因の一つは テストの実行中にAjaxを発生させてAjaxが完了する前にテストが終了し次のテストが同じDBを参照しようとした時に起こる。 この問題の一つの解決策は Ajaxが終了していることをテストの最後に確認すること。 THOUGHTBOT, INC. の記事に一つの解決策を紹介している。 ソースコードはこちら # spec/support/wait_for_ajax.rb module WaitForAjax def wait_for_ajax Timeout.timeout(Capybara.default_wait_time) do loop until
Turbolinksをオフしないためにやった事 - Qiita
fetchReplacement失敗時は再度レンダリングされ, landingの状態になる。 よく出てくるおまじない $(document).on 'ready page:load', -> これはjqueryが提供する'ready'とTurbolinksが提供する'page:load'の両方で定義すること。 非Turbolinks遷移時は'ready'で発火。 Turbolinks遷移時は'page:load'で発火の両方をカバーするという意味。 Turbolinksをサポートしていないブラウザでも'ready'が発火するので安心。 jquery-turbolinks gem 'ready'triggerにpage:loadを追加してくれる機能を提供。 Trigger tips 通常、page:changeでaddEventListenerしてはいけない。 fetchHistoryの際に
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
