Strategie buforowania

Caching is like having a local copy of a book you often read. Instead of fetching it from the library every time, you just grab it from your shelf!

For Micro Frontends (MFEs), caching is vital. It means your browser stores parts of your MFE applications (like JavaScript bundles and CSS files) locally. This drastically reduces network requests and speeds up subsequent page loads, making your app feel much faster and more responsive.

The most common type of caching you'll leverage is browser caching. When you visit a website, your browser saves static assets, so it doesn't have to download them again if you revisit or navigate within the app.

• Static Assets: JavaScript, CSS, images, fonts.
• Reduced Load Times: Subsequent visits are faster.
• Less Bandwidth: Saves data for both user and server.

Web servers use HTTP headers to tell browsers how to cache resources. The most important one is Cache-Control.

It dictates rules like how long a resource can be stored (max-age), whether it's public or private, and if it must be re-validated.

For MFE assets, you'll often see: Cache-Control: public, max-age=31536000. This tells the browser to cache the file for one year.

What happens when you update your MFE code? If the browser has an old version cached, users won't see the new features!

This is where cache busting comes in. We generate unique filenames for our MFE bundles based on their content. If the content changes, the filename changes.

• Old file: main.js
• New file: main.1a2b3c4d.js

The new filename forces the browser to download the fresh version.

Build tools like Webpack make cache busting easy. They automatically generate unique hashes for your output filenames.

Here's a common Webpack configuration snippet:

// webpack.config.js snippet\noutput: {\n  filename: '[name].[contenthash].js',\n  publicPath: 'auto',\n}

The [contenthash] placeholder ensures that the hash changes only when the file's content changes, enabling long-term caching.

A Content Delivery Network (CDN) takes caching to the next level. CDNs are networks of servers distributed globally.

When a user requests an MFE asset, the CDN delivers it from the server geographically closest to them. This dramatically reduces latency and improves load times, especially for a global user base.

• Reduced Latency: Data travels shorter distances.
• High Availability: Content is replicated across many servers.
• Scalability: Handles high traffic loads efficiently.

For hashed MFE assets, you can use the immutable directive with Cache-Control. This tells the browser that the file will never change once cached.

Cache-Control: public, max-age=31536000, immutable

This allows browsers to skip re-validation checks, providing the fastest possible subsequent loads. It works perfectly with content hashing because a change in content means a new filename.

Sometimes you need to force users to get the latest version immediately, even if their cache says it's still valid. This is cache invalidation.

With content hashing, simply deploying new bundles with new hashes handles most invalidation. For CDNs, you can often "purge" the cache for specific files or your entire application, forcing the CDN to fetch fresh content from your origin server.

Module Federation allows MFEs to share common libraries (like React or Lodash). These shared dependencies can also benefit from caching.

By configuring shared modules in Webpack, they can be bundled separately and cached independently. If two MFEs use the same version of a shared library, the user only downloads it once.

Great job! You've learned how critical caching is for Micro Frontend performance. By using browser caching with HTTP headers, content hashing for cache busting, and CDNs for global delivery, you can significantly speed up your applications.

These strategies ensure users always get the latest code quickly and efficiently. Keep exploring how to optimize your federated applications!