Open melange396 opened 1 year ago
here are some more concrete examples:
flask.request
and request argument value handling:
flask.request
should not be referenced outside of endpoint handlersbefore_request
or teardown_appcontext
, etc)request
makes sense in the endpoint context, but not really beyond that..._params.py
like parse_source_signal_pairs()
and parse_time_pairs()
and etc should take an argument instead of pulling request
out of thin air
parse_blah()
do more than just parse, they also 'get' and 'validate' or even 'enforce'parse_x()
methods defined in src/server/endpoints/covidcast.py that should be in with the rest of the parse_*
methods in _params.pyextract_x()
methods in _validate.py that have near identical behaviors and should be moved into the same file as the other similar methods (and renamed)_handle_lag_issues_as_of()
in src/server/endpoints/covidcast.py:
None
" arguments, which is a complete no-op. a call is also commented out once. these can all be removed.as_of
argument (which is arguably the most complicated thing this does)set_order()
in src/server/_query.py:
get_related_signals()
in src/server/endpoints/covidcast_utils/model.py is never used
src/server/_db.py is pretty much never used
_common.py
or _config.py
TimePair
(and other similarly named classes/type-aliases/etc) have horrible names...
a number of class definitions are related but scattered around (and might even have some overlap), and could potentially be integrated:
The covidcast API server code works well, but it can be improved with an eye toward extensibility and other future changes. A number of points of potential refinement exist, including: