Chapter 4: Throttling, filtering, testing, and deploying an API with Django
Understanding Throttling Classes
We are introduced to the
SimpleRateThrottle (Django Link) class. There are three options we can use
- AnonRateThrottle
- UserRateThrottle
- ScopedRateThrottle
Configuring throttling policies
The easiest way to configure throttling is to add it to the REST_FRAMEWORK dictionary in our settings.py file. You can set rates for any time period of a day or less. To use more targeted rates of throttling, you still add them to the settings file, but then you need to add a few more lines of code to the classes that need them.
Testing throttling policies
We can easily test our new polices by running code in a loop to send requests to the API. Once you receive too many requests, you will get a HTTP Code 429, and the API will send back the number of seconds, until it believes you can try again.
Understanding filtering, searching, and ordering classes
The author asks us to install two new classes
There is not a lot of knowledge in this part. The biggest warning we get is to make sure we have the database set up in the correct way to handling the filtering. (ie, make sure you only allow filtering on indexed fields)
Configuring filtering, searching, and ordering for views
We are introduced to a few new concepts of Django:
filter_fields = auto creates a filter set class
search_fields = allows us to regex to specify what to filter on
ordering_fields = indicates the fields a user can specify for ordering the result set
We can also create a new class with a bunch of different filtering item. We can use this class later in the filter_class inside our of our view.
Testing filtering, searching, and ordering
More examples of how to use the code we just wrote.
Filtering, searching, and ordering in the browsable API
This is actually just a screenshot of the webpage with the filters in place.
Setting up unit tests
We install and configure
Converage and
Django-nose. The author quickly goes over how to set these up. The big takeaway is using the converage file to ignore the parts of the code that won't be tested. For instance, the core django libraries.
Writing a first round of unit tests
The author goes over a couple of unit tests. There is one tip I disagree with. Tests do not have to stand alone as the author states. You can use the
setUp and tearDown methods to instantiate objects and destroy them. I found this
page to be very helpful for learning more about unit testing in Django. One thing to remember is that all tests must start with test_ This was a trial and error learning process for me personally. I think it should be stated by the author.
Running tests, checking test coverage
The writer shares a tip, that I think can be better explained. All tests use a separate on demand database there is no need to configure this, and it won't mess with the existing data in the database. This new test database is destroyed when the tests are done running. The author shows us two different ways to run and how to view the results and interpret them.
Improving testing coverage
Adding more test to see how coverage expands when we "cover" more lines of code. I feel like this section was a little useless. I would have preferred a more robust treatment of unit testing in django.
Understanding strategies for deployment and scalability
This chapter ends with a few details on how to deploy your shiny new app. Since these can change rapidly, there is little point to trying to document them. The big takeaway is to use pip freeze to generate a requirements.txt file for deployment. Again, though, there probably should be a little explanation on how that file is useful.
Comments
Post a Comment