How to continue making progress on API-centric engineering +++
Devs advocating for tech opportunities in backlog ++
Unlocking Cross-Squad collaboration
Unlocking collaboration +
Where to put a feature? App/Library/IDA/etc? +
Localizing on frontend or backend?
Repo ownership +
Awesomizing Courseware +
Location of edx.org specific docs that are easy to find +
Django Config - YAML paradigm vs. custom devstack in python +
In-process, cross-app APIs - how should we do this?
calling across Django apps
Often throwing around models, probably want querysets
Fat model thing that Django does - bad for this
Often end up faking API calls - make a request to yourself, invoke the view handler of the DRF view directly
An attempt at avoiding making a new code-path and to re-use the existing DRF code
No documentation on where you put functions that modify state and read state from your django app that aren't invoking views
Why do you have to invoke the views?
Is it cause there's logic in the views? Django pushes you to put logic in the views - the view is the first python code that runs, so wherever you put your logic, it's going to be somewhere under the view.
Should we be delegating to a function library?
We want to do less directly in the views, instead have the view collect data from request, delegate, and then format response
Often API patterns from DRF don't match.
Ideally: here's a serializer, it does validation and whatever else, I want to use it in many places
Views and serializers often built to work together
Models are the things we should be exposing
Needs doc so you don't query it with indexes that don't exist, for instance
Consider pagination: a thing that the caller (in python), should be a thing that you decide.
DRF should have a query set that tells you how to get the data, DRF will format it into JSON and only get the subset the user is asking for based on a standard type of pagination for a REST API.
Should be using (from python) model objects and query sets with appropriate documentation.
Validation - can be at various levels. Often at the DB level, or the model level.
Returning query sets allows them to be evaluated by the consumer at the right time, rather than presupposing that they always want it immediately executed as is.