在Vue + Django Webpack应用程序中处理页面 [英] Handling pages in a vue + django webpack application
问题描述
我将Vue添加到了我的Django项目中，但是由于我不想将前端与后端分离，所以我决定直接从Django加载webpack.我的设置似乎可以与 django webpack加载器一起使用，但是我有一些我对该项目的结构有疑问.
I added Vue to my Django project, but since i didn't want to decouple frontend from backend, i decided to load webpack directly from Django. My setup seems to work with django webpack loader, but i'm having some doubts on how i structured the project.
这是我的文件夹:
my_site
- django settings
my_app
- views, urls, models, templates
vue_frontend
- webpack and vue stuff
我的疑问是:应该由Django处理路由还是应该由SPA中的Vue处理路由?
My doubt is: should routing be handled by Django or should it be handled by Vue in a SPA?
这是我现在拥有的:
django_template2.html
{% extends 'header.html' %}
{% load render_bundle from webpack_loader %}
{% block content %}
<body>
<div id="app">
<firstVueComponent />
</div>
</body>
{% render_bundle 'chunk-vendors' %}
{% render_bundle 'main' %}
{% endblock %}
django_template2.html
{% extends 'header.html' %}
{% load render_bundle from webpack_loader %}
{% block content %}
<body>
<div id="app">
<secondVueComponent />
</div>
</body>
{% render_bundle 'chunk-vendors' %}
{% render_bundle 'main' %}
{% endblock %}
因此Django在此处处理网址:
So Django handles the urls here:
from django.urls import path, include
from . import views
urlpatterns = [
path('first_page/', views.first_page, name='first'),
path('second_page/', views.second_page, name='second'),
]
所以在这里我不是用Vue来处理路由，而是在需要它们的Django模板中加载同一应用程序的各个Vue组件.我的疑问:这是不好的做法吗?有什么理由我应该避免这样做?
So here i'm not using Vue to handle routes, but i load individual Vue components of the same app in those Django templates where i need them. My doubt: is it a bad practice? Are there reasons for which i should avoid doing so?
推荐答案
我的疑问是:应该由Django处理路由还是应该由SPA中的Vue处理路由?
My doubt is: should routing be handled by Django or should it be handled by Vue in a SPA?
如果您要进行SPA，您的FE需要知道路线，例如如果用户单击链接/项目，您的FE需要知道如何更新URL.否则，将刷新页面或错误的URL.
Your FE needs to know the routes if you're going to do SPA, e.g. your FE needs to know how to update the URL if user clicks on a link/item. Otherwise there would be page refreshes or wrong URLs.
所以在这里我不是用Vue来处理路由，而是在需要它们的Django模板中加载同一应用程序的各个Vue组件.我的疑问:这是不好的做法吗?有什么理由我应该避免这样做?
So here i'm not using Vue to handle routes, but i load individual Vue components of the same app in those Django templates where i need them. My doubt: is it a bad practice? Are there reasons for which i should avoid doing so?
我认为您需要决定是否要建立SPA.我的经验法则是SPA更好，如果您的页面上有很多互动，或者您有FE的专业团队.在BE/FE之间完全分开绝对是业界事实上的标准，但是在BE上渲染大多数内容并拥有轻量级的FE也不构成犯罪，Stack溢出本身使用这种方法.
I think you need to decide it you're going to build a SPA or not. My rule-of-thumb is SPA is better if have a lot of interactions on your page or you have a team of speciallized people for FE. Having a total separation between BE/FE is definitely industry de-facto standard but rendering most stuff on BE and having a lightweight FE is not a crime either, Stack overflow itself uses such approach.
如果要使用SPA，则将FE URL放入BE也没有太大意义(除非您正在执行服务器端渲染之类的操作).BE将提供一组API URL(对于最终用户不可见)，FE将使用它们，并提供一组用户将看到的FE URL.
If you're going with SPA, putting FE URLs in BE also makes not much sense (unless you're doing something like server side rendering). BE will provide a set of API URLs (invisible to end user) and FE will consume them and provide a set of FE URLs that users would see.
是的，主要问题是将应用程序托管在两个不同的域上可能使我在安全方面失去很多django的好处.我对将jwt令牌存储在本地存储上有一些疑问，我认为这不是最安全的解决方案.有基于会话的身份验证，但我不知道它将如何在两个不同的域上工作.另一件事是缺少示例，最后最大的问题是我已经在此环境上安装了该应用程序，因此，将其移至去耦将是一个关键点
Yes, the main problem is that having the apps hosted on two different domains might make me lose a lot of django benefits in terms of security. I have some doubts on storing a jwt token on local storage, i don't think its the safest solution; there is session based auth but i don't know how would it work on two different domains. Another thing is the lack of examples on this, and finally the biggest problem is that i already setup the app on this environment, so moving to decoupled would be quite a pivot
您有多个答案.
1-无需分隔域.您可以在所有BE URL前面加上/api/前缀，然后在生产时可以使用NGINX或Traefik之类的反向代理或您的负载均衡器，...来将两者分开.从长远来看，拥有单独的域更容易维护，但是您需要不时地处理cookie/CORS问题.
1- There's no need to have separated domain. You can prefix all your BE URLs with /api/ then on production you can use a reverse-proxy like NGINX or Traefik or your load balancer, ... to separate the two. Having separate domains is easier to maintain in long run but you'll need to handle cookie/CORS issues now and then.
2- If you have separated domains you can set cookies on the main domain from subdomain with this settings
3-在本地存储中无需使用JWT令牌.IMO不如拥有httponly cookie.Django会话身份验证默认已打开 httponly .这样，您在页面上安装的随机npm库或第三方脚本将无法访问和窃取令牌.
3- There's no need to go with JWT token in localstorage. IMO it's inferior to having httponly cookies. Django session auth has httponly turned on by default. This way random npm libraries you installed or 3rd party scripts on your page has no way to access and steal the token.
4-另外，现在我们有浏览器上的相同站点 cookie.在此处检查浏览器支持.较新版本的Django默认为Lax，可保护您免受受支持的浏览器中CSRF的侵害.因此，您可以关闭该保护功能以减轻头痛.
4- On a separate note, Django CSRF protection is kinda obsolete now we have samesite cookie on browsers. Check browser support here. Newer versions of Django defaults to Lax that protects you from CSRF on supported browsers. So you can turn that protection off to have one less headache.
我个人认为您可以坚持基于Django会话的身份验证，而无需在您的FE中添加任何内容.FE只会调用/api/auth/login ，并且会自动设置适当的cookie.
I personally think you can stick to Django session based auth, no need to add anything to your FE. FE will just call /api/auth/login and proper cookies will be set automatically.
要更强大，可以添加一个类似/api/auth/me 的API，该API将当前登录的用户数据返回给FE.当用户首次访问您的网站时，FE会致电告知您是否登录.
To be more robust you can add an API like /api/auth/me that returns current logged in user data to FE. FE will call that when user visits your website for first time to understand if user is logged in or not.
这篇关于在Vue + Django Webpack应用程序中处理页面的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
