在 Django 应用程序中初始化 GraphQL 客户端的位置答案

【问题标题】：Where to initialize a GraphQL Client inside Django App在 Django 应用程序中初始化 GraphQL 客户端的位置
【发布时间】：2020-10-04 19:00:36
【问题描述】：

我正在用 Django 构建一个 API，我想查询 Github GraphQL API，我发现这个 GraphQL client 的 python 适合我的需要。

但是现在，我想知道，在我的 Django 应用程序中初始化这样一个客户端的正确位置在哪里？在请求里面？在apps.py 中？在views.py中？任何指导方针将不胜感激！这是我当前的 Django Project 文件夹结构：

.
├── LICENSE
├── README.md
├── api
│   ├── __init__.py
│   ├── admin.py
│   ├── apps.py
│   ├── migrations
│   │   └── __init__.py
│   ├── models.py
│   ├── tests.py
│   ├── urls.py
│   └── views.py
├── db.sqlite3
├── manage.py
├── portfolio
│   ├── __init__.py
│   ├── asgi.py
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
├── requirements.txt
└── setup.py

提前致谢！

【问题讨论】：

参考这篇文章。 medium.com/swlh/…
嘿！谢谢你的建议！但我认为这不是我想要的，如果你仔细阅读，我不是构建 GraphQL API，而是从 Django 请求中查询一个（Github v4 API）。我提到的库是 Python 的 GraphQL 客户端，它必须被初始化，但是每次请求进来时都初始化一个新的客户端实例听起来没有必要，所以我觉得必须有一个更好的地方来初始化库，然后导入已经将客户端初始化到视图
不能说这是否是最 Djangoish 的方式，但我会把它放在 views.py 中。如果您仅在一个视图中使用客户端，那么我将在该视图函数/类中导入和初始化客户端。
您好！我正在考虑这个问题，但我在那里读到，views.py 是根据工人的请求导入的，也许我理解错了？如果是这样的话，也许它与在请求本身上初始化它没有什么不同
为什么需要在服务器端进行查询？

标签： python django graphql

【解决方案1】：

根据定义，graphql 客户端需要它自己的配置、模块和错误处理，我建议您创建一个与其他项目相邻的命名空间。 Django 使用Applications 的概念，为这种情况提供单独的配置、日志记录和错误处理。您在 settings.py 中的 INSTALLED_APPS (Docs) 中定义项目中的其他应用程序。你的项目结构看起来像这样：

.
├── LICENSE
├── README.md
├── graphql-client
│   ├── __init__.py
│   ├── main.py
│   ├── client.py
│   ├── ressources
│   │   ├── __init__.py
│   ├── ├── repository.py
│   │   └── user.py
│   ├── settings.py
│   └── views.py
├── api
│   ├── __init__.py
│   ├── admin.py
│   ├── apps.py
│   ├── migrations
│   │   └── __init__.py
│   ├── models.py
│   ├── tests.py
│   ├── urls.py
│   └── views.py
├── db.sqlite3
├── manage.py
├── portfolio
│   ├── __init__.py
│   ├── asgi.py
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
├── requirements.txt
└── setup.py

【讨论】：

您好！我将在我的 /api Django 应用程序中使用我的 GraphQL 客户端，你能建议一些替代方案来保持我的 /api 应用程序完全独立吗？这样，它可以在项目之间轻松移动。
项目结构中的位置取决于您的偏好。此外，您只需在命名空间中对其进行初始化，就可以坚持使用 django Application 概念。 (api.graphql-client)

【解决方案2】：

我最终在/api 应用程序中创建了一个名为graphql.py 的python 模块，该模块用于初始化graphql 客户端。从这里，它很容易导入。

我决定不为此创建一个单独的 Django 应用程序，因为由于代码的简单性，在这种情况下这将是多余的：

在graphql.py:

from gql import Client
from gql.transport.requests import RequestsHTTPTransport
from django.conf import settings

# Instaciate a graphql client
client = Client(
    transport=RequestsHTTPTransport(
        url='https://api.github.com/graphql',
        headers={'Authorization': 'bearer {token}'.format(token=settings.GITHUB_TOKEN)},
        verify=False,
        retries=3,
    ),
    fetch_schema_from_transport=True,
)

【讨论】：

【解决方案3】：

TLDR：在视图方法中实例化新客户端 = 每个请求的新客户端。（不错的选择 - 覆盖 initial 视图方法）。稍后改进。

视情况而定。

如果客户端没有请求/用户选项（= 客户端相同 每个请求/用户）：

按照@ElPapi42 的建议从子模块导入一个（= 与全局在views.py 中实例化新客户端相同，而不是作为方法逻辑的一部分）
或在视图方法中实例化新客户端 - 每个请求的新客户端

如果有请求/用户特定选项（即客户端需要有request.user 特定选项/凭据）：

在视图方法中实例化新客户端

选项 1 - 每个工作人员视图实例化一次客户端。虽然它提供了一些性能优势，但它们是微妙而模糊的：

您可能不知道这意味着什么：共享客户端 => 可能使用修改客户端状态的方法来处理依赖状态的不同请求/用户
工人的寿命（应该）实际上没有那么长
很难评估性能优势，也很难评估是否正确实施

实际上，您可能希望使用一些当前的request.user 特定选项连接到 github，执行多个请求（= 可能涉及 cookie 并在后续请求中自动添加 => 客户端不能与多个用户共享）= 至少每个用户都有单独的客户端。

【讨论】：