关于正在开发中的DjangoStarter v3版本

前言

最近做的这个项目大量使用了 python 及其相关的生态，因此自然而然选择了我的 DjangoStarter 作为后端框架

之前 v2 版本是用 RestFramework 做接口的，后面我试用了一次 django-ninja 之后就喜欢这种类似 FastApi 的写接口方式

正所谓天下苦 drf 久矣，在新的 v3 版本框架中，我决定直接把整个 RestFramework 替换成 ninja

目前大部分功能都完成了，代码在主项目的 v3-alpha 分支里，等开发完成我会合并到 master 里（现在基本可用了）

另外还做了很多新功能和改进，接下来会介绍一下

关于 DjangoStarter

这个开发脚手架，最开始还是叫 DjangoRails ，名字模仿的 Ruby on Rails

后面经过重构才改成 DjangoStarter

这个脚手架起源于2020年开始的项目，当时使用 Django + RestFramework 作为后端框架，为了满足安全部门的要求，又做了很多魔改，再加上其他一些配置啥的，慢慢的就积累出了 DjangoStarter ~

这里贴一下项目介绍吧~

DjangoStarter v3 是下一代 Django 项目快速开发模板，专为提升开发效率和性能而设计。

结合了 Django 的丰富功能和 Django-Ninja 的性能、灵活、简洁特性，v3 版本旨在为开发者提供一个更加强大、简洁和高速的开发体验。

通过这个全新的框架版本，开发者能够迅速搭建起符合现代 web 应用标准的项目基础架构。

核心特性

Django Ninja 集成：采用 Django Ninja 替代传统的 Django Rest Framework，为 API 开发带来了性能优化和更简洁的编码体验。利用 Python 类型提示，自动生成交互式 API 文档，不再需要 drf-yasg 那一堆繁琐的手动配置文档，同时提升了代码的可读性和维护性。
增强的安全性：内置了多项安全功能，包括但不限于 Admin 登录验证码、IP 限制等，确保应用的安全性。
代码自动生成：v3 版本进一步优化了代码生成器，丢掉了 DRF 这个包袱，只需要定义模型，就可以生成 schema 以及 RESTFul API，还能根据定义自动创建测试用例，大大提高开发效率。
随机种子数据生成：v3 版本内置 seed 模块，支持为已有模型自动填充假数据，方便开发测试。
模块化项目结构：推出了更加模块化的项目结构设计，方便开发者根据需要添加或移除功能模块，使项目维护更为简单。
现代化前端集成：提供了对现代化前端技术的集成，以及利用 NPM 和 gulp 管理前端资源，帮助开发者打造富交互式的用户界面。
容器化支持：内置 Dockerfile 和 docker-compose.yml 配置，简化了容器化部署的过程，支持一键部署到任何支持 Docker 的环境。
详尽的文档与社区生态：提供全面的文档和指南，覆盖从项目启动到部署的每一个步骤。同时，基于活跃的 Django 开源社区，开发者可以轻松获取支持和反馈。

关于v3版本

OK，终于说回正题

这次重构v3版本最主要的原因是把 RestFramework 替换成 ninja

然后也做了一些新的功能

比如：

新的自动代码生成功能
完善了单元测试和集成测试，搭配代码生成，可以为每个应用自动生成 crud 的测试用例
随机种子数据，目前使用 faker 实现假数据，打算进一步实现类似 EFCore 的种子数据机制，使假数据更自然
新的登录接口
多种第三方登录接入（目前接了微信、小程序、企微）
使用 tailwindcss 替换 bootstrap 实现前端（只是一些简单的后台展示，还是以 API 为主）
拆分 settings 配置，像 AspNetCore 那样支持多个环境配置
更换了包管理器

目前大概就这些吧

后面有用到什么新的再一步步加入

代码生成

一直没有好好介绍一下 DjangoStarter 框架的具体实现

代码生成这块其实也不复杂，包名是 django_starter.contrib.code_generator

主要就两个部分

分析器 - src/django_starter/contrib/code_generator/analyzer.py
生成器 - src/django_starter/contrib/code_generator/generator.py

分析器使用 django.apps.apps 提供的 get_app_config 和 get_models 来扫描已注册的所有 App

然后搭配反射（或者在 Python 中应该叫自省 inspect）来获取各个字段的信息，把搜集到的信息保存到我定义的几个对象中

然后在生成器部分，根据特定的规则，使用 jinja2 模板进行渲染~

注意要把字段的 primary_key, is_relation 这些属性拿出来，后面有用。如果是关系字段（如外键）的话，还需要把 target_field 拿出来。

大概思路就是这样，其中有很多细节的地方，本文的篇幅受限，后续我写篇文章来介绍吧。

API

使用 ninja 来写 API

不同于之前的 RestFramework ，ninja 用的是装饰器来定义路径，这个对于不喜欢 Django 配置式路由的人来说很友好

