为你的 Django 网站增添一些魔法

处理 JavaScript 构建工具，或者说：并非所有闪闪发光的东西都是金子

构建 API 和 GraphQL，或者说：用大锤砸坚果

前端模板混用，或者说：因噎废食

一个用于 Django 的全栈框架，或者说：跳出思维定式

由 Mux 主办的 DEV 全球展示挑战赛：展示你的项目！

在某些圈子里，Django 因未能跟上现代 Web 开发的步伐而饱受诟病，无论这种批评是否正确。甚至在最近的Django 开发者调查中，一些评论也提到了这一点。就我个人而言，我认为这种评价并不完全公平（Django 为异步视图所做的所有工作正是其创新性的一个绝佳例证），然而，如何将 Django 与现代前端框架集成，目前还不太明朗。

然而，我认为大多数网站根本不需要复杂的前端框架。大多数网站并非单页应用（SPA），但开发者却要承受大型前端框架带来的臃肿和网站性能下降，而且还会增加工作量。秉承Python 之禅“简单胜于复杂”的理念，除非必要，否则我倾向于避免复杂性。

注：我所说的“前端框架”主要指的是React、Vue.js、Ember和Angular。不过，我目前也对一些较新的微框架（例如Alpine、htmx）很感兴趣，感觉它们出现的问题比我下面描述的要少。

处理 JavaScript 构建工具，或者说：并非所有闪闪发光的东西都是金子

你以前是不是也曾为Gulp、Grunt、Browserify或Webpack而苦恼？（嘘，听说Parcel能解决所有问题！哦不，等等，也许esbuild才是万能的？）当新的 JavaScript 工具链成为构建网站的“正确”方法时，你会怎么办？我可不想因为技术更新换代就浪费时间去切换工具，只为了获得一些微小的改进。我宁愿把时间花在开发应用上，而不是配置前端资源的构建方式。

每次运行 Djangorunserver管理命令时，你都喜欢启动一个 Node.js 进程来监视 JavaScript 代码的更改吗？对我来说，这只会增加开发体验的复杂性。

构建 API 和 GraphQL，或者说：用大锤砸坚果

将 Django 应用与前端框架连接的最佳实践是构建 REST API，或者最近兴起的 GraphQL。构建 API 会占用大量时间和精力，从而影响网站核心功能的改进。除非您计划同时支持移动应用，否则构建一个健壮的 REST API 需要投入大量工作。虽然Django REST Framework (DRF) 是一个优秀的库，它鼓励合理的 REST 实践，并减少了简单实现所需的代码量，但它仍然是构建在 Django 之上的另一个框架。即使是简单的实现，理解 DRF 的工作原理也可能比较棘手。

GraphQL解决了REST对象映射和查询方面的一些特殊问题，但它也存在一些与DRF相同的缺点。为每个模型创建序列化器并理解其特定的术语并非易事。此外，GraphQL的工作方式和实现方式也相对较新，存在一些细微差别。

此外，API 除了具备正常的网站功能外，通常还需要身份验证、授权、COR 和其他安全措施。

前端模板混用，或者说：因噎废食

要将前端框架集成到现有的 Django 网站中，需要进行一些额外的配置，以确保 Django 不会干扰当前使用的 JavaScript 框架，例如，不会将 Vue 的变量解释{{ }}为 Django 模板变量。虽然这并非不可能，但无疑增加了额外的处理工作。另一个复杂之处在于 Django HTML 模板和前端框架代码之间的上下文切换。Django HTML 模板通常负责引导数据，然后让前端框架处理所有繁重的工作。

另一种方法是完全跳过 Django 的 HTML 模板，直接使用你刚刚构建的全新 API。无论哪种方式，你都将放弃 Django 模板语言——一种强大且可扩展的数据转 HTML 工具。虽然 Django 不如前端框架组件那样高级或封闭，但它includes 仍然可以用来构建网站中可重用的 UI 组件。

一个用于 Django 的全栈框架，或者说：跳出思维定式

每次我开始一个新的 Django 项目时，我都会进行同样的思考，以决定如何处理网站的前端。

• 应该使用哪个CSS框架？
• 如何配置 CSS 预处理器（例如 SASS、Less 等）？
• 使用 Javascript 框架，还是简单地将一些微型库和原生 Javascript 代码拼凑在一起？
• 创建 REST API？搭建 GraphQL？

对于其中一些问题，我有一些第三方应用程序，可以从一个项目复制到另一个项目，它们大多都能正常工作，但这很复杂。

我喜欢 Python 和 Django 的一点就是它们“开箱即用”的设计理念。我知道 Django 已经构建了一个集成化、稳定且安全的平台，用于构建服务器端网站。我不想为了获得现代化的网站体验而去做其他决定——我只想专注于创作，而不是费力地进行各种配置。

我一直很羡慕其他服务器端框架的开发者们解决同样的问题，比如Laravel（一个 PHP Web 框架）中的Livewire和 Elixir Web 框架中的LiveviewPhoenix。所以，就像其他所有不愿放弃自己偏爱语言的“不讲道理”的开发者一样，我心想：“用 Django 实现这个功能能有多难？！”（结果……还真难！）我把 Livewire 的一小部分想法移植Livewire到 Django，利用一个周末的时间做了个原型，于是django-unicorn就诞生了。

我确实受益匪浅，因为有人比我聪明，走在我前面——能够查阅 Livewire 的技术文档和屏幕录像对我理解痛点究竟是如何Livewire解决的非常有帮助。我也从 JavaScript 部分的工作原理中汲取了很多灵感Livewire。

目前，django-unicorn专注于简洁性，能够满足现代网站 80% 的需求。虽然未来总会有需要更复杂的单页应用 (SPA) 框架的情况，但如果您只需要简单的网站交互，django-unicorn已经能够以最小的麻烦满足您的需求。

django-unicorn 0.3.0 版本已经提供了基本构建模块，但我仍在完善细节并添加更多功能。文档也在不断完善中，我会逐步添加，使其尽可能实用。我非常希望听到大家对这个想法以及其他有助于提升 Django 开发体验的功能的反馈。代码采用 MIT 许可证，欢迎在https://github.com/adamghill/django-unicorn/提交 PR ！

独角兽照片，摄影师：Meritt Thomas，来自Unsplash