Thanks for the feedback @perrystallings!

• release is missing the asgiref dependency

Submitted #1667 to fix this

• running AsyncApp still requires a flask install (is this intentional?)

This is indeed not intentional, you should be able to run the AsyncApp without installing Flask. Submitted #1668 to fix this.

We'll release this as a new version asap.

Thanks!

These changes have been released as 3.0.0a2.

Thanks for this! This is exactly the feedback we're looking for: real-life use cases that we need to cater to.

The AsyncApp is built on top of a Starlette Router because a Starlette App is a Router wrapped with a middleware stack. Which is what Connexion now is as well. It's a lot simpler to not have multiple middleware stacks wraped by each other. The default middleware stack of Starlette would also duplicate some of the behavior of Connexion (such as error handling), which we don't want to happen there.

I had a quick look at your links, and the good news is that the opentelemetry instrumentation also provides a generic ASGI middleware, which is exactly what Connexion 3 now enables. You should be able to plug it into the middleware stack as follows (untested):

from connexion import AsyncApp, ConnexionMiddleware
from opentelemetry.instrumentation.asgi import OpenTelemetryMiddleware

middleware_stack = ConnexionMiddleware.default_middlewares + [OpenTelemetryMiddleware]

app = AsyncApp(__name__, middlewares=middleware_stack)
app.add_api(...)

It's not completely clear yet to me what the advantage of the Starlette specific instrumentator is.

Note that if you want to pass arguments to middleware you add to the stack, you can use a partial.

from functools import partial

middleware = partial(OpenTelemetryMiddleware, *args, **kwargs)
middleware_stack = ConnexionMiddleware.default_middlewares + [OpenTelemetryMiddleware]

app = AsyncApp(__name__, middlewares=middleware_stack)

We currently use the same interface to specify middleware as Django, which allows a lot of flexibility. This is needed because the order of the middleware matters.

We might want to add an add_middleware() method similar to Starlette's to enable simple use cases though. This is something I would still consider for the 3.0 release.

We probably should at least expose the default_middlewares via the app directly instead of via the ConnexionMiddleware.

Thanks for the context! Just tested the configuration and it works!

Thanks @SpudInNZ!

As far as I'm aware, there are indeed no plans for AioHttp to support the ASGI spec, which unfortunately means connexion can no longer support it.

I see 2 possible migration paths:

• Switch to Connexion's AsyncApp. I think this should be possible if you're not heavily dependent on the AioHttp ecosystem. We're happy to help make this as painless as possible. So if you can provide feedback on the migration, we can see if there's ways for us to make this easier or at least provide documentation.
• Switch to a Connexion 2 fork such as https://github.com/athenianco/especifico by @vmarkovtsev

@RobbeSneyders

Thanks for the reply. In truth it's difficult for us to make the case for migration. However we may start new projects with the new stack.

We indeed still need to document this behavior. Working on the documentation as we speak 🙂

You can access all these objects in the request-level context by importing from connexion.context:

from connexion.context import context, operation, request, receive, scope

The request is also still available as

from connexion import request

but that is now a Starlette Request instead of a Flask one.

The pass_context_arg_name parameter has been removed, but the mechanism hasn't. So ou can no longer define the name, but you can still get the connexion context in your handler function via the hardcoded context_ parameter name.

def handler(context_)
    pass

I'm wondering if we still need this now that the context is available globally as well though.

@RobbeSneyders Not all fields are available using this method as well..

Let's say, I have my spec like this:

          multipart/form-data:
            schema:
              type: object
              properties:
                file:
                  type: string
                  format: binary
                  description: Event file to upload
                filetype:
                  type: string
                  $ref: "#/components/schemas/EventUploadType"
              required:
                - file
                - filetype

I am able to access: file but I am not able to access filetype.

Also just for context, when I am debugging, this field filetype was available in _form field of the ASGI Request till we reach this point in. code:

class AsyncParameterDecorator(BaseParameterDecorator):
    def __call__(self, function: t.Callable) -> t.Callable:
        unwrapped_function = unwrap_decorators(function)
        arguments, has_kwargs = inspect_function_arguments(unwrapped_function)

        @functools.wraps(function)
        async def wrapper(request: ASGIRequest) -> t.Any:
            request_body = self._maybe_get_body(
                request, arguments=arguments, has_kwargs=has_kwargs
            )

            while asyncio.iscoroutine(request_body):
                request_body = await request_body

            kwargs = prep_kwargs(
                request,
                request_body=request_body,
                files=await request.files(),
                arguments=arguments,
                has_kwargs=has_kwargs,
                sanitize=self.sanitize_fn,
            )

            return await function(**kwargs)

        return wrapper

Pls See the value in debugger:

But this field is not accessible in the actual post view function. I had tried passing them as arguments and also tried accessing the _form.

Anyway to overcome this?

I am also wondering if this could be related to the name of the parameter: filetype is this causing any issues?

You're right. With Swagger 2, this works since form data is defined as parameters in the specification. With OpenAPI 3, form data is defined in the body, so we pass in the whole body.

This will work:

def post(file, body):
    # body = {"filetype": "..."}

But I agree that this is not very consistent. I think we should either

• Copy the Swagger behavior for OpenAPI and pass the top level fields in separately.
  (This might impact the behavior of strict_validation as well.)
• Don't pass in the files separately for OpenAPI either, and just include them in the body

I'll have to look how this was done on Connexion 2.X before deciding on how to move forward.
CC: @Ruwann

Thanks for quick response... and helping here.... now I am able to access it from body. Posting it here so that it may help others as well.

Yes that should work. Both options mentioned above will change this interface and break your code though. But I'll keep you updated here so you can change it when the fix is released.

@Ruwann I checked and this is the same behavior as we had on Connexion 2 (see also #1679)

I would propose to go with a single body argument and include the files in there under there respective key. This is consistent with other content-types and we can still make this more user friendly in the future by providing parsing functionality (#1190).

Yes, we are aware. This is documented in the change log as a breaking change. We'll make sure to highlight this in the routing documentation again.

Thanks @RobbeSneyders! Missed that one.

We will not make it default, since it is not always desired.

Adding middleware at specific locations will become easer with #1683 which I just opened yesterday. It adds an add_middleware interface to add middleware to the stack, which supports different logical locations.

The CORS middleware needs to be inserted before the RoutingMiddleware, so you'll be able to do:

from connexion.middleware import MiddlewarePosition

app.add_middleware(CorsMiddleware, position=MiddlewarePosition.BEFORE_ROUTING)

This is great, thanks @RobbeSneyders!

This has been released as 3.0.0a5

Thanks!

Latest release is 3.0.0a6 already, which contains some additional fixes related to this functionality.

Hi @SpudInNZ,
Both @Ruwann and I had less time to spend on connexion the previous weeks, but we are still moving forward (albeit slowly), which also allows for additional feedback on the Alpha release.

We are ironing out some final issues which we want to resolve (eg. #1709) and adding documentation (#1701, #1706), which unfortunately takes a bit longer than hoped.

If people want to help, they can triage issues or help write documentation (#1531)

Hi @danderwald. Is there a reason for you to want to migrate to quart instead of the AsyncApp based on Starlets?

Hi,

pragmatic reasons :)

• one reason is that quarts api is the same as the flask one (for example for templating / globals /events / ...), so I just would need to replace the imports
• because the API is the same, my team would not need to learn a new framework
• we would be able to use concurrency (in combination with an asgi based framework/server) without much migration effort ( => to get rid of some blocking IO by exchanging requests with httpx)

Thanks @hedleyroos! Great to hear!

Let us know if you run into any issues.