Lean Coffee Topics
- Kubernetes vs. ? +++++
- In-process, cross-app APIs +++
- 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
- How to continue making progress on API-centric engineering
...
- +
- Location of edx.org specific docs that are easy to find +
- Django Config - YAML paradigm vs. custom devstack in python +
Notes
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.