Response caching helps your web app send data faster by saving answers to repeat requests. This makes your app quicker and uses less work from the server.
Response caching strategies in Flask
from flask_caching import Cache cache = Cache(app, config={'CACHE_TYPE': 'simple'}) @app.route('/data') @cache.cached(timeout=60) def data(): # generate response return 'Hello, cached world!'
The @cache.cached(timeout=seconds) decorator saves the response for the given time.
You need to set up Cache with your Flask app before using caching decorators.
from flask_caching import Cache cache = Cache(app, config={'CACHE_TYPE': 'simple'}) @app.route('/time') @cache.cached(timeout=30) def current_time(): import datetime return str(datetime.datetime.now())
@cache.cached(timeout=120, key_prefix='my_key') def my_view(): return 'Cached with custom key prefix'
memoize caches function results based on arguments, useful for expensive computations.@cache.memoize(timeout=50) def expensive_function(param): # some slow calculation return param * 2
This Flask app shows the current time on the homepage. The time is cached for 10 seconds, so refreshing the page within 10 seconds shows the same time. After 10 seconds, it updates.
from flask import Flask from flask_caching import Cache import datetime app = Flask(__name__) cache = Cache(app, config={'CACHE_TYPE': 'simple'}) @app.route('/') @cache.cached(timeout=10) def home(): now = datetime.datetime.now() return f'Current time is {now.strftime("%H:%M:%S")}' if __name__ == '__main__': app.run(debug=True)
Use caching carefully for data that changes often to avoid showing old info.
Simple cache stores data in memory, good for development or small apps.
For bigger apps, use Redis or Memcached for caching backend.
Response caching saves server work and speeds up your app.
Use @cache.cached to cache whole responses for a time.
Choose caching backend based on your app size and needs.
Practice
Solution
Step 1: Understand response caching
Response caching stores the output of a request so the server doesn't have to recompute it every time.Step 2: Identify the benefit
This reduces server work and makes the app respond faster to repeated requests.Final Answer:
To save server work and speed up response times -> Option BQuick Check:
Response caching = save work & speed up [OK]
- Thinking caching increases response size
- Believing caching slows down the server
- Confusing caching with access control
Solution
Step 1: Recall Flask-Caching decorator syntax
The correct decorator is@cache.cachedwith a named argumenttimeout=60to set cache duration.Step 2: Check each option
@cache.cached(timeout=60) def my_route(): return 'Hello' uses correct decorator and syntax. Options A and B usecache.cachewhich is invalid. @cached(60) def my_route(): return 'Hello' misses thecache.instance prefix.Final Answer:
@cache.cached(timeout=60) def my_route(): return 'Hello' -> Option CQuick Check:
Use @cache.cached(timeout=seconds) [OK]
- Using @cache.cache instead of @cache.cached
- Omitting the cache. prefix (@cached instead of @cache.cached)
- Using positional timeout argument
get_data() within 30 seconds?
@cache.cached(timeout=30)
def get_data():
print('Fetching data...')
return 'Data'Solution
Step 1: Understand caching effect on function calls
The first call runs the function, prints 'Fetching data...', and caches the return 'Data'.Step 2: Analyze second call within timeout
Within 30 seconds, the cached result is returned directly, so the print statement does not run again.Final Answer:
Data -> Option AQuick Check:
Cached call skips print, returns cached 'Data' [OK]
- Expecting print output on every call
- Confusing cached return with function execution
- Assuming cache misses cause errors
@cache.cached(timeout=60)
def index():
return render_template('index.html')
# Later in code
cache = Cache(app, config={'CACHE_TYPE': 'simple'})Solution
Step 1: Check order of cache setup and usage
The decorator@cache.cacheduses thecacheobject, but it is created after the function definition, socacheis undefined at decoration time.Step 2: Validate other options
Timeout as integer is valid.render_templateoutput can be cached. 'simple' cache type is valid for development.Final Answer:
Cache instance is created after using @cache.cached decorator -> Option DQuick Check:
Define cache before using decorators [OK]
- Defining cache after using it in decorators
- Thinking timeout must be string
- Believing templates can't be cached
Solution
Step 1: Understand caching by key prefix
The cache stores responses by keys. To cache per user, the key must include the user ID.Step 2: Evaluate options for key prefix
Use@cache.cached(timeout=60, key_prefix=lambda: f'user_{current_user.id}')uses a lambda returning a string with the current user's ID, ensuring unique cache per user. Use@cache.cached(timeout=60, key_prefix=lambda: request.path)uses request path only, same for all users. Use@cache.cached(timeout=60, key_prefix=lambda: request.args)uses request arguments, which may not include user ID. Use@cache.cached(timeout=60)without key_prefix uses default key, same for all users.Final Answer:
Use @cache.cached(timeout=60, key_prefix=lambda: f'user_{current_user.id}') -> Option AQuick Check:
Cache key must include user ID for per-user caching [OK]
- Using only request path for cache key
- Ignoring user-specific cache needs
- Not using key_prefix for per-user caching
Ready to prove it?
Pass the test and this pattern moves unknown
