Next.js Cacheのアツさをシェアしたい(App Router)
sumirenです。 2023年5月5日、ついにNext.js App Routerがstableになりましたね！ おめでとうございます！！ありがとうございます！！！ 今から本番で使うのが楽しみで待ちきれません。 13.4のリリースではstableの宣言とともに、目玉機能としてServer Actionsが来ています。Data Fetch（というか、もはやData Handling的なもの）の機能の一部として、とても興味深いです。 さて、Server Actions自体の解説は他の方に任せるとして、リリースノートには以下のような一文があります。 Server Actions in Next.js have been designed for deep integration with the rest of the data lifecycle, including the Next.js
Next.js 13 の cache 周りを理解する - revalidate
Next.js 13 App Router の cache 周りを理解したい記事シリーズです。 Automatic fetch() Request Deduping revalidate ← この記事 fetchCache (後日公開) Incremental Static Regeneration / ISR Next.js では、もともとレンダリング方法のひとつとして、Incremental Static Regeneration = ISR が利用可能でした。 静的なページ生成を前提としながらも、一定間隔を超えた時点でページを再生成してくれる仕組みで、間隔は、getStaticProps の revalidate オプションで指定可能でした。 export async function getStaticProps() { const res = await fetch("https
キャッシュ動作を管理する | Firebase Hosting
Firebase Hosting は、強力なグローバル CDN を使用してサイトを高速化します。 リクエストされた静的コンテンツは CDN で自動的にキャッシュに保存されます。サイトのコンテンツを再デプロイすると、キャッシュに保存されたコンテンツは CDN 全体から自動的にクリアされ、次のリクエストまでそのままになります。 ただし、Cloud Functions サービスと Cloud Run サービスはコンテンツを動的に生成するため、特定の URL に対応するコンテンツは、ユーザーが入力した情報やユーザー ID などに応じて変わります。これを考慮するため、バックエンド コードによって処理されるリクエストは、デフォルトでは CDN でキャッシュに保存されません。 ただし、動的コンテンツのキャッシュの動作はユーザーが構成できます。たとえば、ある関数が新しいコンテンツを定期的に生成する場合は、
webpack@5で入るPersistent Cachingについて - hiroppy's site
webpack/lib/config/defaults.js 実際に使うときの設定 結論ですが、webpack.config.js へ以下のように書くことが推奨されます。 module.exports = { cache: { type: "filesystem", buildDependencies: { config: [__filename], }, }, }; あとは、各コードの設定に依存するためversion等の追加が必要になる可能性があります。 ドキュメント Other Options | webpack webpack is a module bundler. Its main purpose is to bundle JavaScript files for usage in a browser, ... 仕組み ファイルキャッシュでは以下のようにデフォルトではnode_m
HTTPキャッシュ入門の入門 – cat /dev/random > /dev/null &
ローカル・経路上のキャッシュを併用しよう キャッシュは再利用されるほどいいものです。 サイトの規模にもよるのですが、ローカルと経路上のキャッシュはそれぞれ性質が異なるため、ブラウザキャッシュだけ適切に設定しておけば経路上では不要というわけではありません。 ローカルキャッシュはキャッシュを持つクライアント自身がサイトを再訪する場合は有効ですが、キャッシュを持っていない新規クライアントには無効です。 経路上のキャッシュは新規クライアントに対してもキャッシュを返すことができるため、例えばサイトへの流入が突然増えるといった事態でも対処がしやすいです。 そのためコンテンツ次第ではありますが、ブラウザキャッシュのように特定のクライアントでしか使えないprivate cacheにするよりも、 効率を考えてローカル・経路上のどちらでもキャッシュができ、多数のクライアントで共有できるshared cache
Thread Safe な汎用オブジェクトCache - がくぞーのメモ
「DB負荷を減らしたいのでマスタテーブルはキャッシュして下さい＞＜」だとか 「ファイルIOは重いのでテンプレートはキャッシュして下さい＞＜」だとか 割と良く言われたりします。 オブジェクトのキャッシュは手軽な高速化の手段だと思われているようですが、並列性に気を使う必要性があったり、キャッシュされたオブジェクトを使用する側でも注意深く扱う必要が発生したりと、何かと不具合の温床になるので、大抵の場合なるべく別の方法を提案します。 それでも最終的にキャッシュした方がいい、という結論になるときもままあるので、Thread Safe で汎用的なCacheクラスを作成しました。 import java.util.concurrent.Callable; import java.util.concurrent.CancellationException; import java.util.concurr
ISUCON Cheat Sheet · GitHub
00_timeline.md 集合 9:00にオフィス(Sticky Fingers) 食料品は事前に用意しておく。食べ過ぎない。胃に負担をかけないようにする。 運営の櫛井さんからのメールに従って、サポートチャットと予選ポータルサイトにログインする。 ISUCON6 予選レギュレーション メール: ISUCON6 オンライン予選 当日の流れについて 今までに寄せられた質問についてまとめたFAQ ISUCON6 予選 9月18日(日) 参加者サポート用チャット ISUCON6 予選ポータルサイト http://isucon6q.songmu.org/ 10:00〜11:00 最初の1時間 11:00〜12:00 まず基本的なことをやる。 12:00〜17:00 この辺りからRedis移行に取り組む。 17:00〜18:00 最後の1時間 01_first_hour.md Why 課題の理解、
GithubActionsでのDocker BuildでCacheを効かせる方法メモ - Qiita
はじめに GitHub ActionsでDockerのコンテナをBuildするとデフォルトだとLayerのCache?がされないため、毎回Dockerfileの先頭から実行することになります（何も工夫をしないと）。 「LocalでBuildするときは(Cacheが効いて)速いんだけど、GitHub Actionsだと遅い」というのは、Buildに時間がかかる場合結構しんどいです(Twitterなどが捗ってしまう)。 色々方法があるようですが、Dockerのマルチステージビルドを使っていないなら、割と簡単にCacheを効かせられるようなので、そのメモです（主に自分用）。 ポイントは docker buildコマンドの --cache-from と --build-arg BUILDKIT_INLINE_CACHE=1 になります。また、このOptionを指定するには、BuildKitを有効に
GitHub Actionsのキャッシュは常に有効にしない方がいいかも、という話 | HAJIPY.NET
自作アプリのビルドにGitHub Actionsを使っています。Electron製アプリのmacOS・Windows・Linuxのそれぞれのビルドができるので、とても助かっています。 プライベートリポジトリのビルドなので、料金が掛かります。Linuxは1分あたり0.008ドルと安価なのですが、Windowsは0.016ドル(2倍)、macOSは0.08ドル(10倍)という価格になっています。ビルドには約10分掛かるので、1回あたり(0.008+0.016+0.08)*10=1.04ドルの費用が掛かります。開発版をナイトリービルドすると月に約30ドル掛かることになります。 なるべく費用を抑えられないかとキャッシュ機能を導入してみたのですが、微妙な効果となり、利用は見送ることにしました。この記事ではどう微妙だったのかを記載します。 キャッシュとは GitHub Actionsの標準機能で、作成
GitHub Actions でキャッシュを使った高速化 - 生産性向上ブログ
GitHub Actions Advent Calendar 2019 の 15 日目の記事です。 この記事では、GitHub Actions のキャッシュ機能について解説します。 目次 CI/CD とキャッシュ 簡単な例 (npm) 実験用リポジトリ作成 キャッシュ actions/cache Inputs と Outputs キーのマッチング順序 ビルド失敗時 キャッシュクリア 複数 OS で matrix ビルドするときのキャッシュ 言語ごとの例 アーティファクトとキャッシュの違い 制限事項 注意事項 まとめ CI/CD とキャッシュ CI/CD のビルドでは、リポジトリが依存するパッケージのダウンロードが原因でビルド時間が長くなってしまうことがよくあります。近年の CI/CD ではビルドごとに完全にクリーンな実行環境が用意され、前回のビルドでダウンロードしたファイルが持ち越されない
How do I reuse the cache from a `RUN --mount=type=cache` docker build?
I'm using the new experimental docker buildkit syntax to do a multistage build, as so: Dockerfile: RUN --mount=type=cache,target=/home/build/.build-cache,gid=1000,uid=1001 ./build bash: DOCKER_BUILDKIT=1 docker build . Works great locally. On CI I get a new docker environment every time, so no caching. I can export and import files into the env, but I don't know where the cache is located. Any ide
IPA ISEC セキュア・プログラミング講座：Webアプリケーション編 第5章 暴露対策：プロキシキャッシュ対策
第5章 暴露対策 プロキシキャッシュ対策 プロキシキャッシュへのコンテンツ残留 ブラウザとWebサーバの間には、いくつかのキャッシュメカニズムが働いていることが多い。 プロキシサーバのキャッシュ──企業等LANを運用している多くの組織体ではLANからインターネットアクセスを行う際プロキシサーバを経由して行うことが多い キャッシュサーバ─インターネットプロバイダの中には、会員のWebアクセスを円滑にする目的でキャッシュサーバを運用しているところがある これらのキャッシュメカニズムは、ブラウザからのリクエストによって得られたコンテンツをキャッシュに保持しておき、同じURLのリクエストが生じたとき、本来のWebサーバにコンテンツを取りに行かず、キャッシュの内容をブラウザに渡すものである。 このようにキャッシュは、円滑なインターネットの利用に寄与してくれる。 しかし、コンテンツによっては、ただひと
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Yarn restores cache, but does not install from it · Issue #60 · actions/cache
Varnish Cache Introductory Book