我参加了2023年的DjangoCongress JP

我在2023年10月7日参加了DjangoCongress JP 2023。今年的会议地点是由Cybozu株式会社主办。

Django应用程序运维的真实情况：从问题发生到优化的路径可视化

发言人是吉田花春。

发布后必须处理问题，但因为调查所需的材料不足而感到困扰，所以希望与有相似经验的人共享信息，这是发布的动机。

我主要解释了以下改进点。

1. 使用APM（应用程序性能监控）来收集错误和日志

 

1. 利用APM来解决瓶颈问题

 

通过测量自定义指标来了解问题的根本原因

获取错误和日志

这个设计是为了解决日志消息通常不输出内容，或者虽然输出了内容但对故障排查没有帮助的情况。

• ログレベル（CRITICAL、ERROR、WARNING、INFO、DEBUG）を使い分ける

 

• APIリクエストのstart/end時にログを出力

 

5W1Hがわかるログメッセージを出力（「いつ」「どこで」「なぜ」「何が起きて」「何をすればいいのか」）

此外，据说可以使用Ruff和Flake8扩展来验证是否存在不适当的日志消息。如果出现错误或警告，将通过Sentry通知到Slack，以便快速了解原因并进行对策的考虑。

利用APM（应用性能监控）来消除瓶颈。

据称是为了了解应用的哪个部分较重而引入了以下内容。

• APM

SentryのPerformance Monitoring
DatadogのAPM

CloudWatch Logs Insightで使ったログデータの分析

スロークエリの発見

通过测量自定义指标，可以了解问题的原因。

据说，为了防止存在指标但原因不明的情况，创建自定义指标是有效的。他们使用python-json-logger将日志以JSON格式输出，并在Datadog中创建了自定义指标。

对于如何设计易于使用的设计，我们需要通过一次痛苦的经历来学习，这样基于实际经验的讨论非常有价值。

使用图形数据库创建Django应用程序的入门指南

说话者是Akinori先生。

这是关于在Django中使用Neo4j图数据库的技巧的讲解。图数据库是一种用图形表示数据关系的数据库，具有以下优点。

1. 具有应对复杂现实世界的最佳表达能力

 

具备应对未知问题的迅捷响应能力

在关系数据库中，即使存在性能问题的设计，在图数据库中也可以舒适地使用。

听说要在Django中使用Neo4j，需要使用neomodel（Neo4j的Python界面）和django_neomodel（用于在Django中使用neomodel的扩展）。根据实际的代码展示，发现模型定义的方式与使用关系数据库类似（但不会生成迁移文件）。由于也可以在admin中使用，所以基本上可以实现与使用关系数据库类似的功能。

尽管图数据库不能完全替代关系数据库，但我认为它是一种能够引发可能性的数据库，这取决于应用程序的要求。最重要的是，仅仅通过观看演示中GUI上的数据关联，就感到非常有趣。我也想自己尝试制作应用程序来进行实验。

成为中级Django开发者需要了解的事项

演讲者是Hiroki Kiyohara先生。

尽管尝试完成了Django的教程，但对于想要迈向更高层次的人，不知道该怎么做的人，这是关于技巧的讨论。
主要谈到了以下内容。

• 設計

 

• テスト

 

デプロイ

設計 (shè jì)

在开始制作之前，重要的是要具体考虑想要制作的东西。
并不是希望大家记住像DDD这样的设计方法，而是要考虑有什么功能、需要什么样的界面等内容，这就是他们所说的。
如果无法想到界面，建议参考类似服务的界面或URL结构（但要注意，明显抄袭公开服务是不好的，所以可以在个人非公开服务中模仿学习）。
设计要以模型为中心进行考虑。一旦模型确定了设计，要进行大的更改就会很困难，所以最好认真考虑。在考虑模型设计的过程中，可以考虑到与需求匹配的合适名称。

考试 shì)

首先，建议按照官方文件引入自动化测试。
同时也推荐使用第三方工具pytest-django。
另外，为了方便测试，最好不要在View中写入过多的逻辑。

部署

在部署时，必须注意以下事项，并且有一个与在本地使用应用程序时不同的视角，这是通过运行服务器命令实现的。

1. 让其能够通过互联网使用

 

1. 确保其安全使用

 

使其运行稳定，并便于中长期管理和运维

如果是有趣的应用程序，只需要先做最基本的事情，然后再慢慢学习就可以了。

