Our great sponsors
-
litestar
Production-ready, Light, Flexible and Extensible ASGI API framework | Effortlessly Build Performant APIs
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
fx-private-relay
Keep your email safe from hackers and trackers. Make an email alias with 1 click, and keep your address to yourself.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
openapi-typescript-codegen
NodeJS library that generates Typescript or Javascript clients based on the OpenAPI specification
What's the preferred Python Web Framework these days?
I've read a lot of love for Litestar (formerly Starlite), since it seems people prefer it over FastAPI, Flask, etc.
https://litestar.dev
I'll preface all of this with a couple esoteric design goals that I had in mind:
1. I actually _want_ an SPA. You might not need an SPA, if you don't need one then Vue/React/etc are overkill, etc.
2. I want to power as much of the SPA as I can using the same REST API as my core product, both for dogfooding reasons and for consolidation. Many people might argue that this is a bad idea.
---
With that in mind, some specific packages that I highly recommend:
1. Django-vite (https://github.com/MrBin99/django-vite). This makes it very easy to serve an SPA from the actual django response/request model
2. Some sort of way to get type information (if you're using TypeScript) into the frontend. I use a frankensteined system of the OpenAPI spec that django-ninja generates + openapi-typescript (https://github.com/drwpow/openapi-typescript). This means when I add, say, a new field to a response in Django, I immediately get typechecking for it in Vue ā which has been _tremendously_ useful.
3. Django-typescript-routes (a package I extracted and open-sourced!: https://github.com/buttondown-email/django-typescript-routes) which gives your front-end routing information based on the Django router.
I'll preface all of this with a couple esoteric design goals that I had in mind:
1. I actually _want_ an SPA. You might not need an SPA, if you don't need one then Vue/React/etc are overkill, etc.
2. I want to power as much of the SPA as I can using the same REST API as my core product, both for dogfooding reasons and for consolidation. Many people might argue that this is a bad idea.
---
With that in mind, some specific packages that I highly recommend:
1. Django-vite (https://github.com/MrBin99/django-vite). This makes it very easy to serve an SPA from the actual django response/request model
2. Some sort of way to get type information (if you're using TypeScript) into the frontend. I use a frankensteined system of the OpenAPI spec that django-ninja generates + openapi-typescript (https://github.com/drwpow/openapi-typescript). This means when I add, say, a new field to a response in Django, I immediately get typechecking for it in Vue ā which has been _tremendously_ useful.
3. Django-typescript-routes (a package I extracted and open-sourced!: https://github.com/buttondown-email/django-typescript-routes) which gives your front-end routing information based on the Django router.
I'll preface all of this with a couple esoteric design goals that I had in mind:
1. I actually _want_ an SPA. You might not need an SPA, if you don't need one then Vue/React/etc are overkill, etc.
2. I want to power as much of the SPA as I can using the same REST API as my core product, both for dogfooding reasons and for consolidation. Many people might argue that this is a bad idea.
---
With that in mind, some specific packages that I highly recommend:
1. Django-vite (https://github.com/MrBin99/django-vite). This makes it very easy to serve an SPA from the actual django response/request model
2. Some sort of way to get type information (if you're using TypeScript) into the frontend. I use a frankensteined system of the OpenAPI spec that django-ninja generates + openapi-typescript (https://github.com/drwpow/openapi-typescript). This means when I add, say, a new field to a response in Django, I immediately get typechecking for it in Vue ā which has been _tremendously_ useful.
3. Django-typescript-routes (a package I extracted and open-sourced!: https://github.com/buttondown-email/django-typescript-routes) which gives your front-end routing information based on the Django router.
In case you're interested, Firefox Relay uses that stack and is open source: https://github.com/mozilla/fx-private-relay/
Congrats on the release to the Django community!
If anyone is curious, I updated my Django / Docker starter kit app to use Django 5.0 at: https://github.com/nickjj/docker-django-example
It pulls together gunicorn, Celery, Redis, Postgres, esbuild and Tailwind with Docker Compose. It's set up to run in both development and production.
Simple middleware can warn you about lazy loading/N+1 queries. Most of the time people just forget it happens.
Try using: https://github.com/har777/pellet
No, as I understand it, Django project's stance on type hints is that they aren't going to be added any time soon, but they are willing to accept small PRs that are needed by external type-checkers on a case by case basis. Details here: https://github.com/django/deps/pull/65
There is a package, https://github.com/carltongibson/django-template-partials, that is basically like server-side hex-select, when there is some performance concern. Overall, I agree with you though, hx-select is going to be fine most the time.
I haven't used Elixir yet and mostly using flask in Python for work but I started with Django (and still think it's better than flask for most apps). If stuff like https://github.com/aesmail/kaffy (first thing I've found on google, never heard of it before) is on par with the Django admin, would you still use Django or Elixir and never look back?
Iād also add that if you use Typescript with an OpenAPI client generator (https://github.com/ferdikoomen/openapi-typescript-codegen) it can immensely alleviate some of the biggest pain points of seperate backend and front-end. It always used to be a major pain in the ass with the amount of overhead an API change would incur - updating documentation, postman, constant communication between backend and front-end devs, etc. Now I just npm run generate, I see new API changes in my Git client and Typescript errors for code that needs updating.
Also, using a library like Tanstack Query or Rdtk Query can almost completely eliminate manual state management, and kinda makes the whole development experience feel almost like SSR.
Related posts
- Django Ninja is a web framework for building APIs with Django
- Effortless API Documentation: Accelerating Development with FastAPI, Swagger, and ReDoc
- Killed by open sourced software. Companies that have had a significant market share stolen from open sourced alternatives.
- It's Christmas day. You wake up, run to the tree, tear open the largest package with your name on it... FastAPI has added _____?
- Django Ninja