Understanding Connexion’s intended use cases and throughput characteristics

[mehdihasan]

Hi team,

We’re currently using the spec-first / Connexion framework for one of our observability pipeline ingestion APIs. The service runs on Kubernetes with HPA enabled.

During peak traffic, we’re observing that each pod can reliably handle roughly 9–10 parallel requests, but does not seem able to process more concurrent requests beyond that. As a result, handling peak load relies heavily on scaling out via HPA rather than increasing per-pod concurrency.

This made us pause and reflect, and we wanted to sanity-check our understanding with the maintainers directly.

A few questions we were hoping to get your perspective on:

Is this kind of per-pod concurrency/throughput characteristic typical or expected for a Connexion-based service?

Are there recommended configurations, deployment patterns, or tuning suggestions to increase per-pod throughput with this framework?

In your view, is Connexion a good fit for high-throughput ingestion-style workloads? If not, could you help explain why from a design or architectural standpoint?

More broadly, what kinds of use cases do you see Connexion being best suited for, and where do its strengths really shine? Conversely, what are the main trade-offs or limitations teams should be aware of?

We’re mainly trying to better understand the intended use cases and design goals of the framework, and to learn from the development team’s experience rather than making assumptions on our side.

Thanks in advance - really appreciate any insights you’re willing to share.

[chrisinmtown]

Please mention what version of connexion you're using, and whether you're using the old FlaskApp or the new AsynchApp in v3.

[mehdihasan]

Hi @chrisinmtown, thanks for your reply.

We’re using Connexion v3.2.0, and we’re running it in ASGI mode using ConnexionMiddleware (not the legacy FlaskApp).

The app is served via uvicorn (e.g. uvicorn.run(app=app, port=xxxx)).

[chrisinmtown]

Please note I am not a maintainer, and I have no experience in wrapping a third-party application with ConnexionMiddleware. My perception of Connexion is that it mostly handles parameter validation and delivery to your functions, and does not impose any kind of concurrent-request limit. I suppose the critical question to investigate here is, does the wrapped application perform any blocking non-async calls? I hope a maintainer will jump in here to ask an even better question and guide you further.

[mehdihasan]

Let me clarify a bit more.

While reading through this issue#221, I got the impression that Connexion has historically been positioned more for use cases where latency and throughput are not primary concerns, and where correctness, validation, and spec-first development matter more.

Is that still the intended positioning today, or has this changed with newer versions (e.g. v3 / ASGI support)? I’m mainly trying to understand whether our observations align with the framework’s design goals, or if we might be missing something in our setup.