Consider using a web framework other than Django for performance

[Amaras]

With respect to reports by a user, it seems as though Django is too slow for a quick startup. I recommend considering a micro-framework like Flask, as it should start quicker (although we need to measure before we get the conclusion)

[adrienave]

I have to be honest: it surprised me a bit to find that this project is built in Django ; it's such an heavy framework that in my experience it is intended to be used for rather bigger projects. So yes, for such a project, I was more expecting something like Flask, or FastAPI, it's also a very well-known alternative.

Though my experience is quite limited in Python web ecosystem.

[pascalaubry]

Obviously a good idea to lighten the http server. Had a quick look at Django vs Flask vs FastAPI: migrating from Django seems really easy since the templates look very close (built-in vs jinja2 vs anything including jinja2). Any opinion on Flask vs FastAPI that could lead us to a quick choice (keeping in mind further evolutions such as HTMX)? I feel that writing web forms will be easier with pedantic, do you? @adrienave Whatever your Python experience is, it is probably longer that mine ;-)

[adrienave]

No opinion on my side, but I will try to take the time to check both options to compare them in the context of this project.

@pascalaubry What do you mean by "pedantic"? I didn't find anything connected to web forms matching pedantic, is it this Python module?

[pascalaubry]

Pydantic, sorry.

[Amaras]

Interesting find with pedantic-decorators, we could probably use that for code quality in several spots.

[adrienave]

Found by accident then haha, but looks like reputation of this module is quite non-existent... Except for this documentation we would not be able to search for issues we may encounter. But to be considered.

Regarding pydantic, ok, I never used it but looks interesting yes.

[Amaras]

Based on the idea of switching out of Django, here are two packages that are built to simplify the plumbing work between HTMX (which we plan on using, see #12) and the framework we'd use:

1. Flask-HTMX
2. FastAPI-HTMX

I'm sure there are other packages based on other frameworks (I saw Django-HTMX, for instance), so which one supports HTMX is not a blocking issue.

[adrienave]

Yes, also as far as I know HTMX is a frontend library, so anyway it could be integrated with any backend Python framework, knowing REST APIs are programming language-agnostic.

So I took some time comparing both frameworks and playing a bit with tutorial projects for each, I have some preference over FastAPI for a lot of points.

FastAPI is overall a more modern solution (cares about type hints, has some more elegant way of defining endpoints, support for auto-generated documentation etc.), probably because it's more recent, it is way faster (hence the name), has integrated validation (like you said), can easily convert stuff from/to JSON and transformation of database models/entities to validation models objects/DTO looks kinda automatic as well. I also prefer the documentation. The parts I have seen are better explained with some clean examples.

I wasn't able to find big advantages of Flask against FastAPI, looks like the main one is the seniority of Flask (meaning more community support) and the philosophy: Flask is light-weighted and encourages you to pick only the packages you need. Also Flask is already shipped with some templating engine pre-configured (Jinja2), while FastAPI is more focusing on the API side (but can still be connected to a Jinja2 templating engine).

At the end either choice would be a good one, both frameworks are neat.

I will be willing to help in this transition.

[Amaras]

Thank you very much for your detailed explanation. I think I'd like FastAPI better, while the only real advantage of Flask would be being lightweight, which is still something we look for. I'm voting for FastAPI anyway, what do you think about it @pascalaubry?

[Amaras]

From an interaction with a developer, it seems Litestar could be a replacement for FastAPI. As we didn't officially start work on FastAPI, I feel we need to consider it as well. What do we think about it?

[pascalaubry]

I agree on the need to switch to another web framework. Found FastAPI better than Flask, but then convinced by https://medium.com/@v3ss0n/litestar-2-0-a-faster-proper-fastapi-alternative-is-launching-soon-cf543a0931f8 that we should directly go to LiteStar. Any objection?

[adrienave]

I didn't know LiteStar, probably because it's something new. I like the syntax and everything it's offering.

There is just one statement we need to take into consideration. In https://docs.litestar.dev/2/#philosophy:

Litestar is not a microframework. Unlike frameworks such as FastAPI, Starlette, or Flask, Litestar includes a lot of functionalities out of the box needed for a typical modern web application, such as ORM integration, client- and server-side sessions, caching, OpenTelemetry integration, and many more. It’s not aiming to be “the next Django” (for example, it will never feature its own ORM), but its scope is not micro either.

So Litestar is not the same as FastAPI or Flask, but it's still lightweight. Not sure about what are the exact consequences of this fact.

I'm not objecting though, let's try it 👍

[pascalaubry]

Litestar replaced Django in 2.2.