项目结构我也做了一些调整

以 demo 应用为例

每个 model 都在 apis 下单独创建一个 package，单独有 apis.py 和 schemas.py 代码，这样不会把所有代码逻辑混在一起

PS：后续如果我转向使用 FastApi，也可以用这个思路来组织项目

 demo

 ├─ tests

 │  ├─ __init__.py

 │  ├─ test_music_album.py

 │  ├─ test_music.py

 │  ├─ test_movie.py

 │  └─ test_actor.py

 ├─ migrations

 │  ├─ __init__.py

 │  └─ 0001_initial.py

 ├─ apis

 │  ├─ music_album

 │  │  ├─ __init__.py

 │  │  ├─ schemas.py

 │  │  └─ apis.py

 │  ├─ music

 │  │  ├─ __init__.py

 │  │  ├─ schemas.py

 │  │  └─ apis.py

 │  ├─ movie

 │  │  ├─ __init__.py

 │  │  ├─ schemas.py

 │  │  └─ apis.py

 │  ├─ actor

 │  │  ├─ __init__.py

 │  │  ├─ schemas.py

 │  │  └─ apis.py

 │  └─ __init__.py

 ├─ __init__.py

 ├─ views.py

 ├─ models.py

 ├─ apps.py

 └─ admin.py

坑点

要说的话，ninja 这种比较新的库，还是有一点点坑的地方的

有些文档不够详细
URL reverse 功能不够好用，只能在 NinjaAPI 对象配置 urls_namespace ，下面的各级 router 都不能配置 urls_namespace，我只能对下面的接口用 url_name='demo/movie/list' 这种形式的命名
ModelSchema 对外键的支持有限，对于输入的 schema ，不能在 Meta.fields 里配置这个外键字段，需要自己单独写出来，这点对于自动生成代码来说有点麻烦，不过我已经解决了

种子数据/假数据

这个可以叫 seed data ，也可以叫 mock data

在开发测试中很有用，不用手动去添加各种数据

包名是 django_starter.contrib.seed

一开始我是找到了一个叫 django-seed 的库，可以实现种子数据的生成

不过这个包已经年久失修，好几年没更新了

我试了一下，运行起来居然还依赖 PostgreSql 的库？！

就离谱，不应该和数据库无关的吗……

算了，我自己写得了，又不难

Python 生态就是好，Faker 库用来生成随机假数据很好用

主要代码在 src/django_starter/contrib/seed/seeder.py 文件里

就是根据不同的字段类型，使用不同的假数据方法

坑点：外键

其中外键字段会比较坑，需要做一些特殊处理

related_model = field.related_model

# Ensure there is at least one instance of the related model

related_instance = related_model.objects.order_by('?').first()

if not related_instance:

  related_instance = related_model.objects.create(**self.seed(related_model))

# Set the foreign key ID field

fake_data[field.attname] = related_instance.pk

settings 拆分

早就对 Django 的配置 settings.py 不爽了

项目一大，这个文件就乱七八糟又臭又长

而且还不支持多环境切换，得自己写一堆逻辑去判断不同环境

之前版本中，我是把几个主要的配置拆分成不同文件，然后在 settings.py 里引用

现在我用上了 django-split-settings 这个包，瞬间舒服了

来看看现在的 config 目录

 config

 ├─ settings

 │  ├─ environments

 │  │  ├─ __init__.py

 │  │  ├─ testing.py

 │  │  ├─ production.py

 │  │  ├─ local.py.template

 │  │  └─ development.py

 │  ├─ components

 │  │  ├─ __init__.py

 │  │  ├─ simpleui.py

 │  │  ├─ rq.py

 │  │  ├─ ninja.py

 │  │  ├─ logging.py

 │  │  ├─ django_starter.py

 │  │  ├─ database.py

 │  │  ├─ csp.py

 │  │  ├─ cors.py

 │  │  ├─ common.py

 │  │  ├─ captcha.py

 │  │  └─ caches.py

 │  └─ __init__.py

 ├─ __init__.py

 ├─ wsgi.py

 ├─ urls_root.py

 ├─ urls.py

 ├─ env_init.py

 ├─ asgi.py

 └─ apis.py

可以看到现在 settings 变成了一个 package

各种配置拆分出来分散到 components 下面

然后不同的环境又放到 environments 下面，可以覆盖前面定义的配置

很好的解决了之前的几个痛点

更换包管理器

原本就直接使用 pip ，搭配 requirements.txt 来管理依赖

这个方式的优缺点我就不多说了

这次换成 pdm ，总算有点现代包管理器的感觉了

PS：其实我之前还用过 poetry ，不过偶尔会遇到一些奇奇怪怪的问题，弃了~

小结

大概就这些吧，后面有什么新的想法我再来更新

还有其中几个关键的更新我可能会单独写文章来详细介绍~