Связь между Джанго и Реактом

Question

Я пытаюсь настроить проект, используя Django для бэкэнда и React для веб-интерфейса.Проект имеет несколько экранов, много информации в БД и изображения, сгенерированные бэкэндом, и будет включать в себя некоторую аутентификацию и пользовательские разрешения для разных экранов.

Согласно тому, что я нашел - лучший способ сделать этоDjango отображает HTML-файл:

def index(request):
    return render(request, 'frontend/index.html')

, который ссылается на файл .js:

<script src="{% static "frontend/main.js" %}"></script>

, созданный с помощью Webpack.

Этот main.js извлекаетданные, которые ему нужны из Django с использованием API REST:

 fetch("...some Django endpoint..").then(response => ... this.setState(...retrieved data...))

В отличие от простого использования Django для бэкэнда + шаблонов Django для внешнего интерфейса, где бэкэнд может просто отправить контекст непосредственно в шаблон:

def index(request):
    context = {'information': .... retrieve info from DB}
    return HttpResponse(loader.get_template('bla/index.html').render(context, request))

и шаблон может использовать эту информацию напрямую, без повторной ссылки на бэкэнд:

{% for bla in information %}

Мне интересно, является ли это разумной настройкой?

Кажется чрезмерным иметьИнтерфейс использует REST для извлечения каждой части информации, которая ему нужна, а бэкэнд предоставляет другой REST API для каждой части данных, которую он должен предоставить (вместо простогоиспользование всей информации в едином формате и отправка ее вместе с шаблоном),

Кроме того, требуется минимум 2 RTT для рендеринга полной страницы (что, я думаю, обычно хорошо)

Answer 1

Согласно тому, что я нашел, лучший способ сделать это - заставить Django визуализировать HTML-файл:

Я не согласен с этой строкой.Я бы сказал, что было бы лучше, чтобы приложение «Реакция» и приложение «Джанго» были полностью отделены друг от друга.Я считаю, что приложение Django должно предоставлять исключительно API и административный сайт (возможно, в зависимости от ваших потребностей).И интерфейс должен быть автономным приложением, которое может обслуживаться через NGINX / ExpressJs / Apache и т. Д.

Есть несколько преимуществ этой настройки.

С точки зрения приложения Django, преимущества заключаются в следующем:

1. Джанго не будет обременен обслуживанием фронтенда.Используйте gunicorn или uwsgi для обслуживания API-интерфейсов Django.
2. Поскольку Django будет предоставлять данные только через API, он обеспечит ясность в отношении того, как приложение внешнего интерфейса будет взаимодействовать с бэкэндом.Я знаю, что вы можете отправлять данные, используя контекст, когда Django обслуживает приложение реагирования, но это может вызвать путаницу из-за сосуществования API и контекста.
3. Вы можете использовать Аутентификация на основе токенов , JWT и т. Д. Вместо собственной аутентификации Django на основе сеанса , которая имеет множество других преимуществ .

Освобождение вашего веб-приложения от бэкэндаэто лучшее, что может случиться для внешнего интерфейса.Как например:

• если у вас был Django для обслуживания внешнего интерфейса, вы были почти вынуждены использовать сессионную аутентификацию (это не значит, что вы не можете использовать другие аутентификации, но какой смысл иметь несколькосистемы аутентификации)
• Вы не могли бы использовать рендеринг на стороне сервера с Django рендерингом внешнего интерфейса.
• Допустим, вы понятия не имеете, как работает Django, новы будете вынуждены настроить приложение Django на локальном компьютере, поскольку оно обслуживает внешний интерфейс.
• Вы не могли использовать ExpressJ для обслуживания внешнего интерфейса или использовать преимущества использования NGINX для обслуживания.это содержимое .
• Развертывание будет затруднено, если у вас есть настройка докера.В этом случае вам пришлось бы использовать один Docker-контейнер для обслуживания всего, иначе вы могли бы использовать несколько Docker-контейнеров для обслуживания бэкэнда / внешнего интерфейса.
• Допустим, вы хотите обслуживать приложение Django на одном сервере., интерфейс с другого сервера, но с Django, тесно связанным с Frontend, вы не можете выполнить эту настройку.
• Вы можете легко подключать внешние службы RESTful API, не беспокоясь о Django.Даже вы можете использовать любые другие фреймворки, такие как Tornado, Flask и т. Д. (Но DRF + Django ORM великолепен) для разработки API.

Есть еще несколько общих преимуществ разделения бэкэнда и внешнего интерфейса .

Существует фантастический учебник , который вы можете прочитать на носителе о настройке отдельного приложения Django + ReactJs .

Answer 2

Вы можете настроить шаблонный проект с помощью инфраструктуры, которую я написал, которая достигает того, что вы ищете, из коробки.Django on на сервере, React на клиенте.

https://github.com/rafay826/djudo

Реагирующий клиент принимает данные API из Django, и аутентификация обрабатывается пакетом, называемым rest-auth.

Answer 3

Вы можете использовать GraphQL, он имеет несколько преимуществ перед REST, например:

• только одна конечная точка для всего приложения;
• возможность извлечения данных с отношениями между ними;
• легкие изменения структуры данных с обеих сторон;
• расширенный клиент с кэшем / нормализацией / подписками / оптимистическими обновлениями (я предпочитаю apollo для ретрансляции);
• может использоваться как источник данных для статических данныхсоздание сайта (SEO);
• вы можете использовать другие сервисы / API;
• ... многие другие.

Используя реагирование на стороне сервера, вы можете получить страницыбез дополнительных запросов - «предварительно заполнено» / повторно гидратировано, готово к взаимодействию - лучше «Время для интерактива».

Учебное пособие / демо: django-graphql-apollo-реагировать-демо