Playground for auto-generating FastAPI apps

[elijahbenizzy]

[Short description explaining the high-level reason for the pull request]

Changes

How I tested this

Notes

Checklist

• PR has an informative and human-readable title (this will be pulled into the release notes)
• Changes are limited to a single goal (no scope creep)
• Code passed the pre-commit check & code is left cleaner/nicer than when first encountered.
• Any change in functionality is tested
• New functions are documented (with a description, list of inputs, and expected output)
• Placeholder code is flagged / future TODOs are captured in comments
• Project documentation has been updated if adding/changing functionality.

[elijahbenizzy]

Just prototyping to evaluate typed state

[elijahbenizzy]

This is a prototype, and I'm going to take a quick pause to focus on other stuff OS users are actually asking for. That said, this is what needs to get done for this to go to production:

• Fix the mess around inputs/input schema to keep backwards compatibility -- this is messy, and we have a lot of psosibilities. There should be a simpler solution here.
• Add tests for FastAPI
• Review the REST structure to be opinionated in the right way
  • Look over this: https://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api
  • E.G. /…/partition_key/{PARTITION_KEY}/application_id/{APP_ID}
• Think through API
  • Do we want users to provide an app? Graph? ApplicationBuilder?
  • What can we derive? points that require a halt/input (currently listed out, but we konw whether it has an unbound input)
• Add documentation, including caveats
  • Synchronization on app access -- locking
  • ACL integration
  • How to use
• Outline plan for actually generating code (not part of MVP, but worth ensuring we will be able to
  • E.G. burr generate --output-file ./server.py -- config ./config.py or something like that
• Add tests
  • Test specific logic for input schema
  • Test endpoint generation function
  • Test E2E, compare against actual app call