|
|
|
|
@@ -33,7 +33,7 @@ class CategoriesView(generics.CachedListRetrieveAPIView):
|
|
|
|
|
filter_backends = []
|
|
|
|
|
logger = logger
|
|
|
|
|
cache = cache
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
class SearchView(generics.CachedListRetrieveAPIView):
|
|
|
|
|
"""
|
|
|
|
|
This view lists the gallery pictures with extensive searching and filtering features. You can use this API to get the latest pictures, perform picture searches among others.
|
|
|
|
|
@@ -55,20 +55,21 @@ class SearchView(generics.CachedListRetrieveAPIView):
|
|
|
|
|
logger = logger
|
|
|
|
|
cache = cache
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### New class attributes that are used
|
|
|
|
|
```python
|
|
|
|
|
cache_prefix = defines the prefix that the module will use when saving values in the cache
|
|
|
|
|
cache_vary_on_user = defines whether keys saved in the cache are different for each user, in which case extra user information will be added to the cache prefix
|
|
|
|
|
cache_timeout_mins = the cache key timeout
|
|
|
|
|
filter_backends = the filters that you want the view to have, each can be configured with view class attributes
|
|
|
|
|
ordering_fields = if you use the OrderingFilter you must indicate what fields the user can order by, the first element is used as the default order
|
|
|
|
|
search_fields = if you use the TrigramSearchFilter you must indicate the fields to search through
|
|
|
|
|
paged = your generic view can have a pager for the user to choose pages or it can be a full listing
|
|
|
|
|
default_page_size = the default size of the pages if a user has not indicated a page size
|
|
|
|
|
logger = you should register a logger in order to get error feedback in your deployments
|
|
|
|
|
cache = the main feature of this module is automated and organized caching, you should register your cache here
|
|
|
|
|
```
|
|
|
|
|
| Attribute | Description |
|
|
|
|
|
| --------- | ----------- |
|
|
|
|
|
| cache_prefix | Defines the prefix that the module will use when saving values in the cache |
|
|
|
|
|
| cache_vary_on_user | Defines whether keys saved in the cache are different for each user, in which case extra user information will be added to the cache prefix |
|
|
|
|
|
| cache_timeout_mins | The cache key timeout |
|
|
|
|
|
| filter_backends | The filters that you want the view to have, each can be configured with view class attributes |
|
|
|
|
|
| ordering_fields | If you use the OrderingFilter you must indicate what fields the user can order by, the first element is used as the default order |
|
|
|
|
|
| search_fields | If you use the TrigramSearchFilter you must indicate the fields to search through |
|
|
|
|
|
| paged | Your generic view can have a pager for the user to choose pages or it can be a full listing |
|
|
|
|
|
| default_page_size | The default size of the pages if a user has not indicated a page size |
|
|
|
|
|
| logger | You should register a logger in order to get error feedback in your deployments |
|
|
|
|
|
| cache | The main feature of this module is automated and organized caching, you should register your cache here |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### Extras
|
|
|
|
|
The source code is similar to the django-rest-framework's generic classes and related objects, it should be eminently readable. As with the rest framework's generics multiple inheritance is used through mixing to organize the behavior of each class in a standalone setting.
|
|
|
|
|
@@ -77,3 +78,6 @@ The source code is similar to the django-rest-framework's generic classes and re
|
|
|
|
|
The problem arises in the way cache keys are created, the naive method is to just use the information from the url of the request and just save it to the cache. This creates a problem in that a request such as https://example.com/api/v1/pictures/search?search=mypic&category=mycat and a request https://example.com/api/v1/pictures/search?category=mycat&search=mypic contain the same information in their cache values. So the order of each filter or the order within the filters (such as the facet filter I made for e-commerce APIs) affects the caching behavior and creates more work for our APIs.
|
|
|
|
|
|
|
|
|
|
The way this module fixes the duplicate cache keys problem is by systematically ordering the filters through each filter's get_unique_dict method that are called in cache_mixins.py and then running the sorted_params_string utility function in the resulting dict.
|
|
|
|
|
|
|
|
|
|
# Why this instead of webserver caching
|
|
|
|
|
Using web server caching, in particular API microcaching, eg [Benefits of Microcaching](https://www.nginx.com/blog/benefits-of-microcaching-nginx/), is recommended to be used along with this library. This way the microcaching at the web server level manages the bulk of the caching while this cache that sits further back manages more flexible caching. This permits among others, runtime cache timeout configuration, handling of the duplicate cache keys problem above, more cache redundancy and more flexible and complicated network topologies for your servers.
|
|
|
|
|
|