网页应用程序需要记住很多东西，但是我认为首先需要公开一个能够运行的版本，积累成功经验也是必要的，所以我觉得学习的内容也需要有优先级。

Django 知识共享 – 数据库管理由不同部门负责 & 开发技巧

发言者是松野一贵先生。

在松野的工作场所，数据库分为前端和后端，而后端的数据库由另一个部门负责管理，因此无法进行迁移。

据说，为了使settings.py文件中的DATABASES同时包含前端数据库的信息和由另一个部门管理的后端数据库的信息，
对于无法进行迁移的后端数据库，他们使用inspectdb命令根据表定义来生成模型输出。

根据所述，切换Django连接数据库的方法有两种选择，选择了第二种。

1. 更改连接的数据库通过db_manager

 

通过设置数据库路由器，可以根据模型更改连接的数据库（参考链接: https://tokibito.hatenablog.com/entry/20160202/1454344534）

另外，据说由于后端数据库不使用外键的规则，需要对模型定义进行巧妙处理，您经历了相当强烈的体验。

学习数据库设计的Django迁移

演讲者是aodag先生。

由于模式更改的执行成本会根据更改内容的不同而大幅变化，因此设计成本低的执行方法就变得十分重要。

• メタデータの変更のみ→一瞬で終わる

 

• データ更新→インデックスの追加、カラムの（末尾への）追加はwrite lockがかかる

 

テーブル再構築→主キーの変更、カラム削除、カラムのデータ型変更、NOT NULL, NULL制約の変更、カラムサイズの大幅な変更はテーブルコピーがかかる

为了降低模式更改的执行成本，需要考虑以下事项。

• テーブルを小さく保ってスキーマ変更時の実行コストを低く、変更の影響範囲を小さく

正規化（第一正規化、第二正規化、第三正規化）

依存関係を簡潔なものにして、そのデータを触るDjangoアプリケーションを減らす
小さく恥ずかしがりなデータ

另外，据说设计Django应用程序时，可以参考以下内容是很好的选择。

• ユースケース駆動

 

• ドメインオブジェクト

 

オブジェクト指向設計原則(SOLID)

尽管使用了对象关系映射器（O/R Mapper），并不意味着不需要数据库和SQL的知识，所以我决定好好学习我正在使用的关系数据库。

GraphQL库Strawberry在Django项目中的应用示例：从实践中学习提示和策略。

说话者是宫下洋介先生。

这是关于在Django项目中使用Python的GraphQL库Strawberry时的经验分享。

据说Strawberry拥有基于Django模型定义GraphSQL类型的功能，因此将其整合到Django中并不困难。

他们列举了以下的理由来选择草莓。

• 開発が継続している

 

• コードファーストである

既存の実装を活かしたい
ゼロからスキーマを書くより生産性が高そう

听说在模式设计中，与REST不同的地方包括以下几点。

• 大きなAPIにすることを恐れない

現状ユースケースがなくても元モデルの全フィールドを返すTypeにしておく(もちろんセキュリティ上非公開にしたいフィールドは除外する)
クライアント側で取得するフィールドを選択できるので、大きいAPIでも問題ない

関連オブジェクトはネストさせる

関連するIDだけでなくオブジェクトそのものを返す

安易にQueryを定義せず、Typeのフィールドにすることを検討する

据说在测试方面，通过不在GraphQL层直接编写逻辑，将GraphQL层本身从单体测试的对象中排除掉。

此外，GraphSQL存在易发生N+1问题的情况，但目前尚未成为重大问题。

由于我的开发经验一直只涉及REST API，因此对GraphQL独特的见解我感到非常有趣。

闪电演讲

收尾

派对

最终

今年的DjangoCongress JP已经结束了。果然线下活动有一种线上无法比拟的独特氛围，非常有趣。

回想起20多年前刚开始志向成为一名没有IT经验的工程师时，我曾对这个行业紧密的横向联系感到惊讶。

接触到公司组织之外的人们彼此共享知识的文化，感觉就像是在许多场合拯救了我一样。

虽然在疫情中，这种流动暂时中断了，但是现在线下活动的势头又回来了，我希望年轻一代也能体验到这种氛围。

我理解有些人会有犹豫不决的心情，但是IT社区有很多持欢迎初学者态度的人，所以不用太担心，非常安全。请务必来玩啊。

顺便一提，10月27日和28日有PyCon APAC 2023。门票价格可能有点高，但是会有与价格相匹配的体验，如果时间合适的话，请务必参加！

大家辛苦了。我们明年再见！