2019-03-25 10:25:05 +00:00
|
|
|
from flask import abort, has_request_context, request
|
2016-10-13 17:05:37 +01:00
|
|
|
from flask_login import current_user
|
2017-12-28 10:05:54 +00:00
|
|
|
from notifications_python_client import __version__
|
2019-03-25 10:25:05 +00:00
|
|
|
from notifications_python_client.base import BaseAPIClient
|
2020-06-22 09:39:32 +01:00
|
|
|
from notifications_utils.clients.redis import RequestCache
|
|
|
|
|
|
|
|
|
|
from app.extensions import redis_client
|
|
|
|
|
|
|
|
|
|
cache = RequestCache(redis_client)
|
2016-04-15 11:08:19 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
def _attach_current_user(data):
|
2016-08-11 14:20:43 +01:00
|
|
|
return dict(
|
|
|
|
|
created_by=current_user.id,
|
|
|
|
|
**data
|
|
|
|
|
)
|
2016-11-30 17:00:42 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
class NotifyAdminAPIClient(BaseAPIClient):
|
Add Redis cache between admin and API
Most of the time spent by the admin app to generate a page is spent
waiting for the API. This is slow for three reasons:
1. Talking to the API means going out to the internet, then through
nginx, the Flask app, SQLAlchemy, down to the database, and then
serialising the result to JSON and making it into a HTTP response
2. Each call to the API is synchronous, therefore if a page needs 3 API
calls to render then the second API call won’t be made until the
first has finished, and the third won’t start until the second has
finished
3. Every request for a service page in the admin app makes a minimum
of two requests to the API (`GET /service/…` and `GET /user/…`)
Hitting the database will always be the slowest part of an app like
Notify. But this slowness is exacerbated by 2. and 3. Conversely every
speedup made to 1. is multiplied by 2. and 3.
So this pull request aims to make 1. a _lot_ faster by taking nginx,
Flask, SQLAlchemy and the database out of the equation. It replaces them
with Redis, which as an in-memory key/value store is a lot faster than
Postgres. There is still the overhead of going across the network to
talk to Redis, but the net improvement is vast.
This commit only caches the `GET /service` response, but is written in
such a way that we can easily expand to caching other responses down the
line.
The tradeoff here is that our code is more complex, and we risk
introducing edge cases where a cache becomes stale. The mitigations
against this are:
- invalidating all caches after 24h so a stale cache doesn’t remain
around indefinitely
- being careful when we add new stuff to the service response
---
Some indicative numbers, based on:
- `GET http://localhost:6012/services/<service_id>/template/<template_id>`
- with the admin app running locally
- talking to Redis running locally
- also talking to the API running locally, itself talking to a local
Postgres instance
- times measured with Chrome web inspector, average of 10 requests
╲ | No cache | Cache service | Cache service and user | Cache service, user and template
-- | -- | -- | -- | --
**Request time** | 136ms | 97ms | 73ms | 37ms
**Improvement** | 0% | 41% | 88% | 265%
---
Estimates of how much storage this requires:
- Services: 1,942 on production × 2kb = 4Mb
- Users: 4,534 on production × 2kb = 9Mb
- Templates: 7,079 on production × 4kb = 28Mb
2018-04-06 13:37:49 +01:00
|
|
|
|
2019-01-29 11:12:33 +00:00
|
|
|
def __init__(self):
|
|
|
|
|
super().__init__("a" * 73, "b")
|
|
|
|
|
|
2018-02-09 15:03:32 +00:00
|
|
|
def init_app(self, app):
|
|
|
|
|
self.base_url = app.config['API_HOST_NAME']
|
|
|
|
|
self.service_id = app.config['ADMIN_CLIENT_USER_NAME']
|
|
|
|
|
self.api_key = app.config['ADMIN_CLIENT_SECRET']
|
|
|
|
|
self.route_secret = app.config['ROUTE_SECRET_KEY_1']
|
|
|
|
|
|
2016-11-30 17:00:42 +00:00
|
|
|
def generate_headers(self, api_token):
|
|
|
|
|
headers = {
|
|
|
|
|
"Content-type": "application/json",
|
|
|
|
|
"Authorization": "Bearer {}".format(api_token),
|
2018-02-09 15:03:32 +00:00
|
|
|
"X-Custom-Forwarder": self.route_secret,
|
2016-11-30 17:00:42 +00:00
|
|
|
"User-agent": "NOTIFY-API-PYTHON-CLIENT/{}".format(__version__)
|
|
|
|
|
}
|
|
|
|
|
return self._add_request_id_header(headers)
|
|
|
|
|
|
|
|
|
|
@staticmethod
|
|
|
|
|
def _add_request_id_header(headers):
|
|
|
|
|
if not has_request_context():
|
|
|
|
|
return headers
|
2018-08-14 12:00:23 +01:00
|
|
|
headers['X-B3-TraceId'] = request.request_id
|
2018-08-14 18:12:06 +01:00
|
|
|
headers['X-B3-SpanId'] = request.span_id
|
2016-11-30 17:00:42 +00:00
|
|
|
return headers
|
2016-12-09 15:44:58 +00:00
|
|
|
|
|
|
|
|
def check_inactive_service(self):
|
|
|
|
|
# this file is imported in app/__init__.py before current_service is initialised, so need to import later
|
|
|
|
|
# to prevent cyclical imports
|
|
|
|
|
from app import current_service
|
|
|
|
|
|
|
|
|
|
# if the current service is inactive and the user isn't a platform admin, we should block them from making any
|
|
|
|
|
# stateful modifications to that service
|
2018-07-20 08:42:01 +01:00
|
|
|
if current_service and not current_service.active and not current_user.platform_admin:
|
2016-12-09 15:44:58 +00:00
|
|
|
abort(403)
|
|
|
|
|
|
|
|
|
|
def post(self, *args, **kwargs):
|
|
|
|
|
self.check_inactive_service()
|
|
|
|
|
return super().post(*args, **kwargs)
|
|
|
|
|
|
|
|
|
|
def put(self, *args, **kwargs):
|
|
|
|
|
self.check_inactive_service()
|
|
|
|
|
return super().put(*args, **kwargs)
|
|
|
|
|
|
|
|
|
|
def delete(self, *args, **kwargs):
|
|
|
|
|
self.check_inactive_service()
|
|
|
|
|
return super().delete(*args, **kwargs)
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
class InviteTokenError(Exception):
|
|
|
|
|
pass
|