Arch Lunch: 2019-09-26

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 specific docs that are easy to find +
  12. 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.