Is this 2015?

Looks like last week was coding week, current one is marketing week.

We did the same for our app as well. I wrote a little library to make it as simple as FastAPI to generate swagger specs - you can try it out - https://github.com/sleeksky-dev/alt-swagger .

> Python async sucks

I always find this line of thought strange. It's as if the entire team hinges their technical decision on a single framework, when in reality it's relatively easy to overcome this level of difficulties. This reminds me of the Uber blunder - the same engineer/team switched Uber's database from MySQL to Postgres and then from Postgres to MySQL a few years later, both times claiming that the replaced DB "does not scale" or "sucks". In reality, though, both systems can work very well, and truth be told, Uber's scale was not large enough for either db to show the difference.

I like mikro orm - cool to see you use that. I do prefer django however.

I see express as the backend. Why not nestjs? And are you using openapi at all for generating your frontend client?

What i've discovered is - any backend + orm should expose an openapi spec'd backend... and your frontend can autogen your client for you. Allows you to move extremely quick with the help of ai.

Should be "Why we migrated from Django to Node.js".

Answer: Because Django doesn't support async by default.

Do yourself a favor and use Elixir. Elixir has almost the same top libraries from Python you need to work with AI. As a matter of fact, the Elixir versions are far less fragile and more reliable in production use cases. I documented my journey of writing an AI app using Elixir and listed out the top libraries you can use, especially if you're coming from Python:

https://medium.com/creativefoundry/i-tried-to-build-an-ai-pr...

If we ignore the ML/AI/array libs, where Python shines, the core development has really done nothing much for it since 3.0.

Despite MS, Guido and co throwing their weight, still none of the somewhat promised 5x speedup across the board (more like 1.5x at best), the async story is still a mess (see TFA), the multiple-interpreters/GIL-less is too little, too late, the ecosystem still doesn't settled on a single dependency and venv manager (just make uv standard and be done with it), types are a ham-fisted experience, and so on, and so forth...

> You gotta write sync_to_async and async_to_sync everywhere.

I have a a simple wrapper that allows you write once and works for both sync/async https://blog.est.im/2025/stdout-04

> We did this so we can scale.

lol sounds more like a bunch of front end developers who don’t know what they are doing wanted to use a language they use on the front end on the backend.