Cache max-age = 時間ベースの依存関係
Cache max-ageは、Cache-ControlヘッダーのHTTP max-ageディレクティブに類似しています。
なぜ？
キャッシュのmax-ageは、時間に依存するキャッシュを作成するための宣言的な方法を提供します。
一部のデータは限られた期間のみ有効であり、その場合は適切なmax-ageを指定する必要があります。ただし、Drupal 8コアの場合、限られた期間のみ有効なデータはありません。通常は永続的にキャッシュし（下記参照）、無効化のためにキャッシュタグに完全に依存しています。
どのような値か？
キャッシュのmax-ageは、秒数を表す正の整数です。
キャッシュのmax-ageは個々の整数として渡されます。特定のキャッシュアイテムは論理的に1つのmax-ageしか持つことができないためです。
例：
コンテキストキャッシュ = （リクエスト）コンテキスト依存関係
キャッシュコンテキストはHTTPのVaryヘッダーに類似しています。
なぜ？
キャッシュコンテキストは、キャッシュする必要があるもののコンテキスト依存のバリアントを作成する方法を定義します。キャッシュを作成するコードが読みやすくなり、同じコンテキストのバリエーションが必要な場所ごとに同じロジックを繰り返す必要がなくなります。
例：
Cache tags = データの依存関係
Cache tagsは、Drupalによって管理されるデータへの依存関係を記述します
なぜ？
キャッシュタグは、どのキャッシュアイテムがDrupalによって管理される特定のデータに依存するかを追跡するための宣言的な方法を提供します。
これは、DrupalのようなCMS/フレームワークにとって重要です。同じコンテンツがさまざまな方法で再利用される可能性があるためです。言い換えれば：コンテンツがどこで使用されるかを事前に知ることは不可能です。コンテンツが使用される場所ではどこでも、キャッシュされる可能性があります。つまり、同じコンテンツが数十の場所でキャッシュされる可能性があります。そして、これが有名な引用につながります。コンピューター科学には、キャッシュの無効化と名前の割り当てという2つの難しい問題しかありません。つまり、コンテンツが使用されているすべてのキャッシュアイテムをどのように無効化するのか、ということです。
Cache APIはDrupal 8で大幅に改善されました。次のセクションでは、各機能について詳しく説明します。
簡単な概要については、APIドキュメントのCache APIページも参照してください。
キャッシュ可能性メタデータ
直接レンダリングされるもの、または何を表示するかを決定するために使用されるものはすべて、キャッシュのメタデータを提供します - アクセス結果からエンティティやURLまで。
キャッシュのメタデータは3つのプロパティで構成されています：
- キャッシュタグ
エンティティや設定など、Drupalによって管理されるデータへの依存関係用
- キャッシュコンテキスト
バリアント用。つまり、リクエストコンテキストへの依存関係
概要
Drupal 8のブロックは、実際には2つの別々のAPI構造で構成されており、Drupalが以前のイテレーションでサポートしていたものと同様のユーザーインターフェースを作成します。この2つのAPIは、再利用可能なスタンドアロンAPIであるBlock Plugin APIと、ブロックの配置と可視性の制御のためのDrupal 8の特定のユースケースであるBlock Entity APIです。
Block Plugin APIでのブロックの作成
モジュールのコードで定義されたブロックを作成するには、プラグインAPI、特にアノテーションベースのプラグイン検出の学習と理解が必要です。これは、Drupal 8がブロックを定義するコードを見つけるために使用するメカニズムです。
モジュールで定義されたカスタムブロックの作成には、次の手順が含まれます：
APIの機能
最も一般的に使用されないAPIから順に並べられています：
認証プロバイダーサービス
\Drupal\Core\Authentication\AuthenticationProviderInterfaceを実装し、'authentication_provider'サービスタグを使用します。
ルートの_authオプション
デフォルトの認証マネージャー（下記参照）を使用すると、開発者はルートパラメーターで_authを指定して、許可される認証メカニズムのセットを指定されたサブセットに制限できます。
例： _auth: ['basic_auth', 'cookie']
認証マネージャー
認証マネージャー（\Drupal\Core\Authentication\AuthenticationManager）は、各サービスの優先度に応じて、さまざまな認証プロバイダーサービスを呼び出します。
マネージャーは非常に複雑なユースケースのためにオーバーライドできます；99.9%の場合、デフォルトの実装で十分です。
Drupal 8は多くの新しいAPIを導入し、Drupal 7/6のAPIの一部のみを保持しています。このセクションでは、Drupal 8のAPIについて詳しく説明します。
以下のドキュメントに取り組む前に、基本事項と前提条件、およびDrupal 8.xモジュール作成ガイドを確認することをお勧めします。ここでのAPIドキュメントで前提とされる概念と用語のいくつかを説明しています。
短期集中コースでありながら実際の深みを求める場合は、Understanding Drupal 8をチェックしてください。多くの主要なD8 APIの概要が説明されています。
このドキュメントはモジュール向けです。テーマについては、Drupal 8テーマへのスタイルシート（CSS）とJavaScript（JS）の追加セクションを参照してください。
Drupal 8では、スタイルシート（CSS）とJavaScript（JS）は、モジュール（コード）とテーマの両方で同じシステム（アセットライブラリ）を通じて読み込まれます。アセットライブラリには、1つ以上のCSSアセット、1つ以上のJSアセット、および1つ以上のJS設定を含めることができます。
Drupalは高レベルの原則を使用します：アセット（CSSまたはJS）は、Drupalに読み込む必要があると伝えた場合にのみ読み込まれます。Drupalはすべてのページですべてのアセット（CSS/JS）を読み込みません。これはフロントエンドのパフォーマンスに悪影響を与えるためです。
Drupal 7との違い
開発者向けに、Drupal 7との重要な違いが2つあります：
フックは、モジュールが追加されたモジュールやDrupalコアのサブシステムと対話する方法の1つです。フックは、テンプレートファイルのプリプロセス変数（hook_preprocess()）、情報リストの変更（hook_tokens_alter()、hook_views_data_alter()）、フォームの操作（hook_form_alter()）など、さまざまなタスクに使用されます。このページには、コアによって提供されるすべてのフックがリストされています。
モジュールは独自の追加フックを定義できます。たとえば、Flagモジュールはhook_flag_options_alter()を定義しており、既存のフラグのデフォルトオプションを変更したいモジュールが使用できます。フックを定義するほとんどのモジュールは、それらのドキュメントも提供しています。このドキュメントは*.api.phpファイルにあります。