Lean Coffee Topics

1. Kubernetes vs. ? +++++
2. In-process, cross-app APIs +++
3. How to continue making progress on API-centric engineering +++
4. Devs advocating for tech opportunities in backlog ++
5. Unlocking Cross-Squad collaboration
6. Unlocking collaboration +
7. Where to put a feature?  App/Library/IDA/etc? +
8. Localizing on frontend or backend?
9. Repo ownership +
10. Awesomizing Courseware +
11. Location of edx.org specific docs that are easy to find +
12. 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.