<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Caching on Nalar</title>
    <link>https://nalar.dev/tags/caching/</link>
    <description>Recent content in Caching on Nalar</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Wed, 02 Sep 2026 00:00:00 +0700</lastBuildDate>
    <atom:link href="https://nalar.dev/tags/caching/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Cache Pure Work in Python with functools.cache and lru_cache</title>
      <link>https://nalar.dev/cache-pure-work-with-functools-cache-and-lru-cache/</link>
      <pubDate>Wed, 02 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/cache-pure-work-with-functools-cache-and-lru-cache/</guid>
      <description>&lt;p&gt;Caching can turn repeated expensive work into a dictionary lookup, but it can also return stale data or grow memory without bound. Python&amp;rsquo;s &lt;code&gt;functools&lt;/code&gt; module provides two convenient memoization decorators: &lt;code&gt;lru_cache&lt;/code&gt; and &lt;code&gt;cache&lt;/code&gt;.&lt;/p&gt;&#xA;&lt;p&gt;&lt;code&gt;functools.cache&lt;/code&gt; has been available since Python 3.9. It is effectively an unbounded memoization cache. &lt;code&gt;lru_cache&lt;/code&gt; adds a configurable size limit and eviction behavior.&lt;/p&gt;&#xA;&lt;h2 id=&#34;cache-functions-not-arbitrary-side-effects&#34;&gt;Cache functions, not arbitrary side effects&lt;/h2&gt;&#xA;&lt;p&gt;Memoization works best when a function behaves like a pure function: the result depends only on its arguments.&lt;/p&gt;</description>
    </item>
    <item>
      <title>HTTP Content Negotiation and Correct Vary Headers</title>
      <link>https://nalar.dev/http-content-negotiation-and-correct-vary-headers/</link>
      <pubDate>Wed, 02 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/http-content-negotiation-and-correct-vary-headers/</guid>
      <description>&lt;p&gt;One URL can sometimes represent the same resource in several formats. An API might return JSON or CSV, while a documentation endpoint might return HTML or plain text.&lt;/p&gt;&#xA;&lt;p&gt;HTTP content negotiation lets a client express which representation it can accept. The server chooses a response and tells caches which request headers influenced that choice.&lt;/p&gt;&#xA;&lt;p&gt;The second part is easy to miss: if the response changes based on a request header, shared caches need the correct &lt;code&gt;Vary&lt;/code&gt; metadata.&lt;/p&gt;</description>
    </item>
    <item>
      <title>HTTP Conditional Requests with ETag and Last-Modified</title>
      <link>https://nalar.dev/http-conditional-requests-with-etag-and-last-modified/</link>
      <pubDate>Tue, 01 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/http-conditional-requests-with-etag-and-last-modified/</guid>
      <description>&lt;p&gt;HTTP caching is not only about choosing a long &lt;code&gt;max-age&lt;/code&gt;. Applications often need clients to revalidate data because a resource can change, while still avoiding retransmitting the full representation when it has not changed.&lt;/p&gt;&#xA;&lt;p&gt;HTTP validators solve that problem. The two common validators are &lt;code&gt;ETag&lt;/code&gt; and &lt;code&gt;Last-Modified&lt;/code&gt;.&lt;/p&gt;&#xA;&lt;h2 id=&#34;freshness-and-validation-are-different&#34;&gt;Freshness and validation are different&lt;/h2&gt;&#xA;&lt;p&gt;A freshness directive can tell a cache that a response may be reused without contacting the server for a period:&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
