feat(apigateway): add separated async apigw package

[gi0baro]

SSIA

Depends on: getsentry/pypi#2155

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 246c26a. Configure here.}

[cursor]

Django SQL %% escapes not unescaped for asyncpg

Low Severity

pgq_from_djq converts Django's %s placeholders to asyncpg's $N format but doesn't unescape %% to %. Django's sql_with_params() escapes literal % as %% (for psycopg2 compatibility). Since asyncpg doesn't interpret %%, any query containing literal % (e.g., LIKE patterns) would send doubled %% to PostgreSQL, producing incorrect results.

 

^{Reviewed by Cursor Bugbot for commit 246c26a. Configure here.}

[vgrozdanic]

Can't we do the same with async Django view and async ORM?

I am a bit worried with introducing new dependencies just for this, if the same thing could be achieved with Django.

This will be hard to maintain in the long run, especially if you decide to move on or you no longer want to maintain emmett55 :)

[untitaker]

same as vjeran. why do we add this entirely separate service into this repo to begin with?

[gi0baro]

@vgrozdanic @untitaker sorry, the description lacks a lot of context.

We've already tried to use Django in ASGI with async views (implemented in #111307), but after ~1 mo of eval with a single pod, it turns out it's not feasible for production usage. Main issues observed in this timeframe were:

• very high avg CPU load
• unmanageable memory leaks (basically having workers reaching max RSS every minute)

This was mainly discussed with @getsentry/sre-production-engineering and @markstory, the idea is to launch a separated deployment with this reachable only from canaries with a specific set of headers, and monitor the actual behavior for few weeks before taking a decision on whether this is feasible or not.

The emmett55 choice doesn't have to be definitive here, it simply was the quickest way for me to have a MVP version ready to test (@vgrozdanic I've maintained this for the last 10+ years, don't see why I should stop). It can be relatively easy swapped to any other web async framework (eg: starlette or blacksheep), but ideally we should eval that once we have metrics on this.

[vgrozdanic]

Had a chat with Gio offline, approving to unblock him with testing of async proxy. This will not be run in a production, and it's more of a PoC than the real final thing.

We'll also explore the way to do this with Django and not rely on additional dependencies, but this will primarly be used to see if we can have an async proxy that will work end-to-end

[markstory]

I also don't like the addition of another web-framework. It adds complexity and redundancy that we should be avoiding given the scope and complexity of this application already.

It can be relatively easy swapped to any other web async framework (eg: starlette or blacksheep), but ideally we should eval that once we have metrics on this.

Do we really need another async runtime though? Django has asgi support, and I think the previous implementation had enough sync/async bridge points that we aren't really comparing similar solutions. Also if we're switching frameworks again, any metrics we collect will need to be re-done.

I'm also surprised to see this getting approved and merged without any automated tests ☹️

[vgrozdanic]

Django has asgi support, and I think the previous implementation had enough sync/async bridge points that we aren't really comparing similar solutions

I agree, I talked about this with Gio as well, we can build a proper async proxy with Django as well

I'm also surprised to see this getting approved and merged without any automated tests

I see your point, and agree with you. From my talks with Gio, this will only be used to verify end-to-end that this is possible to do and that it will behave the way we expect it, so for me it was ok to let it live here as a temporary PoC in a separate app.