Chalice & API Gateway Caching

[schnitzelK1ng]

As a feature request,

it would be great if one could specify api gateway cache settings in chalice directly per view. Currently new deployments will overwrite stage settings.

[jamesls]

Thanks for the feature request, I agree this would be good to have.

[rafnarnason]

I could really use this feature - here is one idea of the workflow - aiming to keep it consistent with the console - note the new param at the end of the app route @app.route("/programs/search/{filter}/{search_query}", methods=['GET'], cors=True, caching=['filter','search_query']) def search(filter,search_query): which corresponds to:

[dperconti]

Curious if this feature was still being considered? As of right now, it's possible to manually set caching in the UI and then manually re-deploy the stage. But, re-deploying chalice wipes those changes out.

[kyleknap]

Yes. We would still like to include this feature in Chalice. A small proposal of the interface followed by a pull request that implements the feature would be welcomed!

[newton]

The approach proposed above at https://github.com/aws/chalice/issues/324#issuecomment-366747179 is almost there - we need a way to specify the cache TTL seconds also. That makes the parameters a bit unwieldy. Maybe a new separate decorator? such as:

@app.cache(key=['param1','param2'], ttl=3600)

[kyleknap]

@newton. Yeah I suspect what @rafnarnason suggested is close as well. I also think we need to be able to handle the different parameters you could set, but instead of a new decorator I would imagine we add a new CacheConfig object sort of similar to what we have for CorsConfig in order to set these parameters. I would need to do more research into the feature, but I could imagine the feature consisting of the following:

1. Cache configuration at the entire API level (i.e. an app.api.cacheor app.api.cache_config property) as most of the configuration looks like it is done on the API Gateway stage level.
2. Additional parameters for the caching in the app.route() decorator. This would be needed for setting what parameters to use for the cache key and any other per route configurations. For this value, we would be able to overload it like we do for cors parameter as well if we are concerned about the number of cache-related parameters with a simple value (i.e. boolean or list) for the common case and a CacheConfig object for more complicated per route configurations.
3. Updates to the .chalice/config.json in order to support configuring caching from the configuration file and have it be configured per Chalice stage.

[whardier]

+1

[whardier]

Wow.. a lot of default caching is implied... just working with the deployment process with caching enabled now and I'm a little dubious.

[whardier]

I actually think this should be per view using a cache preference object.. I often decorate a function with multiple routes and having an uncached route would be ideal.

[newton]

Wow.. a lot of default caching is implied... just working with the deployment process with caching enabled now and I'm a little dubious.

It's pretty messed up and making apig caching work thru cloudformation is not coherently documented. https://github.com/newton/cloudformation-apigateway-cache-macro provides a working example

[whardier]

Wow.. a lot of default caching is implied... just working with the deployment process with caching enabled now and I'm a little dubious.

It's pretty messed up and making apig caching work thru cloudformation is not coherently documented. https://github.com/newton/cloudformation-apigateway-cache-macro provides a working example

Roger that. I'm working on a per app.route cache setting and this is obviously instrumental to that. I'm opting for per app.route rather than per function since I'm also working on a stage filter for routes (endpoints that only exist in certain stages) and removing caching on specific endpoints seemed like an obvious thing to do.

app.route('/something/{something}', cache=False, stages={'any': False, 'dev': True})
app.route('/something/{something}', cache=CacheConf(...), stages={'dev': False})
app.route('/something/nocache/{something}', cache=False, stages={'dev': False})
app.route('/somethingforsomereason/{something}', cache=AutoCacheConf(...))
def dosomething(something):
   ...

[Bento007]

Has work on this feature stopped, or does an adequate work around exist?

[reik-wargaming]

I started to use the API gateway caching feature on a Chalice project recently. It's all manually right now and it would be great to get framework support here.

[rmoskal]

This seems like a no brainer as a user!

[doukasd]

+1

[wagenertimm]

+1

[shuaimilo]

+1

[aritztg]

This would be really great. Is there any new or workaround?

[chakeega]

+1

[OkkarMin]

+1

[kapish-joshi]

We have a lot of chalice projects deployed, and this is a highly time-consuming maintenance task that we have to do manually after each deployment. The caching which is enabled on path & query parameters goes away after every deployment. It will be great if the issue is fixed or a workaround is suggested.

I've been following this discussion since last year in the hopes of finding a solution. I've been pleased with the chalice framework so far and would prefer not to switch, but I won't have an option if there isn't any solution/workaround soon.

[vibhormehta]

Agreed with all the requests above. This is a much-needed feature. I don't want to add a new database just for caching one little variable. Wondering if there's a simpler solution for this.

[olivier-keeper]

Seconded, this feature would be very useful and save us a lot of additional manual work.

[vethan]

Is this still an ongoing lack of functionality? It's a bit of a pain if so. Has anyone had any workarounds, even through using Terraform?