How does FastQL compare to Strawberry?
FastQL and Strawberry are both code-first Python GraphQL frameworks, but they differ in their architecture and design goals:
FastQL’s zero-dependency core means you can embed it in environments where adding
graphql-core is undesirable, and its single schema model avoids the split between
a code-first definition layer and a separate execution runtime.
Does FastQL really have zero runtime dependencies?
Yes. Themygenx-fastql package installs with no required third-party runtime
dependencies. All optional integrations (Pydantic, OpenTelemetry, federation) are
behind package extras ([pydantic], [opentelemetry]) and are never imported by
the core.
Is FastQL async-first? Can I use sync resolvers?
FastQL’s execution pipeline is async-first —execute, subscribe, and
execute_incremental are all async. Sync resolvers are fully supported: the engine
detects non-coroutines and calls them directly without wrapping in
asyncio.run_in_executor, so plain def resolvers add no threading overhead.
Where does the HTTP transport live?
FastQL’s core (fastql) has no transport code at all. HTTP, WebSocket, and SSE
are implemented in the framework adapters (fastql.asgi, fastql.starlette,
fastql.fastapi, etc.). This boundary means:
- The same schema works with any supported web framework.
- The development server (
python -m fastql serve) is a thin ASGI wrapper and is not suitable for production. - Framework-specific concerns (auth middleware, CORS, TLS) belong in the framework layer, not in FastQL itself.