Нужно ли использовать Nuxt Server в качестве посредника между моим внешним Django API и фронтендом Nuxt 3 в режиме SSR?
Я разрабатываю SaaS-приложение, использующее архитектуру бэкенда с Django REST API и базой данных PostgreSQL, а фронтенд использует Nuxt 3 с TypeScript, Tailwind и TanStack Query для управления API-запросами. Я включил Server-Side Rendering (SSR), установив ssr: true в файле nuxt.config.ts :
export default defineNuxtConfig({
ssr: true,
})
В моей текущей архитектуре у меня есть каталог server/api/ внутри приложения Nuxt 3, содержащий несколько файлов, которые представляют конечные точки для взаимодействия с Django API. Например, у меня есть файл server/api/projects/index.ts, который указывает на конечную точку Django /api/projects/ для получения всех проектов.
Интеграция с новым сервером:
Структура каталога следующего сервера:
server/api/projects/index.ts : Указывает на конечную точку Django /api/projects/ для получения всех проектов.
server/api/projects/[id].get.ts : Выбирает проект по его ID из /api/projects/detail/${projectId}/.
Логика взаимодействия с интерфейсом:
Эти конечные точки используются в обработчике сервиса (api/projects.api.ts), который предоставляет такие функции, как getAllProjects, getProjectById и deleteProjectById.
Составляющие (useProjects.ts):
Композитный useProjects.ts использует функции в api/projects.api.ts для управления данными проекта и взаимодействия с конечными точками Nuxt Server в server/api/projects/. Он использует useQuery из TanStack Query для эффективного управления состоянием.
Вопрос:
Нужно ли иметь промежуточный сервер Nuxt между фронтендом Nuxt 3 и внешним Django API? Дает ли это какие-то особые преимущества для Server-Side Rendering (SSR), или фронтенд Nuxt 3 может напрямую взаимодействовать с Django API, сохраняя при этом возможности SSR?
Спасибо за помощь!
Структура приложения :
frontend/
├─ api/ # Functions to call the API server Nuxt 3 (server/api/)
│ └─ projects.api.ts
├─ app.vue
├─ assets/
│ └─ css/
│ └─ tailwind.css
├─ composables/ # Composables to call functions in api/projects.api.ts
│ └─ useProjects.ts # and share data between components
├─ nuxt.config.ts
├─ pages
│ ├─ ecowall/
│ │ ├─ conception
│ │ │ └─ [projectId]
│ │ │ └─ paroi
│ │ │ ├─ [paroiId].vue
│ │ │ └─ new-paroi.vue
│ │ ├─ index.vue
│ │ └─ projects
│ │ ├─ [projectId].vue
│ │ └─ index.vue # I use my composables useProjects.ts here to get all projects
│ └─ index.vue
├─ plugins
│ └─ vue-query.ts
├─ server/ # Intermediary server to call the Django API endpoints
│ ├─ api/
│ │ ├─ projects/
│ │ │ ├─ [id].delete.ts
│ │ │ ├─ [id].get.ts
│ │ │ ├─ create.post.ts
│ │ │ └─ index.ts
│ └─ tsconfig.json
└─ tsconfig.json
Я реализовал промежуточный сервер Nuxt, который будет служить мостом между фронтендом Nuxt 3 и внешним API Django. Я ожидал, что этот промежуточный слой повысит производительность, обеспечит безопасность и улучшит Server-Side Rendering (SSR). Однако я не уверен, что такой подход необходим.
Что я пробовал:
- Я создал несколько конечных точек API в каталоге server/api моего приложения Nuxt 3, которые напрямую указывают на конечные точки API Django:
server/api/projects/index.ts указывает на /api/projects/.
server/api/projects/[id].get.ts указывает на /api/projects/detail/${projectId}/.
Я создал обработчик службы (
api/projects.api.ts), который предоставляет функции для взаимодействия с этими конечными точками сервера Nuxt.Я использовал композитный (
useProjects.ts) для управления данными проекта и взаимодействия с конечными точками сервера Nuxt через TanStack Query.
То, что я ожидал:
Повышение производительности за счет лучшего кэширования и преимуществ SSR. Повышенная безопасность, поскольку сервер Nuxt выступает в качестве посредника между фронтендом и Django API.
Что произошло на самом деле:
Эта настройка работает хорошо, но она добавляет сложности в архитектуру. Я не уверен, нужен ли этот промежуточный сервер Nuxt или фронтенд Nuxt 3 может напрямую взаимодействовать с внешним Django API, сохраняя при этом возможности SSR. Поэтому я хотел бы узнать, дает ли этот подход какие-либо преимущества для SSR или достаточно прямого соединения между фронтендом и Django API.
Вы могли бы получить некоторые преимущества в производительности, если бы получали данные на сервере и передавали их на сторону клиента, а не получали их там (устраняются накладные расходы на JSON), и еще несколько подобных вещей, так что это вроде как улучшит производительность.
Кроме того, если вы используете full-static mode в Nuxt (также доступный в Nuxt3), то вы можете пропустить любые внешние вызовы и установить его во время сборки.
Так что, в зависимости от того, что вы делаете в своем приложении, SSR вроде как помогает.
Может принести некоторую пользу или не принести вовсе.
Усилить безопасность? Совсем наоборот. Между процессом гидратации и тем фактом, что вы работаете с изоморфным приложением в Nuxt, это может привести к большему количеству утечек, чем если бы вы держали Django и Nuxt отдельно.
В целом, вы можете использовать каталог Nuxt server для нескольких конечных точек, если польза от этого очевидна, но в остальном, кроме сложности отладки, как вы правильно догадались, никакой реальной пользы нет.
Если вы выполняете тяжелый набор текста на стороне сервера Nuxt, возможно, вы увидите в этом смысл. Кроме того, вы можете получить более быстрый ответ, обратившись к конечной точке Nuxt, а не к своей, потому что вы пропустите реальное сетевое путешествие (просто сделайте это локально), но вам также нужно, чтобы данные были доступны в вашем приложении Nuxt, так что это тоже не так просто.
TLDR: держите их отдельно и используйте каталог Nuxt server в особых случаях с очевидными преимуществами.