サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Switch 2
mizumotok.hatenablog.jp
GraphQLであるオブジェクトの配列をとってくるときにページネーションをしたいというユースケースはよくあります。GraphQLではページネーションのベストプラクティスとしてカーソルベースを取り上げています。この記事ではカーソルベースのページネーションの仕組みとgraphql-rubyでのカーソルベース、オフセットベース両方に対応したページネーションの実装方法について解説します。 GraphQLのページネーション ページネーションのパターン カーソルベースページネーションを実現するConnection Type graphql-rubyでのページネーション カーソルベース オフセットベース 件数表示 まとめ GraphQLのページネーション ページネーションのパターン GraphQLでは要件にあわせてページネーションを実装して構わないのですが、3パターンが考えられます。 オフセットベース:
SPA認証トークンをどこに保存するかは論争が絶えません。localStorageやCookieがよく使われますが、Auth0は違う方法を採用しています。この記事では、Auth0のトークン管理の方式を理解でき、トークン管理上のセキュリティへの理解を深めることができます。 SPAの認証トークンをどこに保存するか ブラウザでトークンを保存できる場所 保存場所の比較 メリット・デメリット Auth0のアプローチ トークンはインメモリに保存 OpenID Connect準拠とトークン取得のUI/UXの悪化回避を両立 Auth0のjsライブラリ ログイン アクセストークンの(再)取得 図解 ログイン アクセストークンの(再)取得 自サービス内の認証だけのもっと簡易な構成 ログイン IDトークン取得 まとめ SPAの認証トークンをどこに保存するか React やVueで認証付きSPA(Single Pa
DynamoDBは高速でスケーラブルでとても便利なデータベースです。便利なのですが、テーブル設計にはRDBMSのノウハウをそのまま使えません。例えば、DynamoDBではテーブルを1つだけにすることが推奨されています。テーブルを1つだけにする設計手法について考えてみましょう。 DynamoDBの特長 できるだけ少ないテーブル数で 1つのテーブルでの設計例 データの収集 クエリの洗い出し 1つのテーブルにする クエリーにあわせてセカンダリーインデックス 設計を汎用的に まとめ DynamoDBの特長 DynamoDBはAWS(アマゾンウェブサービス)で提供される、とても便利なNoSQL データベースサービスです。高速なパフォーマンスとシームレスなスケーラビリティが特長です。 RDBMSではディスク容量が足りなくなったりしたら、基本的にはディスクを増やす等の「スケールアップ(リソースを一箇所に
DynamoDBではテーブルを1つだけにすることが推奨されています。前回の投稿ではDynamoDBのテーブルを1つだけにする設計のコツを具体例を元に考えてみました。今回はどんな場合にでも通用するような汎用的な手法を考えてみます。 mizumotok.hatenablog.jp エンティティにIDを追加 隣接関係のリスト設計パターン クエリの洗い出し グローバルセカンダリインデックスの多重定義 残りの項目 テーブル1つにする設計の汎用的手法 まとめ エンティティにIDを追加 エンティティにはユニークなIDを持たせるのが普通です。 前回の例にIDを持たせたデータは以下のようになります。 Artistテーブル ID ArtistName CarrerStart 1 David Bowie 1962 2 Bryan Adams 1975 3 Steely Dan 1972 Songテーブル ID
このページを最初にブックマークしてみませんか?
『mizumotok.hatenablog.jp』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く