Split out strawberry packages for core functionality and support/hosting

[djfurman]

Currently, strawberry is one repo and deployment on PyPI including

• Schema generation
  • including cross-definition support with pydantic
• Resolver mapping
• Dev Server
• GraphiQL IDE/Testing
• CLI
• Transport integration
  • aiohttp
  • sanic
  • web socker subscriptions
• Server Integration
  • asgi
  • chalice (which has been largely replaced by AppSync out of the box)
  • django
  • fastapi
  • flask

Submitted for consideration, there appear to be three major components to the application

1. Schema Generation/Transpilation
2. Dev Support (local/debug server) & GraphiQL query exploration
3. Deployment integration (integration with other Python server projects to host production-grade deployment)

I believe that splitting these functions into separate repos and PyPI publications would allow for greater reuse and focused support/testing.

For example, you could bring together the dev environment/CLI with the schema creation to test a GraphQL API locally with the dev-env components only under dev dependencies.

This further ensures that you are not including a dev server's code in a prod deployment, this makes the code smaller/faster as well as innoculating the codebase from CVEs for code that was never intended to be used in a production setting anyway.

Similarly, the produciton integrations become more modular to the core strawberry schema and handler demarkation which helps keep production tests and code light with dependencies as needed. You could even use the strawberry schema to support serverless applications by building (AppSync)[https://aws.amazon.com/appsync/] config and scaffolding one or more Lambda functions with Python and using aws-lambda-powertools for Python, to scaffold all of the resources necessary for development powered by strawberry.

I know there are implications to taking this step and having your application split across PyPI especially with regression tests, but if you're aligned with architecturally classifying components, it is possible! In my opinion, this is a stronger reuse basis of the project and can simplfy many of the concerns discussed at the PyCon2022 sprint. While I realize this would be a refactor, it may pay dividents to do it prior to the release of 1.x to allow these components to iterate within their bounded context and with the interface.