How and why GraphQL will influence the Sourcehut alpha

The author says that he has soured on Python for “serious, large projects”. While it’s clearly personal opinion, and that’s fair enough , I can’t help but think his choice of framework hasn’t helped him and has likely caused significant slowdown when delivering features.

Looking through some of the code for Sourcehut, there’s an insane amount of boilerplate or otherwise redundant code[1]. The shared code library is a mini-framework, with custom email and validation components[2][3]. In the ‘main’ project we can see the views that power mailing lists and projects[4][5].

I’m totally biased, but I can’t help but think “why Flask, and why not Django” after seeing all of this. Most of the repeated view boilerplate would have gone ([1] could be like 20 lines), the author could have used Django rest framework to get a quality API with not much work (rather than building it yourself[6]) and the pluggable apps at the core of Django seem a perfect fit.

I see this all the time with flasks projects. They start off small and light, and as long as they stay that way then Flask is a great choice. But they often don’t, and as the grow in complexity you end up re-inventing a framework like Django but worse whilst getting fatigued by “Python” being bad.

1. https://git.sr.ht/~sircmpwn/paste.sr.ht/tree/master/pastesrh...

2. https://git.sr.ht/~sircmpwn/core.sr.ht/tree/master/srht/emai...

3. https://git.sr.ht/~sircmpwn/core.sr.ht/tree/master/srht/vali...

4. https://git.sr.ht/~sircmpwn/hub.sr.ht/tree/master/hubsrht/bl...

5. https://git.sr.ht/~sircmpwn/hub.sr.ht/tree/master/hubsrht/bl...

6. https://git.sr.ht/~sircmpwn/paste.sr.ht/tree/master/pastesrh...

Exactly agreed. I basically only use Flask for things I want to explicitly be single-file these days. For anything larger, I reach for Django, because I know that if I need at least one thing from it (and I always need the ORM/migrations/admin), it will have been worth it.

My current favorite way of building APIs is this Frankenstein's monster of Django/FastAPI, which actually works quite well so far:

https://www.stavros.io/posts/fastapi-with-django/

FastAPI is a much better way of writing APIs than DRF, I wish it were a Django library, but hopefully compatibility will improve as Django adds async support.

I built the backend for my knowledge-base platform[0] using Flask originally, but performance was definitely a struggle so I rewrote the whole thing with FastAPI. Have definitely seen a serious performance bump from that switch, and currently am quite happy with it. Many of our users are actually impressed with how fast everything is on the platform.

I still want to rip out SQLAlchemy ORM and replace it with pure SQL via `asyncpg`, as SQLAlchemy ORM is not async and that causes a bunch of extra switching in the backend that certainly doesn't help eek out more perf, but at the moment it's a bit too much effort and users are happy.

Scaling is handled by just throwing more instances of the application at the problem, behind a load-balancer.

[0] https://supernotes.app